| Oracle® Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング 11g リリース1 (10.3.6) B61002-05 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング 11g リリース1 (10.3.6) B61002-05 |
|
前 |
次 |
この章では、パフォーマンス・チューニングにおける重要推奨事項を簡単に示します。WebLogic ServerおよびWebLogic Serverアプリケーションのチューニングは、複雑で繰返し実施しなければならない作業です。ここでは、チューニングを始めるにあたり、アプリケーションのパフォーマンスを最適化する際の推奨事項について簡単に説明します。ここで説明するチューニング方法は、ほとんどのWebLogicアプリケーションに適用できます。
予想されるスレッドの利用に対して、同時実行性を最大化するプール・サイズ(JDBC接続、ステートレス・セッションEJB、およびMDBのプールなど)を指定します。
WebLogic Serverリリース9.0以降の場合、サーバー・インスタンスでは自動チューニング・スレッド・プールが使用されます。適切なプール・サイズを決定する最良の方法は、プールの現在のサイズ、縮小数、拡大数、および待機数をモニターすることです。「スレッド管理」を参照してください。MDBのチューニングは特殊なケースです。第11章「メッセージドリブンBeanのチューニング」を参照してください。
WebLogic Server 9.0より前のリリースの場合、一般的に、プールによって処理されるリクエストの処理に必要と考えられるスレッドの数と接続の数を等しくする必要があります。適切なプール・サイズを確保する最も有効な方法は、プールをモニターし、プールが縮小および拡張していないことを確認することです。「WebLogic 8.1スレッド・プール・モデルを有効にする方法」を参照してください。
プリペアド文キャッシュは、メモリーにコンパイル済SQL文を保持するため、後で同じ文が使用された場合に、データベースとの往復を回避できます。第12章「データ・ソースのチューニング」を参照してください。
トランザクション対応のデータベース・アプリケーションを使用する場合、XAではなく、JDBCデータ・ソースのロギング・ラスト・リソース(LLR)トランザクション・ポリシーの使用を検討してください。LLRの最適化を使用すると、特に2フェーズ・コミット・データベースの挿入、更新、および削除処理など、データベース処理の2PC XAオーバーヘッドの一部が安全に除去されるため、トランザクションのパフォーマンスを大幅に向上することができます。詳細は、第12章「データ・ソースのチューニング」を参照してください。
WebLogic Serverインスタンスが受け入れる接続リクエストの数(それ以上のリクエストは拒否されます)をチューニングできます。この調整可能なパラメータは、主にWebアプリケーションに適用されます。「接続バックログのバッファリングのチューニング」を参照してください。
チャンクは、クライアント側とサーバー側のWebLogic Serverネットワーク・レイヤーが、データのソケットからの読込みおよびソケットへの書込みを行うために使用するメモリーの単位です。サーバー・インスタンスは、これらのチャンクのプールを保持します。リクエストに対して大量のデータを処理するアプリケーションでは、クライアント側とサーバー側の両方でこの値を増やすことによって、パフォーマンスが向上する場合があります。「チャンク・パラメータのチューニング」を参照してください。
可能な限り、CMP EJBのquery-cachingではRead-only同時実行性を、cache-between-transactionsではOptimistic同時実行性を使用してください。これらの2つのオプションでは、EJBコンテナによって提供されるエンティティBeanキャッシュが利用されます。
cache-between-transactionsでのオプティミスティックな同時実行性は、read-mostly Beanに対して最も正常に機能します。これらと読込みの検証を組み合せて使用すると、データの高整合性が保証され、キャッシングのパフォーマンスも向上します。第10章「WebLogic Server EJBのチューニング」を参照してください。
問合せキャッシングはWebLogic Server 9.0以降の機能。EJBコンテナはこの機能によって、読取り専用EJBに対して定義された任意の非主キー・ファインダの結果をキャッシュできます。これらのパラメータはすべて、アプリケーションまたはモジュールのデプロイメント記述子で設定できます。「同時実行性戦略」を参照してください。
同じアプリケーション内で、あるEJBがサーブレットまたはJSPによって呼び出されたり、別のEJBに呼び出される場合は、local-interfacesを使用するか、call-by-referenceセマンティクスを使用して、シリアライゼーションのオーバーヘッドを回避します。次の点に注意してください。
WebLogic Server 8.1より前のリリースでは、call-by-referenceはデフォルトでオンになっています。WebLogic Server 8.1以降のリリースでは、call-by-referenceはデフォルトでオフになっています。call-by-referenceが明示的にオンにされない8.1以降のWebLogic Serverに移行する古いアプリケーションでは、パフォーマンスが低下する場合があります。
この最適化は、異なるアプリケーション間の呼出しには適用されません。
可能なかぎり、eager-relationship-caching (積極的なリレーションシップ・キャッシング)を使用してください。この機能を使用すると、EJBコンテナは、単一のSQL文を使って関連Beanをロードできます。この機能を使用すると、トランザクションの関連Beanをロードするデータベース呼出し数が減少するため、Beanとその関連Beanがそのトランザクションで使用されるものと考えられる場合にパフォーマンスが向上します。第10章「WebLogic Server EJBのチューニング」を参照してください。
セッションの永続性およびセッションを処理する場合、アプリケーションの作業ができるだけ少なくなるようアプリケーションを最適化してください。また、環境およびアプリケーションに合わせてセッション管理戦略を設計する必要もあります。「セッション管理」を参照してください。
メッセージング・ユーザー用に、パフォーマンスを調整可能なパラメータが豊富に提供されています。一般的に、割当てとページングは常に構成する必要があります。次を参照してください:
