Oracle® Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング 11g リリース1 (10.3.3) B61002-01 |
|
![]() 前 |
![]() 次 |
次の項では、JDBCアプリケーションから最高のパフォーマンスを引き出すためのヒントを紹介します。
WebLogic ServerアプリケーションでJDBCのパフォーマンスを向上させる簡単な方法は、データ・ソースの接続プールを構成するときに「初期容量」
の値を「最大容量」
の値と同じに設定することです。
データベース接続の作成は、環境内では比較的コストのかかるプロセスです。通常、起動時の接続プールには少数の接続が含まれています。接続に対するクライアントのリクエストが増えるにつれて、プール内の接続だけではリクエストに十分に応じられなくなります。WebLogic Serverは、最大プール・サイズに達するまで、接続をさらに作成してプールに追加します。
サーバーを使用するクライアントに対して接続の作成が遅れないようにする1つの方法は、すべての接続をクライアントの要求によって初期化するのではなく、サーバーの起動時に初期化することです。データ・ソース構成の「接続プール」タブの接続の初期数の値を接続の最大数の値と等しい設定します。Oracle WebLogic Server管理コンソール・ヘルプのJDBCデータ・ソース: 構成: 接続プールに関する項を参照してください。本番前パフォーマンス・テストの一部として最大容量
の値を決定する必要があります。
チューニングの詳細は、『Oracle WebLogic Server JDBCの構成と管理』のデータ・ソース接続プールのオプションのチューニングに関する項を参照してください。
JDBCアプリケーションのパフォーマンスを向上させる簡単な方法としては、リソースを浪費しないようにすることがあります。以下のような状況では、JDBC関連リソースの浪費を避けることができます。
JNDIルックアップは比較的コストがかかるため、クライアント・コードまたはアプリケーション・コードでルックアップを要求したオブジェクトをキャッシュしておくと、パフォーマンスに何度も影響を与えることがなくなります。
クライアントまたはアプリケーション・コードで接続を取得したら、接続を閉じて新しい接続を再取得する代わりに、その接続をできる限り再利用します。既存の接続を取得して戻すと、新しい接続を作成する場合よりもコストが抑えられますが、取得とプールへの返却を過度に行うと、接続プールに競合が発生して、アプリケーションのパフォーマンスが低下します。
作業の実行に必要な時間よりも長く接続を保持しません。接続を一度取得して必要な作業をすべて完了したら、できるだけ早く接続を戻すようにすると、全体的なパフォーマンスのバランスが最適になります。
「予約時に接続をテスト」
を有効にした場合、サーバー・インスタンスはデータベース接続をクライアントに戻す前にチェックします。この機能によって、無効な接続がクライアントに渡されるリスクを減らすことができます。
ただし、この処理にはかなりコストがかかります。通常、サーバー・インスタンスでは、接続を戻す前に各接続に対して完全なSQL問合せを実行することにより、テストを実行します。SQL問合せが失敗すると、その接続は破棄されて、代わりに新しい接続が作成されます。WebLogic Server 9.xでは、この「予約時の接続テスト」機能に、パフォーマンス調整可能な任意の新しいオプションが用意されました。9.xのパフォーマンス調整可能な任意の新しいオプションを使用すると、クライアントが接続を以前に正常に使用したときから構成済みの期間内(デフォルトは10秒間)であれば、WebLogic ServerでSQL問合せテストを省略できます。クライアントがプールに接続を戻すとき、WebLogic Serverはその接続にタイムスタンプを設定します。この特定の接続が期間内にクライアントに返された場合、WebLogic ServerはSQL問合せテストを省略します。この期間の経過後には、SQL問合せテストが実行されるようになります。この機能によって、「予約時の接続テスト」を使用するビジー・システムでは、パフォーマンスを大幅に向上させることができます。
アプリケーションまたはEJBで準備された文またはコール可能文を使用すると、アプリケーション・サーバーとデータベース・サーバーの間とデータベース・サーバー自体に通信のために大きな処理オーバーヘッドが発生されます。処理コストを最小限にする場合、WebLogic Serverでは、アプリケーションで使用されるプリペアド文またはコール可能文をキャッシュできます。アプリケーションまたはEJBによってキャッシュに格納された文が呼出されると、キャッシュに格納された文が再利用されます。プリペアド文またはコール可能文を再利用すると、データベース・サーバー上のCPU使用量が低減され、現在の文のパフォーマンスが向上します。また、CPUサイクルを別のタスクを行うために使用できます。詳細は、『Oracle WebLogic Server JDBCの構成と管理』の文キャッシュによるパフォーマンスの向上に関する項を参照してください。
ステートメント・キャッシュを使用することでパフォーマンスを大幅に向上させることができますが、制限があることも考慮に入れる必要があります。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCの構成と管理』の文キャッシュに関する制限を参照してください。
アプリケーションがデータ・ソースからのデータベース接続を予約するのにかかる時間を最小限にし、データベース接続用のスレッド間の競合を削減するには、データ・ソースの接続プロパティ・リストにPinned-To-Thread
プロパティを追加し、その値をtrue
に設定します。
このリリースでは、Pinned-To-Thread機能はマルチ・データ・ソース、Oracle RAC、およびIDプールでは有効になりません。これらの機能は、接続プールに接続を返し、接続が失敗した場合や、接続IDが一致しなかった場合に、その接続を再取得する機能に依存しています。
Oracle WebLogic Server管理コンソール・ヘルプの「JDBCデータ・ソース接続プール」を参照してください。
データベース・アプリケーションのパフォーマンスの良し悪しはほとんどの場合、アプリケーション言語ではなく、アプリケーションがどのように設計されているかによって決定されます。クライアントの数と場所、DBMS表および索引のサイズと構造、および問合せの数とタイプは、すべてアプリケーションのパフォーマンスに影響を与えます。『Oracle WebLogic Server JDBCのプログラミング』のベスト・パフォーマンス用アプリケーションの設計に関する項を参照してください。