|
|
WebLogic Server および WebLogic Server アプリケーションのパフォーマンスのチューニングは、複雑で繰り返し実施しなければならない作業です。ここでは、チューニングを始めるにあたり、アプリケーションのパフォーマンスを最適化する際の推奨事項について簡単に説明します。ここで説明するチューニング方法は、ほとんどの WebLogic アプリケーションに適用できます。
予想されるスレッドの利用に対して、同時性を最大化するプール サイズ (JDBC 接続、ステートレス セッション EJB、および MDB のプールなど) を指定します。
プリペアド ステートメント キャッシュは、メモリにコンパイル済み 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 キャッシュが利用されます。
同じアプリケーション内で、ある EJB がサーブレットまたは JSP によって呼び出されたり、別の EJB に呼び出される場合は、local-interfaces を使用するか、call-by-reference セマンティクスを使用して、シリアライゼーションのオーバーヘッドを回避します。以下の点に注意してください。
可能な限り、eager-relationship-caching (積極的なリレーションシップ キャッシュ) を使用してください。この機能を使用すると、EJB コンテナは、単一の SQL 文を使って関連 Bean をロードできます。この機能を使用すると、トランザクションの関連 Bean をロードするデータベース呼び出し数が減じられるため、Bean とその関連 Bean がそのトランザクションで使用されるものと考えられる場合にパフォーマンスが向上します。「WebLogic Server EJB のチューニング」を参照してください。
セッションの永続性およびセッションを処理する場合、アプリケーションの作業ができるだけ少なくなるようアプリケーションを最適化してください。また、環境およびアプリケーションに合わせてセッション管理戦略を設計する必要もあります。「セッション管理」を参照してください。
メッセージング ユーザ用に、パフォーマンスを調整可能なパラメータが豊富に提供されています。一般的に、割り当てとページングは常にコンフィグレーションする必要があります。以下を参照してください。
|