データベース接続の作成は、環境内では比較的コストのかかるプロセスです。WebLogic Serverアプリケーションでデータ・ソースのパフォーマンスを向上させる簡単な方法は、データ・ソースの接続プールを構成するときに「初期容量」
の値を「最大容量」
の値と同じに設定することです。
通常、起動時の接続プールには少数の接続が含まれています。接続に対するクライアントのリクエストが増えるにつれて、プール内の接続だけではリクエストに十分に応じられなくなります。WebLogic Serverは、最大プール・サイズに達するまで、接続をさらに作成してプールに追加します。
サーバーを使用するクライアントに対して接続の作成が遅れないようにする1つの方法は、すべての接続をクライアントの要求によって初期化するのではなく、サーバーの起動時に初期化することです。データ・ソース構成の「接続プール」タブの接続の初期数の値を接続の最大数の値と等しい設定します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソース: 構成: 接続プールを参照してください。本番前パフォーマンス・テストの一部として最大容量
の値を決定する必要があります。
Initial Capacity
の値をゼロに構成すると、WebLogic Serverは起動中に接続を確立しません。これは起動パフォーマンスを大幅に向上します(特に、いくつかのデータ・ソースが有効になっている場合)。しかし、さらに重要なこととしては、データベースが使用可能でない場合や起動時に問題がある場合でも(あるいは、プライマリ・サービスが実行中には使用できないスタンバイ・データ・ソースの場合でさえも)、起動時にデータ・ソースをデプロイできるようにします。
Initial Capacity
がゼロであっても接続が予約されている状況を次に2つ示します。
LLR用に構成されたマルチ・データ・ソース。メンバー・データ・ソースごとに接続が予約され、基礎となるデータベースがOracle Real Application Clusters (Oracle RAC)データベースであるかが判断されます。Oracle RACの場合、使用できるメンバー・データ・ソースは1つのみです。
auto-ONSで構成されたActive GridLink (AGL)データ・ソースの場合(つまり、ONSホストとポートのペアが提供されない場合)、接続が確立され、データベースからONS構成情報を取得できます。
『Oracle WebLogic Server 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 WebLogic Server JDBCデータ・ソースの管理』の文キャッシュの使用制限に関する項を参照してください。
アプリケーションがデータ・ソースからのデータベース接続を予約するのにかかる時間を最小限にし、データベース接続用のスレッド間の競合を削減するには、データ・ソースの接続プロパティ・リストにPinned-To-Thread
プロパティを追加し、その値をtrue
に設定します。
このリリースでは、Pinned-To-Thread機能はマルチ・データ・ソース、Oracle RAC、およびIDプールでは有効になりません。これらの機能は、接続プールに接続を返し、接続が失敗した場合や、接続IDが一致しなかった場合に、その接続を再取得する機能に依存しています。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソース: 構成: 接続プールを参照してください。
WebLogic Serverの負荷が重くなるという一部の状況では、データベース・リスナーがタイムアウトし、新規接続の作成中に例外をスローする場合があります。この問題を解決するには、データベース・サーバー上でリスナー・タイムアウトを増進します。
次の例は、オラクル社のドライバおよびデータベースの例です。
スローされた例外はResourceDeadException
で、ドライバの例外はソケット読取りは時間切れ
でした。
解決するには、次を使用してデータベース・サーバーのタイムアウトを増進します。
sqlnet.ora: SQLNET.INBOUND_CONNECT_TIMEOUT=180
listener.ora: INBOUND_CONNECT_TIMEOUT_listener_name=180
デフォルトでは、Array、Blob、Clob、NClob、Ref、SQLXML、およびStructのデータ型オブジェクトに加え、ParameterMetaDataとResultSetMetaDataオブジェクトがWebLogicラッパーによってラップされます。データ型オブジェクトのラップを無効化できます。
『Oracle WebLogic Server JDBCデータ・ソースの管理』のラップされていないデータ型オブジェクトの使用に関する項を参照してください。
Oracleドライバとデータベースを使用する場合にデータ・ソースとドライバのパフォーマンスを向上させる詳細構成オプションが用意されています。オプションには、プロキシ認証、接続での資格証明の設定、接続収集、接続のラベル付けなどがあります。
『Oracle WebLogic Server JDBCデータ・ソースの管理』のOracleドライバとデータベースの詳細構成に関する項を参照してください。