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