| Oracle® Fusion Middleware Oracle WebLogic Server パフォーマンス チューニング ガイド 11g リリース 1 (10.3.1) B55570-01 |
|
 戻る |
 次へ |
| Oracle® Fusion Middleware Oracle WebLogic Server パフォーマンス チューニング ガイド 11g リリース 1 (10.3.1) B55570-01 |
|
戻る |
次へ |
以下の節では、JDBC アプリケーションから最高のパフォーマンスを引き出すためのヒントを紹介します。
WebLogic Server アプリケーションで JDBC のパフォーマンスを向上させる簡単な方法は、データ ソースの接続プールをコンフィグレーションするときに [初期容量] の値を [最大容量] の値と同じに設定することです。
データベース接続の作成は、環境内では比較的コストのかかるプロセスです。通常、起動時の接続プールには少数の接続が含まれています。接続に対するクライアントの要求が増えるにつれて、プール内の接続だけでは要求に十分に応じられなくなります。WebLogic Server は、最大プール サイズに達するまで、接続をさらに作成してプールに追加します。
サーバを使用するクライアントが接続作成時の遅延を受けないようにするには、クライアントの要求に応じて接続を作成する代わりに、すべての接続をサーバ起動時に初期化する方法があります。データ ソース コンフィグレーションの [接続プール] タブで、接続の初期数を接続の最大数と同じに設定します。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JDBC データ ソース : コンフィグレーション : 接続プール」を参照してください。ただし、プロダクション前のパフォーマンス テストの際には、[最大容量] に最適な値を決定する必要があります。
チューニングの詳細については、『Oracle Fusion Middleware 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 が、キャッシュに格納された文のいずれかを呼び出すと、WebLogic Server はキャッシュ内に格納されている文を再利用します。プリペアド ステートメントや呼び出し可能ステートメントを再利用することで、データベース サーバの CPU の使用率が下がり、現在のステートメントのパフォーマンスが向上するため、CPU サイクルを他のタスクに割り当てることができます。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理』の「ステートメント キャッシュによるパフォーマンスの向上」を参照してください。
ステートメント キャッシュを使用することでパフォーマンスを大幅に向上させることができますが、制限があることも考慮に入れる必要があります。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理』の「ステートメント キャッシュに関する制限」を参照してください。
アプリケーションがデータ ソースからのデータベース接続を予約するのにかかる時間を最小限にし、データベース接続用のスレッド間の競合を削減するには、データ ソースの接続プロパティ リストに Pinned-To-Thread プロパティを追加し、その値を true に設定します。
このリリースでは、Pinned-To-Thread 機能はマルチ データ ソース、Oracle RAC、および ID プールでは有効になりません。これらの機能は、接続プールに接続を返し、接続が失敗した場合や、接続 ID が一致しなかった場合に、その接続を再取得する機能に依存しています。
Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「JDBC データ ソース : コンフィグレーション : 接続プール」を参照してください。
データベース アプリケーションのパフォーマンスの良し悪しはほとんどの場合、アプリケーション言語ではなく、アプリケーションがどのように設計されているかによって決定されます。クライアントの数と場所、DBMS テーブルおよびインデックスのサイズと構造、およびクエリの数とタイプは、すべてアプリケーションのパフォーマンスに影響を与えます。『Oracle Fusion Middleware Oracle WebLogic Server JDBC プログラマーズ ガイド』の「ベスト パフォーマンスのためのアプリケーション設計」を参照してください。
