WebLogic Server パフォーマンス チューニング ガイド
|
 |
 |
|
以下の節では、WebLogic Server EJB をアプリケーションのニーズに合わせてチューニングする方法について説明します。
weblogic-ejb-jar.xml デプロイメント ファイルには、EJB の同時実行、キャッシング、およびクラスタ化の動作を決定する WebLogic Server 固有のデプロイメント要素が格納されます。このファイルには、利用可能な WebLogic Server リソースを EJB にマップするデプロイメント要素も格納されます。WebLogic Server リソースには、JDBC データ ソースと JDBC 接続プールや JMS 接続ファクトリ、およびデプロイ済みの他の EJB があります。
weblogic-ejb-jar.xml デプロイメント ファイルを変更する方法の詳細については、『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「デプロイメント記述子を編集する」を参照してください。
表 5-1 は、パフォーマンスに影響を与えるweblogic-ejb-jar.xml ファイル パラメータを示しています。
表 5-1 パフォーマンス関連の weblogic-ejb-jar.xml 要素
「データベース ロックの委任」を参照。
「トランザクションのアイソレーション レベルの設定」を参照。
WebLogic Server では、すべてのステートレス セッション Bean クラスに対して EJB のフリー プールが保持されます。weblogic-ejb-jar.xml ファイルの max-beans-in-free-pool 要素は、このフリー プールのサイズを定義します。
この件については、『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「max-beans-in-free-pool」を参照してください。
EJB が作成されると、セッション Bean インスタンスが作成され、ID が与えられます。クライアントが Bean を削除すると、その Bean インスタンスはフリー プールに置かれます。その後 Bean を作成する場合、フリー プールに置かれている直前のインスタンスを再利用することで、オブジェクトの割り当てを回避できます。max-beans-in-free-pool 要素を使用すると、EJB が頻繁に作成および削除される場合のパフォーマンスを向上させることができます。
メッセージの並行処理での必要に応じて、EJB コンテナではメッセージ Bean の新しいインスタンスが作成されます。max-beans-in-pool 要素によって、作成されるインスタンス数に対して絶対的な制限が設定されます。使用可能な実行時リソースに応じて、コンテナでこの設定値がオーバーライドされる場合もあります。
ステートレス セッション Bean およびメッセージ Bean の最高のパフォーマンスを引き出すには、max-beans-in-free-pool 要素のデフォルト値を使用します。デフォルト値を使用すると、できる限り多くのスレッドを使用して Bean を並行して実行できます。
セッション Bean を頻繁に作成し、処理を迅速に行って Bean を解放する場合を除き、セッションの max-beans-in-free-pool パラメータの値は変更しないでください。変更する場合は、フリー プールを 25 ～ 50% 拡張して、パフォーマンスが改善されるかどうかを確認します。オブジェクトの作成が負荷全体の中でわずかな割合しか占めない場合、このパラメータを大きくしてもパフォーマンスは大幅には改善されません。 EJB がデータベースを頻繁に使用するアプリケーションの場合は、このパラメータの値を変更しないでください。
警告 : このパラメータを大きくしすぎると、余計なメモリが消費されます。小さくしすぎると、不必要にオブジェクトが作成されます。このパラメータの変更について疑問がある場合は、値をそのままにしておいてください。
WebLogic Server は、フリー プールを使用してステートレス セッション EJB のパフォーマンスとスループットを高めます。フリー プールには、非バインド ステートレス セッション EJB が格納されます。非バインド EJB インスタンスはステートレス セッション EJB クラスのインスタンスで、メソッド呼び出しを処理しません。
次の図に、WebLogic Server のフリー プールと、ステートレス EJB がフリー プールに出入りするプロセスを示します。点線は、WebLogic Server 側から見た EJB の「状態」を表しています。
図 5-1 ステートレス セッション EJB のライフサイクルを示す WebLogic Server フリー プール
匿名エンティティ Bean (主キー クラスのない Bean) のプールは、ファインダやホーム メソッドの呼び出しおよび他のエンティティ Bean の作成に使用されます。max-beans-in-free-pool 要素は、このプールのサイズも指定します。
数多くのファインダやホーム メソッドを実行している場合や、多くの Bean を作成している場合は、プール内で使用可能な Bean を確保できるよう、max-beans-in-free-pool 要素をチューニングすることもできます。
weblogic-ejb-jar.xml ファイルの initial-beans-in-free-pool 要素を使用すると、起動時のフリー プール内のステートレス セッション Bean インスタンスの数を指定できます。
initial-beans-in-free-pool の値を指定すると、WebLogic Server では、起動時に、指定した数の Bean インスタンスがフリー プールに生成されます。この方法で Bean インスタンスをフリー プールに格納しておくと、リクエストが来てから新しいインスタンスを生成せずに Bean に対する初期リクエストが可能になるため、EJB の初期応答時間が短縮されます。
initial-beans-in-free-pool が定義されていない場合のデフォルト値は 0 です。
『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「initial-beans-in-free-pool」を参照してください。
EJB キャッシュ (Bean が存在するインメモリ スペース) に存在するアクティブな Bean インスタンスの数をコンフィグレーションできます。
weblogic-ejb-jar.xml ファイルの max-beans-in-cache 要素を使用して、メモリに保持可能なこのクラスのオブジェクトの最大数を指定します。max-beans-in-cache の値に達すると、WebLogic Server では、最近クライアントに使用されていない EJB の一部に対してパッシベーションが行われます。また、max-beans-in-cache 要素の値は、EJB を WebLogic Server のキャッシュからいつ削除するかにも影響を与えます。
詳細については、『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「同時方式の選択」を参照してください。
『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「max-beans-in-cache」を参照してください。
過度のパッシベーションとアクティベーションを回避するには、max-beans-in-cache 要素を使用してキャッシュを適切なサイズに設定します。アクティベーションとは、2 次ストレージからメモリに EJB インスタンスを転送することです。パッシベーションとは、メモリから 2 次ストレージに EJB インスタンスを転送することです。max-beans-in-cache の値を大きくしすぎると、メモリが不必要に消費されます。
EJB コンテナでは、キャッシュが一杯になるとパッシベーションが実行されます。 EJB セッション オブジェクトが再び必要になると、コンテナによって Bean がアクティブ化されます。
コンテナは、クライアントまたはサーバの直接の関与を必要とせずに、EJB キャッシュ内の一連のセッション オブジェクトを自動的に管理します。各 EJB の特定のコールバック メソッドは、これらのオブジェクトのパッシベーション (キャッシュへの格納) またはアクティベーション (キャッシュからの取り出し) の方法を定義します。アクティベーションとパッシベーションの回数が多すぎると、EJB キャッシュ内に一連のセッション オブジェクトをキャッシュするというパフォーマンス上のメリットが消えてしまいます (特にアプリケーションで多くのセッション オブジェクトを処理する必要がある場合)。
WebLogic Server では、データベース ロック、オプティミスティック ロック、および排他的ロックのメカニズムがサポートされています。デフォルトであり、EJB 1.1 および EJB 2.0 に対する推奨メカニズムは、データベース ロックです。
データベース ロックによって、エンティティ EJB の同時アクセスの処理速度が向上します。 WebLogic Server コンテナでは、ロック サービスを基盤となるデータベースに委ねることにより、同時アクセスの改善が行われます。委任データベース ロックの場合、排他的ロックとは異なり、基盤データ ストアはより高い粒度で EJB データをロックでき、ほとんどの場合では、さらにデッドロックの検出もできます。
データベース ロックの詳細については、『エンタープライズ JavaBeans (EJB) 』の「同時方式の選択」を参照してください。
weblogic-ejb-jar.xml ファイルの concurrency-strategy 要素を設定することによって、EJB 用に使用するロック メカニズムを指定します。
データへのアクセスは、トランザクションのアイソレーション レベル メカニズムを介して制御されます。トランザクション アイソレーション レベルは、マルチユーザ データベース システムにおいて、複数のインターリーブされるトランザクションが互いを干渉しないようにするレベルを決定します。トランザクションのアイソレーションは、トランザクション データの読み書きを管理するロック プロトコルによって実現されます。 トランザクション データは、「シリアライゼーション」というプロセスでディスクに書き込まれます。 アイソレーション レベルを低くすると、トランザクションのアイソレーションは低くなりますが、データベースの同時接続性を高めることができます。
詳細については、『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』にある、weblogic-ejb-jar.xml ファイルの isolation-level 要素の説明を参照してください。
各アイソレーション レベルの関係とサポートの詳細については、各データベースのマニュアルを参照してください。
表 5-1 は、パフォーマンスに影響を与えるweblogic-cmp-jar.xml ファイル パラメータを示しています。
表 5-2 パフォーマンス関連の weblogic-cmp-jar.xml パラメータ
「リレーションシップ キャッシング」を参照。
「処理の順序付けとバッチ処理」を参照。
「処理の順序付けとバッチ処理」を参照。
「データベース挿入の遅延」を参照。
「フィールド グループの指定」を参照。
WebLogic Server Administration Console では、EJB 実行時のさまざまなモニタ統計が報告されます。それらの統計の多くが EJB のチューニングに役立ちます。 この節では、統計の一部を利用して EJB のパフォーマンスをチューニングする方法について説明します。
Administration Console で統計を表示するには、「EJB のモニタ」を参照してください。
注意 : カスタム モニタ アプリケーションを記述する場合は、関連する実行時 MBean を呼び出すことにより、プログラム的にモニタ統計にアクセスできます。weblogic.management.runtime パッケージの Javadoc を参照してください。
キャッシュ ミス率とは、コンテナがキャッシュ内で Bean を見つけようと試行した回数 (キャッシュ アクセス) に対する、コンテナがキャッシュ内に Bean を見つけられなかった回数 (キャッシュ ミス) の比率です。
キャッシュ ミス率 = (キャッシュ総ミス数 / キャッシュ総アクセス数) * 100
高いキャッシュ ミス率は、キャッシュ サイズが適切に設定されていないことを示している場合があります。アプリケーションで Bean の特定のサブセット (読み取り主キー) が他の Bean よりも頻繁に使用される場合、頻繁に使用される Bean がキャッシュ内に残り、あまり使用されない Bean がリクエストに応じてキャッシュの内と外を循環できるように、キャッシュ サイズを十分な大きさに設定することが理想的です。このような性質を持つアプリケーションの場合、キャッシュの最大サイズを増やすと、キャッシュ ミス率を大幅に下げられる場合があります。
特定の Bean のサブセットを他の Bean よりも頻繁に使用する必要がないアプリケーションの場合、キャッシュの最大サイズを増やしても、キャッシュ ミス率には影響しません。 最も低いキャッシュ ミス率が得られる最大キャッシュ サイズを判断するには、さまざまな最大キャッシュ サイズでアプリケーションをテストすることをお勧めします。また、サーバのメモリの容量は限られているため、キャッシュ サイズを増やす場合は常にトレードオフが伴うことに注意することも重要です。
ロック待機率とは、発行されたロック リクエストの総数に対する、スレッドが Bean のロックを取得するために待機しなければならなかった回数の比率です。
ロック待機率 = (現在の待機数 / 現在のロック エントリ数) * 100
高いロック待機率は、Bean の同時方式が最適ではないことを示している場合があります。アプリケーションに適合している場合、Database または Optimistic の同時方式を使用すると、Exclusive 方式を使用する場合よりも多くの並行処理が可能になり、EJB コンテナ レベルでのロックが不要になります。
通常、トランザクションが継続している間はロックが保持されるため、トランザクションの継続時間を減らすと Bean がより短時間で解放され、その結果ロック待機率を下げることができる場合があります。トランザクションの時間を短縮するには、特別に必要な場合以外は、1 つのトランザクションに多量の作業をグループ化することを避けます。
ロック タイムアウト率とは、ロック マネージャのアクセス数に対する、タイムアウト数の比率です。
ロック タイムアウト率 = (ロック マネージャのタイムアウト総数 / ロック マネージャのアクセス総数) * 100
ロック タイムアウト率は、ロック待機率と密接に関連しています。Bean のロック タイムアウト率を改善する必要がある場合、最初にロック待機率を調べてこの率を下げる対処方法 (同時方式の変更など) を考慮してください。 スレッドが Bean のロックを待機しなければならない回数を削減するかゼロにすることができれば、待機中に発生するタイムアウトの回数も減少するかゼロになります。
また、高いロック タイムアウト率は、トランザクションのタイムアウト値が不適切であることを示している場合もあります。スレッドがロックを待機する最大時間は、現在のトランザクション タイムアウト値と同じです。
トランザクション タイムアウト値が非常に低く設定されていると、スレッドは Bean へのアクセスが可能になるまで待機せずにタイムアウトする場合があります。その場合、Bean の trans-timeout-seconds 値を大きくすると、ロック タイムアウト率を下げることができます。
ただし、trans-timeout-seconds 値を大きくする場合は注意が必要です。この値を大きくすると、貴重なサーバ リソースであるスレッドが長時間 1 つの Bean を待機する場合があります。また、リクエスト時間が長くなり、その結果、タイムアウトまでの待機時間が長くなる場合もあります。
プール ミス率は、プールに Bean をリクエストした総回数に対する、プールに Bean の取得をリクエストしたが利用できる Bean がなかった回数の比率です。
プール ミス率 = (プール総ミス数 / プール総アクセス数) * 100
プール ミス率が高い場合、Bean インスタンスに発生している状況を判断する必要があります。 Bean は、次の 3 つの状況になる場合があります。
EJB の需要を確認する 1 つの方法として、Administration Console に表示される [現在の使用中 Bean 数] および [プールのアイドル Bean 数] を使用する方法があります。一定期間に EJB の需要が急増すると、プールが空になって追加リクエストに対応できなくなるため、多くのプール ミスが表示されます。
EJB の需要が減少して Bean がプールに戻されると、リクエストを処理するために作成された Bean の多くは、プールに収まりきらずに削除されます。 この場合、フリー プールの最大サイズを増やすと、プール ミスの回数を減らすことができる場合があります。この最大サイズを増やすと、ピーク期間中に需要を満たすために作成された Bean がプール内に存続するため、再び需要が増えたときにこれらの Bean を再び使用できるようになります。
Bean 破棄率とは Bean のリクエストの総数に対する、破棄された Bean 数の比率です。
Bean 破棄率 = (破棄総数 / アクセス総数) * 100
Bean の破棄数を減らすには、Bean インスタンスを破棄する必要がある場合以外は、Bean コードから非アプリケーション例外を送出しないことをお勧めします。非アプリケーション例外は、java.rmi.RemoteException 例外 (RemoteException から継承される例外を含む)、あるいは EJB のホーム インタフェースまたはコンポーネント インタフェースのメソッドの throws 句に定義されていない例外のいずれかです。
通常、Bean の破棄の原因となっている例外は、パフォーマンスを低下させている場合や、EJB または EJB で使用されるリソースの問題を示している場合があるため、その例外を特定する必要があります。
プール タイムアウト率とは、行われたリクエストの総数に対する、プールからの Bean を待機していてタイムアウトしたリクエストの比率です。
プール タイムアウト率 = (プール タイムアウトの総数 / プール アクセスの総数) * 100
高いプール タイムアウト率は、フリー プールのサイズが適切に設定されていないことを示している場合があります。max-beans-in-free-pool 設定を使用してフリー プールの最大サイズを増やすと、サービス リクエストに使用できる Bean インスタンスの数が増え、プール タイムアウト率を下げることができる場合があります。
プール タイムアウトの数に影響する別の要因は、Bean に対してコンフィグレーションされているトランザクション タイムアウトです。スレッドがプールからの Bean を待機する最大時間は、Bean のデフォルトのトランザクション タイムアウト値と同じです。weblogic-ejb-jar.xml ファイルの trans-timeout-seconds の設定値を大きくすると、Bean インスタンスが使用可能になるまでのスレッドの待機時間が長くなります。
ただし、この値を大きくする場合は注意が必要です。この値を大きくすると、貴重なサーバ リソースであるスレッドが長時間 1 つの Bean を待機する場合があります。 また、リクエストがタイムアウトするまでの待機時間が長くなるため、リクエスト時間が長くなる場合があります。
トランザクション ロールバック率とは、EJB に関与するトランザクションの総数に対する、ロールバックしたトランザクションの比率です。
トランザクション ロールバック率 = (トランザクション ロールバック総数 / トランザクション総数) * 100
トランザクション ロールバック率が高い場合に原因を調査するには、Administration Console に示されるトランザクション タイムアウト率を最初に調べます。トランザクション ロールバック率が予想よりも高い場合、最初にタイムアウトの問題に対処します。
予想外に高いトランザクション ロールバック率には、いくつかの原因が考えられます。 アプリケーションまたはアプリケーションで使用されるリソースの潜在的な問題を発見するには、トランザクション ロールバックの原因を調査することをお勧めします。
トランザクション タイムアウト率とは、EJB に関与するトランザクションの総数に対する、タイムアウトしたトランザクションの比率です。
トランザクション タイムアウト率 = (トランザクション タイムアウト総数 / トランザクション総数) * 100
不適切なトランザクション タイムアウト値が原因でトランザクション タイムアウト率が高くなる場合があります。たとえば、トランザクション タイムアウトの値が小さすぎると、スレッドが必要な処理を完了する前にトランザクションがタイムアウトする場合があります。トランザクション タイムアウト値を大きくすると、トランザクション タイムアウト数を減らすことができる場合があります。
ただし、この値を大きくする場合は注意が必要です。この値を大きくすると、タイムアウトまでにスレッドが長時間 1 つのリソースを待機する場合があります。また、リクエストがタイムアウトするまでの待機時間が長くなるため、リクエスト時間が長くなる場合があります。
高いトランザクション タイムアウト率の発生には、サーバ リソースのボトルネックなど、多くの原因が考えられます。タイムアウトの原因を特定して問題に対処できるようにするには、トランザクション全体をトレースすることをお勧めします。
アプリケーション レベルのキャッシングを使用すると、1 つのキャッシュを複数のエンティティ Bean で使用するようにコンフィグレーションできます。これは、ユーザビリティとパフォーマンスの問題を解決するのに役立ちます。これまでは、アプリケーションの一部である各エンティティ Bean ごとに別々のキャッシュをコンフィグレーションする必要がありました。アプリケーション レベルのキャッシングの詳細については、「アプリケーションレベルのキャッシングのコンフィグレーション」を参照してください。
バッチ処理による挿入、更新、および削除により、コンテナ管理による永続性 (CMP) Bean の作成における効率が向上します。EJB コンテナが 1 つの SQL 文で CMP Bean での複数回のデータベース操作を実行できるようになり、ネットワークの往復回数が削減されるためです。バッチ処理の詳細については、「処理の順序付けとバッチ処理」を参照してください。
WebLogic Server では、WebLogic Server クラスタ内の EJB を使用するトランザクションのパフォーマンスも向上します。単一のトランザクションが複数の EJB を使用する場合、WebLogic Server は異なるサーバの EJB ではなく、単一の WebLogic Server インスタンスに存在する EJB インスタンスを使用します。この方法を使用すると、トランザクションのネットワーク トラフィックを最小限に抑えることができます。
場合によっては、トランザクションはクラスタ内の複数の WebLogic Server インスタンスに存在する EJB を使用します。これは、すべての EJB がすべての WebLogic Server インスタンスにデプロイされていない混成のクラスタで起こる場合があります。このような場合、WebLogic Server は複数の直接接続ではなく 1 つの多層接続を使用してデータベースにアクセスします。この方法を使うと、リソースの使用量が減り、トランザクションのパフォーマンスが向上します。
しかし、最高のパフォーマンスを得るには、クラスタを同一化する必要があります。つまり、すべての EJB が使用可能なすべての WebLogic Server インスタンスに存在する必要があります。
バージョンとして指定された optimistic カラムを使用して Optimistic 同時方式を使用している場合、主キー カラムとバージョン カラムで構成されるテーブルのインデックスを作成すると、パフォーマンスが向上する可能性があります。
|
|
|
