|
|
以下の節では、WebLogic Server EJB をアプリケーションのニーズに合わせてチューニングする方法について説明します。
RequiresNew トランザクション パラメータの使用は避けてください。RequiresNew を使用すると、現在のすべてのトランザクションが EJB コンテナによってサスペンドされ、新しいトランザクションが開始されます。これは、別のデータベース接続を含む、追加のリソースが割り当てられることを意味します。
以下の節では、EJB キャッシュのチューニング方法について説明します。
EJB コンテナは、weblogic-ejb-jar.xml の max-beans-in-cache パラメータによって指定される数まで、ステートフル セッション Bean をメモリにキャッシュします。このパラメータは、同時ユーザの数と等しくなるように設定する必要があります。これによって、ディスクに対するステートフル セッション Bean のパッシベーションが最小になり、その後のディスクからのアクティベーションのパフォーマンスが向上します。
エンティティ Bean は、EJB コンテナによって、次の 2 つのレベルでキャッシュされます。
エンティティ Bean は、データベースからロードされ、findByPrimaryKey を使って要求されたり、そのトランザクションのキャッシュされた参照から呼び出されると、キャッシュから常に取得されます。非主キー ファインダを使用したエンティティ Bean の取得によって、データベースから Bean の永続的なステートが常に取得されます。
エンティティ Bean インスタンスは、トランザクション間でもキャッシュされます。ただし、デフォルトでは、エンティティ Bean の永続的なステートは、トランザクション間ではキャッシュされません。トランザクション間でのキャッシングを有効にするには、cache-between-transactions パラメータの値を true に設定します。
ステートをキャッシュしても安全でしょうか。これについては、その Bean の同時方式に依存します。エンティティ Bean のキャッシュが本当に役立つのは、cache-between-transactions を安全に true に設定できる場合のみです。ejbActivate() および ejbPassivate() コールバックのコストがかかる場合でも、エンティティ キャッシュ サイズを十分な大きさに保つことが推奨されます。永続的なステートがトランザクションごとに少なくとも 1 回、再ロードされる場合でも、キャッシュ内の Bean は既にアクティブ化されています。キャッシュ サイズの値は、デプロイメント記述子パラメータ max-beans-in-cache によって設定し、キャッシュ ヒット数が最大になるように設定する必要があります。多くの場合、この値は、エンティティ Bean に関連付けられているテーブル内の行数と、Bean に同時にアクセスすると予想されるスレッドの数の積より大きくする必要はありません。
クエリ キャッシングは WebLogic Server 9.0 からの新機能で、これによって、読み込み専用 CMP エンティティ Bean が、任意のファインダの結果をキャッシュすることができます。クエリ キャッシングは、prepared-query ファインダ以外のすべてのファインダに対してサポートされています。クエリ キャッシュは、Bean レベルのキャッシュはもちろん、アプリケーション レベルのキャッシュとなります。キャッシュのサイズは、weblogic-ejb-jar.xml の max-queries-in-cache パラメータによって制限されます。weblogic-cmp-rdbms 記述子ファイル内のファインダレベルのフラグの enable-query-caching を使用して、ファインダの結果をキャッシュするかどうかを指定します。同じ名前のフラグは、weblogic-relationship-role 要素に適用される際に、内部関係ファインダに対して同じ目的を持ちます。クエリは、次の状況で、クエリ キャッシュから削除されます。
エンティティ Bean キャッシュのサイズを使って、クエリ キャッシュのサイズを制限することができます。これを行うには、max-queries-in-cache パラメータを 0 に設定します。これは、対応する EJB が削除されると、クエリがキャッシュから削除されるためです。こうすることで、クエリ キャッシュにおけるロックの競合をある程度回避できる場合がありますが、パフォーマンスの大幅な向上は期待できません。
以下の節では、EJB プールのチューニング方法について説明します。
EJB コンテナは、インスタンスの作成および破棄を回避するため、ステートレス セッション Bean のプールを維持します。このプールは、通常でも便利ですが、ejbCreate() および setSessionContext() メソッドのコストがかかる場合のパフォーマンスにとって、さらに重要です。このプールは、上限値だけでなく、下限値も持ちます。上限値の方がより重要となります。
max-beans-in-free-pool パラメータで指定します。この値は、EJB を同時に呼び出すものと考えられるスレッドの数と等しくする必要があります。あまりにも小さな値を設定すると、同時性に影響します。initial-beans-in-free-pool パラメータで指定します。initial-beans-in-free-pool の値を増やすと、EJB が含まれるアプリケーションのデプロイに費やされる時間が増し、サーバの起動時間に影響します。メリットは、EJB インスタンスの作成コストが実行時にかからない点です。この値をあまりにも高く設定すると、メモリが無駄に消費されます。
MDB のライフサイクルは、ステートレス セッション Bean によく似ています。MDB プールは、ステートレス セッション Bean と同じチューニング パラメータを持ち、チューニング時には同じ要素が適用されます。通常、ほとんどのアプリケーションにおいて、デフォルトの値が適切と考えられています。「メッセージ駆動型 Bean のチューニング」を参照してください。
エンティティ Bean プールには次の 2 つの目的があります。
エンティティ プールには匿名インスタンス (主キーを持たないインスタンス) が格納されます。これらの Bean はまだアクティブでありません (つまり、ejbActivate() がこれらの Bean に対してまだ呼び出されていない) が、EJB コンテキストは設定されています。エンティティ キャッシュから削除されたエンティティ Bean インスタンスは、パッシベーションされ、プールに置かれます。チューニング可能なのは、initial-beans-in-free-pool と max-beans-in-free-pool です。ステートレス セッション Bean や MDB とは異なり、max-beans-in-free-pool には、スレッド数との関係がありません。エンティティ Bean コンストラクタや setEnityContext() メソッドのコストがかかる場合、max-beans-in-free-pool の値を増やす必要があります。
エンティティ Bean では、キャッシングを使ってデータベースとの対話の数を最小限にすることによって、パフォーマンスが最大限向上します。ただし、ほとんどの状況で、トランザクションの範囲外でエンティティ Bean をキャッシュできるようにすることは現実的ではありません。以下の節では、データベースとの対話を安全に最小限に抑えるために使用できる WebLogic Server EJB コンテナ機能について説明します。これらの機能の多くはコンフィグレーション可能です。
積極的なリレーションシップ キャッシュを使用すると、EJB コンテナは、単一の SQL の結合を使って関連エンティティ Bean をロードできます。同じトランザクションが関連 Bean にアクセスする場合にのみ使用します。「リレーションシップ キャッシング」を参照してください。
JDBC バッチ処理は、EJB コンテナにおいてデフォルトでオンにされています。EJB コンテナは、データベースへのラウンド トリップ数を減らすことによってパフォーマンスが向上する単一のバッチでの単純なデータベース操作を自動的に並べ替え、実行します。BEA では、バッチ処理を使用することをお勧めします。
エンティティ EJB が更新されると、EJB コンテナは、実際に変更されたフィールドのみデータベース内で自動的に更新します。その結果、Update 文はより単純になり、Bean が変更されていない場合は、データベースの呼び出しは行われません。さまざまなトランザクションによって、さまざまなフィールドのセットが変更される場合があるため、複数の形式の Update 文が、データベースへの Bean の格納に使用される場合があります。重要なのは、JDBC 接続プールのプリペアド ステートメント キャッシュ サイズを設定する際に使用できる Update 文の種類を把握しておくことです。「プリペアド ステートメントと呼び出し可能ステートメントのキャッシュ」を参照してください。
フィールド グループを使用すると、よく使用されるフィールドを単一のグループに分離できます。グループ内のいずれかのフィールドが、アプリケーションや Bean コードによってアクセスされると、単一の SQL 文を使ってグループ全体がロードされます。このグループは、ファインダと関連付けることもできます。ファインダが呼び出され、finders-load-bean が true の場合、フィールド グループに属するフィールドのみがデータベースからロードされます。つまり、BLOB など、ロードに時間のかかる特定のフィールドが、ほとんどのトランザクションで使用されない場合、フィールド グループから除外できます。同様に、エンティティ Bean に多くのフィールドがあるが、トランザクションではそれらのフィールドのごく一部しか使用されない場合、使用されないフィールドを除外できます。
| 注意: | 同じトランザクションでアクセスされる複数のフィールドを、別々のフィールド グループにコンフィグレーションしないように注意してください。別々のグループにコンフィグレーションすると、同じ Bean をロードするのに 1 つの呼び出しで十分だったところを、複数のデータベース呼び出しが行われます。 |
このフラグを使用すると、EJB コンテナはファインダを実行する前に、変更されたすべてのエンティティ Bean をデータベースにフラッシュします。アプリケーションによって同じエンティティ Bean が複数回変更され、同じトランザクションで非主キー ファインダが途中で実行される場合、データベースに対する更新が複数回行われます。このフラグはデフォルトでオンになっており、EJB の仕様に準拠します。
同じファインダまたは異なるファインダの 2 回の呼び出しによって、同じ Bean インスタンスが返され、ファインダのその 2 回の呼び出しの間にその Bean インスタンスが変更されていたトランザクションがアプリケーションにある場合に、include-updates をオンのままにしておく意味があります。それ以外の場合、このフラグは安全にオフにできます。こうすることで、2 つ目のファインダの実行後に、Bean が再度変更される場合、データベースへの不必要なフラッシュを回避できます。このフラグは、cmp-rdbms 記述子において各ファインダに対して指定します。
このフラグをオフにすると、EJB のメソッド パラメータが値で渡され、シリアライゼーションが伴います。可変で複合型の場合、これは大幅なコスト高になることがあります。以下の場合、優れたパフォーマンスを得るために、この使用を検討してください。
このフラグは、エンティティ EJB だけでなく、すべての EJB に適用されます。また、同じアプリケーションでのサーブレット/JSP と EJB との間の EJB 呼び出しにも適用されます。このフラグはデフォルトでオフになっており、EJB の仕様に準拠します。このフラグは、WebLogic 固有のデプロイメント記述子において Bean レベルで指定します。
Bean レベルのペシミスティックなロックは、Bean のロード時にデータベース ロックを取得することによって、EJB コンテナ内に実装されます。実装されると、各エンティティ Bean に一度にアクセスできるのは、単一サーバの単一トランザクションのみとなります。その他すべてのトランザクションはブロックされ、自身のトランザクションが完了するまで待機します。これは、RDBMS レベルではコスト高となる場合のあるデータベースの高いアイソレーション レベルを使用するかわりの便利な手段です。このフラグは、cmp-rdbms デプロイメント記述子において Bean レベルで指定します。
| 注意: | ロックが排他的ロックでない場合、デッドロックの状態に陥ることがあります。データベース ロックが共有ロックの場合、その RDBMS を使用する際にデッドロックが発生する可能性があります。 |
concurrency-strategy デプロイメント記述子は、同じサーバ インスタンスの複数スレッドによる同じエンティティ Bean への同時アクセスを処理する方法を EJB コンテナに指示します。このパラメータは、以下の 4 つの値のいずれかに設定します。
Exclusive - EJB コンテナは、特定の主キーに対して EJB のインスタンスが 1 つのみ存在するようにし、このインスタンスへのアクセスをシリアライズするコンテナを持つサーバ内のすべての同時トランザクション間でこのインスタンスが共有されます。この同時性の設定では、EJB が頻繁に使用され、同時アクセスの機会が多い場合、通常は優れたパフォーマンスは期待できません。Database - これがデフォルト値で、最もよく使われる同時方式です。EJB コンテナは、データベースへの同時制御を保留します。コンテナは、特定の主キーに対して複数の EJB インスタンスを維持し、各トランザクションは自身のコピーを取得します。データベースの isolation-level と Bean レベルのペシミスティックなロックは、この方式と組み合わせることによって、永続ステートへの同時アクセスを許可すべきかどうかの判断において主要な役割を果たします。cache-between-transactions が true の場合に起こることがありますが、データベースにアクセスする必要がない限り、複数のトランザクションが Bean に同時にアクセスできる点に注意してください。ただし、cache-between-transactions の値を true に設定するのは安全ではなく、Dababase 同時方式では推奨されません。Optimistic - Optimistic 同時方式の目標は、データベースでのロックを最小限に抑える一方で、データの一貫性を提供し続けることです。EJB の永続ステートがほとんど変更されないことが基本前提です。コンテナは、外部トランザクションの isolation-level 設定によってデータベースでロックが取得されないように、ネスト トランザクションの Bean のロードを試行します。コミット時に Bean が変更されている場合、その他のトランザクションによって永続ステートが変更されていないことを確認するために、指定された更新が使用されます。この場合、OptimisticConcurrencyException が送出され、アプリケーションによって処理されます。
この同時方式を使用できる EJB はほとんど変更されないため、cache-between-transactions をオンに設定すると、パフォーマンスが大幅に向上する場合があります。この方式によって、読み込まれているが変更されてはいない Bean のコミット時の検証も可能になります。これを行うには、cmp-rdbms 記述子で、verify-rows パラメータを Read に設定します。これによって、非常に高いデータ一貫性が提供され、同時にデータベースでのロックが最小限に抑えられます。ただし、パフォーマンスはある程度低下します。バージョン カラムを使用してオプティミスティックな検証を実行することをお勧めします。これは、高速で、直後にタイムスタンプがとられ、その後で変更および読み込みが行われるためです。verify-rows が Read に設定されている場合、変更値は適用されません。
オプティミスティックな同時実行性 Bean が、クラスタの一部のあるサーバで変更されると、そのサーバは、OptimisticConcurrencyExceptions を回避するため、その Bean のすべてのインスタンスをクラスタワイドで無効化しようとします。場合によっては、単純に他のサーバに OptimisticConcurrencyException を送出させる方が費用効果が高いこともあります。この場合、 cmp-rdbms 記述子の cluster-invalidation-disabled フラグを設定して、クラスタワイドの無効化をオフにします。
ReadOnly - ReadOnly 値が最もパフォーマンスが高くなります。この値を選択すると、コンテナは、EJB がトランザクショナル非対応であるとみなし、cache-between-transactions を自動的にオンにします。Bean ステートは、コンフィグレーション可能な間隔でデータベースで定期的に更新されるか、Bean がプログラム的に無効化された場合に更新されます。更新間隔によっては、Bean の永続的なステートが無効になる場合があります。ReadOnly は、query-caching を使用できる唯一の同時方式です。「トランザクション間のキャッシング」を参照してください。
WebLogic Server Administration Console では、EJB 実行時のさまざまなモニタ統計が報告されます。それらの統計の多くが EJB のチューニングに役立ちます。この節では、統計の一部を利用して EJB のパフォーマンスをチューニングする方法について説明します。
Administration Console で統計を表示する方法については、Administration Console オンライン ヘルプの「EJB のモニタ」を参照してください。カスタム モニタ アプリケーションを記述する場合、関連する実行時 MBean にアクセスすることによって、JMX または WLST を使って統計のモニタにアクセスできます。『WebLogic Server MBean リファレンス』の「Runtime MBeans」を参照してください。
キャッシュ ミス率とは、コンテナがキャッシュ内で Bean を見つけようと試行した回数 (キャッシュ アクセス) に対する、コンテナがキャッシュ内に Bean を見つけられなかった回数 (キャッシュ ミス) の比率です。
キャッシュ ミス率 = (キャッシュ総ミス数 / キャッシュ総アクセス数) * 100
高いキャッシュ ミス率は、キャッシュ サイズが適切に設定されていないことを示している場合があります。アプリケーションで Bean の特定のサブセット (読み取り主キー) が他の Bean よりも頻繁に使用される場合、頻繁に使用される Bean がキャッシュ内に残り、あまり使用されない Bean がリクエストに応じてキャッシュの内と外を循環できるように、キャッシュ サイズを十分な大きさに設定することが理想的です。このような性質を持つアプリケーションの場合、キャッシュの最大サイズを増やすと、キャッシュ ミス率を大幅に下げられる場合があります。
特定の Bean のサブセットを他の Bean よりも頻繁に使用する必要がないアプリケーションの場合、キャッシュの最大サイズを増やしても、キャッシュ ミス率には影響しません。最も低いキャッシュ ミス率が得られる最大キャッシュ サイズを判断するには、さまざまな最大キャッシュ サイズでアプリケーションをテストすることをお勧めします。また、サーバのメモリの容量は限られているため、キャッシュ サイズを増やす場合は常にトレードオフが伴うことに注意することも重要です。
Exclusive 同時方式を使用する場合、ロック待機率とは、発行されたロック リクエストの総数に対する、スレッドが Bean のロックを取得するために待機しなければならなかった回数の比率です。
ロック待機率 = (現在の待機数 / 現在のロック エントリ数) * 100
高いロック待機率は、Bean の同時方式が最適ではないことを示している場合があります。アプリケーションに適合している場合、Database または Optimistic の同時方式を使用すると、Exclusive 方式を使用する場合よりも多くの並行処理が可能になり、EJB コンテナ レベルでのロックが不要になります。
通常、トランザクションが継続している間はロックが保持されるため、トランザクションの継続時間を減らすと Bean がより短時間で解放され、その結果ロック待機率を下げることができる場合があります。トランザクションの時間を短縮するには、特別に必要な場合以外は、1 つのトランザクションに多量の作業をグループ化することを避けます。
Exclusive 同時方式を使用する場合、ロック タイムアウト率とは、ロック マネージャのアクセス数に対する、タイムアウト数の比率です。
ロック タイムアウト率 = (ロック マネージャのタイムアウト総数 / ロック マネージャのアクセス総数) * 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 つのリソースを待機する場合があります。また、リクエストがタイムアウトするまでの待機時間が長くなるため、リクエスト時間が長くなる場合があります。
高いトランザクション タイムアウト率の発生には、サーバ リソースのボトルネックなど、多くの原因が考えられます。タイムアウトの原因を特定して問題に対処できるようにするには、トランザクション全体をトレースすることをお勧めします。
  
|
