| 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 |
|
戻る |
次へ |
WebLogic Server および WebLogic Server アプリケーションのパフォーマンスのチューニングは、複雑で繰り返し実施しなければならない作業です。ここでは、チューニングを始めるにあたり、アプリケーションのパフォーマンスを最適化する際の推奨事項について簡単に説明します。ここで説明するチューニング方法は、ほとんどの WebLogic アプリケーションに適用できます。
予想されるスレッドの利用に対して、同時性を最大化するプール サイズ (JDBC 接続、ステートレス セッション EJB、および MDB のプールなど) を指定します。
WebLogic Server リリース 9.0 以降の場合、サーバ インスタンスでは自動チューニング スレッド プールが使用される。適切なプール サイズを決定する最良の方法は、プールの現在のサイズ、縮小数、拡大数、および待機数をモニタすることです。「スレッド管理」を参照してください。MDB のチューニングは特殊なケースです。「メッセージ駆動型 Bean のチューニング」を参照してください。
WebLogic Server 9.0 より前のリリースの場合、一般的に、プールによって処理される要求の処理に必要と考えられるスレッドの数と接続の数を等しくする必要がある。適切なプール サイズを確保する最も有効な方法は、プールをモニタし、プールが縮小および拡張していないことを確認することです。「WebLogic 8.1 スレッド プール モデルを有効にする方法」を参照してください。
プリペアド ステートメント キャッシュは、メモリにコンパイル済み SQL 文を保持するため、同じ文が後で使用された場合に、データベースとの往復を回避できます。「JDBC アプリケーションのチューニング」を参照してください。
トランザクション対応のデータベース アプリケーションを使用する場合、XA ではなく、JDBC データ ソースのロギング ラスト リソース (LLR) トランザクション ポリシーの使用を検討してください。LLR の最適化を使用すると、特に 2 フェーズ コミット データベースの挿入、更新、および削除処理など、データベース処理の 2PC XA オーバーヘッドの一部が安全に除去されるため、トランザクションのパフォーマンスを大幅に向上することができます。詳細については、「JDBC アプリケーションのチューニング」を参照してください。
WebLogic Server インスタンスが受け入れる接続要求の数 (それ以上の要求は拒否される) をチューニングできます。この調整可能なパラメータは、主に Web アプリケーションに適用されます。「接続バックログのバッファリングのチューニング」を参照してください。
チャンクは、クライアントサイドとサーバサイドの WebLogic Server ネットワーク レイヤが、データのソケットからの読み込みおよびソケットへの書き込みを行うために使用するメモリの単位です。サーバ インスタンスは、これらのチャンクのプールを保持します。要求に対して大量のデータを処理するアプリケーションでは、クライアントサイドとサーバサイドの両方でこの値を増やすことによって、パフォーマンスが向上する場合があります。「チャンク パラメータのチューニング」を参照してください。
可能な限り、CMP EJB の query-caching では Read-only 同時方式を、cache-between-transactions では Optimistic 同時方式を使用してください。これらの 2 つのオプションでは、EJB コンテナによって提供されるエンティティ Bean キャッシュが利用されます。
cache-between-transactions での Optimistic 同時方式は、read-mostly Bean において最高に機能する。これらと読み込みの検証を組み合わせて使用すると、高いデータの一貫性が保証され、キャッシングのパフォーマンスも向上します。「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 がそのトランザクションで使用されるものと考えられる場合にパフォーマンスが向上します。「WebLogic Server EJB のチューニング」を参照してください。
セッションの永続性およびセッションを処理する場合、アプリケーションの作業ができるだけ少なくなるようアプリケーションを最適化してください。また、環境およびアプリケーションに合わせてセッション管理戦略を設計する必要もあります。「セッション管理」を参照してください。
メッセージング ユーザ用に、パフォーマンスを調整可能なパラメータが豊富に提供されています。一般的に、割り当てとページングは常にコンフィグレーションする必要があります。以下を参照してください。
