Oracle® Fusion Middleware Oracle WebLogic Server 12.1.3のパフォーマンスのチューニング 12c (12.1.3) E56271-05 |
|
![]() 前 |
![]() 次 |
この章では、WebLogic Server 12.1.3でWebLogicデータ・ソースのパフォーマンスを最大にする方法のヒントを示します。
この章には次の項が含まれます:
WebLogic Serverアプリケーションでデータ・ソースのパフォーマンスを向上させる簡単な方法は、データ・ソースの接続プールを構成するときに「初期容量」
の値を「最大容量」
の値と同じに設定することです。
データベース接続の作成は、環境内では比較的コストのかかるプロセスです。通常、起動時の接続プールには少数の接続が含まれています。接続に対するクライアントのリクエストが増えるにつれて、プール内の接続だけではリクエストに十分に応じられなくなります。WebLogic Serverは、最大プール・サイズに達するまで、接続をさらに作成してプールに追加します。
サーバーを使用するクライアントに対して接続の作成が遅れないようにする1つの方法は、すべての接続をクライアントの要求によって初期化するのではなく、サーバーの起動時に初期化することです。データ・ソース構成の「接続プール」タブの接続の初期数の値を接続の最大数の値と等しい設定します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソース: 構成: 接続プールに関する項を参照してください。本番前パフォーマンス・テストの一部として最大容量
の値を決定する必要があります。
チューニングの詳細は、『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の負荷が重くなる(CPU使用率が高い)一部の状況では、データベース・リスナーがタイムアウトし、新規接続の作成中に例外をスローする場合があります。この問題を解決するには、データベース・サーバー上でリスナー・タイムアウトを増進します。次の例は、オラクル社のドライバおよびデータベースの例です。
スローされた例外は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ドライバとデータベースの詳細構成に関する項を参照してください。
データベース・アプリケーションのパフォーマンスの良し悪しはほとんどの場合、アプリケーション言語ではなく、アプリケーションがどのように設計されているかによって決定されます。クライアントの数と場所、DBMS表および索引のサイズと構造、および問合せの数とタイプは、すべてアプリケーションのパフォーマンスに影響を与えます。『Oracle WebLogic Server JDBCアプリケーションの開発』のベスト・パフォーマンスのためのアプリケーションの設計に関する項を参照してください。