EJB コンテナーの調整

Enterprise JavaBeans (EJB) コンテナー・キャッシュのサイズに影響を与えるアプリケーションを使用する場合、誤ったサイズ設定により、アプリケーションのパフォーマンスが影響を受ける可能性があります。このトピックでは、コンテナー管理対象パーシスタンス (CMP) について説明しますが、EJB 3.x モジュールではエンティティー Bean がサポートされていないことを認識しておくことが重要です。

EJB キャッシュ・サイズ

Tivoli® Performance Viewer をモニターして、EJB コンテナーのキャッシュ ・サイズの設定がご使用のアプリケーションに対して正しく調整されているかどうかを診断します。

アプリケーションでキャッシュを埋めてしまったために除去が引き起こされる場合、Tivoli Performance Viewer には、ejbStores メソッドの非常に高い呼び出し率、およびワークステーション・マシン上で予想を下回るプロセッサー使用率が表示される可能性があります。

以下の式の結果が 2000 以上になる場合、Enterprise Bean を使用するすべてのアプリケーションでは、この設定をデフォルト値から調整する必要があります。
EJB_Cache_Size = (Largest number of Option B or C entity beans enlisted in a 
transaction * maximum number of concurrent transactions) + 
(Largest number of unique Option A entity beans expected to be accessed during 
typical application workload) + 
(標準的なワークロード中にアクティブなステートフル・セッション Bean の数) +
(標準的なワークロード中に使用されるステートレス・セッション Bean タイプの数)

各部の意味は、次のとおりです。Option B and C entity beans are only held in the EJB cache during the lifetime 
of the transaction they are enlisted in. Therefore, the first term in the formula 
computes the average EJB cache requirements for these types of beans.

Option A entity beans are held in the EJB cache indefinitely, and are only removed
 from the cache if there starts to become more beans in the cache than the cache
size has been set to. 
アプリケーションが読み取り専用 Bean を使用する場合、この調整の計算においては、それらをオプション A の Bean とみなしてください。

Stateful session beans are held in the EJB cache until they are removed by the 
application, or until their session timeout value is reached.

Only a single stateless session bean instance for each EJB type is held in the 
cache during the time any methods are running on that stateless session 
bean. If two or more methods are being implemented simultaneously on the same 
stateless session bean type, each method runs on its own bean instance, but 
only one cache location is used for all of these instances. 

この式では、アプリケーション・サーバー内で同時にアクティブなエンタープライズ Bean の最大数の上限が計算されます。 EJB コンテナーのキャッシュは、パフォーマンスの最適化のためにこれらすべての Bean を 含むように構築されているので、このキャッシュ・サイズを上の式で算出された数よりも 大きくなるように設定すると、最良のパフォーマンスが得られます。

EJB キャッシュ・サイズは、管理コンソールの「サーバー」 > 「サーバー・タイプ」 > 「WebSphere Application Server」 > server_name > 「EJB コンテナー設定」 > 「EJB キャッシュ設定」で設定できます。

また、EJB キャッシュ・サイズの調整中に、EJB コンテナー管理スレッド・パラメーターをアプリケーションの必要性に合うように調整することもできます。この管理スレッドは、「クリーンアップ間隔」設定を介して制御されます。この設定によって、製品内のデーモン・スレッドが、Bean インスタンスの数をキャッシュ・サイズ よりも低い数値に保とうとして、キャッシュから最近使用されていない Bean インスタンスの除去を 試行する頻度を制御します。 この動作により、EJB コンテナーは、確実に、キャッシュ内に可能な限り迅速に項目を配置し参照できるように なります。 この間隔はデフォルト設定のままにしてください。ただし、この間隔の縮小を検討した方がよい 場合もあります。

EJB キャッシュ・トレース・サービスを使用して EJB キャッシュを調整する方法について詳しくは、EJB キャッシュの調整およびトレース・サービスの使用についての情報を参照してください。

EJB ステートフル・セッション Bean の調整

ステートフル・セッション Bean タイムアウトの構成は、WebSphere® Application Server のバージョンに合わせて、異なる有効範囲を使用したいろいろな方法があります。

WebSphere Application Server バージョン 6.1 以前では、ibm-ejb-jar-ext.xmi ファイルを使用した Bean ごとのステートフル・セッション Bean タイムアウトの構成がサポートされます。

WebSphere Application Server バージョン 7.0 では、ibm-ejb-jar-ext.xmi ファイル (EJB 2.x モジュールの場合)、および ibm-ejb-jar-ext.xml ファイル (EJB 3.x モジュールの場合) を使用した Bean ごとのステートフル・セッション Bean タイムアウトの構成がサポートされます。

WebSphere Application Server バージョン 8.x では、ibm-ejb-jar-ext.xmi ファイル (EJB 2.x モジュールの場合) および ibm-ejb-jar-ext.xml ファイル (EJB 3.x モジュールの場合)、さらにステートフル・タイムアウト XML エレメントと @StatefulTimeout アノテーションを使用した Bean ごとのステートフル・セッション Bean タイムアウトの構成もサポートされます。さらに、サーバー全体 (グローバル) のステートフル・セッション・タイムアウト値を、com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout システム・プロパティーを使用して構成することもできます。

サポートされる構成 サポートされる構成: IBM® 拡張ファイル およびバインディング・ファイルの場合、.xmi または .xml ファイル名拡張子は、Java EE 5 より前のアプリケーションまたはモジュールを使用しているか、 あるいは Java™ EE 5 以降のアプリケーションまたは モジュールを使用しているかによって異なります。IBM 拡張 ファイルまたはバインディング・ファイルは、ibm-*-ext.xmi または ibm-*-bnd.xmi という名前です。 ここで * は拡張ファイルまたはバインディング・ファイルのタイプ (app、application、ejb-jar、 または web など) です。以下の条件が適用されます。
  • バージョン 5 より前の Java EE バージョンを使用するアプリケーションまたはモジュールの場合、ファイル拡張子は .xmi でなければなりません。
  • Java EE 5 以降を使用するアプリケーションまたはモジュールの場合、ファイル拡張子は .xml でなければなりません。.xmi ファイルがアプリケーションまたはモジュールに組み込まれている場合、.xmi ファイルは無視されます。

ただし、Java EE 5 以降のモジュールが、Java EE 5 より前のファイルを含み .xmi ファイル名拡張子を使用する アプリケーション内に存在することは可能です。

ibm-webservices-ext.xmiibm-webservices-bnd.xmiibm-webservicesclient-bnd.xmiibm-webservicesclient-ext.xmi、 および ibm-portlet-ext.xmi ファイルは、引き続き .xmi ファイル拡張子 を使用します。

sptcfg

ステートレス・セッション Bean には、タイムアウト値は存在しません。この Bean には、会話状態は存在せず、また、この Bean は、特定のクライアント専用になることもないためです。

Rational® Application Developer を使用して ibm-ejb-jar-ext.xmi ファイルを更新できます。このファイルを使用すると、EJB 2.x モジュールの Bean のステートフル・セッション・タイムアウト値を構成できます。詳しくは、Rational Application Developer のインフォメーション・センターで Bean のセッション・タイムアウト設定の 定義に関する情報を参照してください。

例えば、15 分のステートフル・セッション・タイムアウト値を設定するために生成された XMI コードは次のとおりです。
<ejbExtensions xmi:type="ejbext:SessionExtension" xmi:id="SessionExtension_1"
  timeout="15">

EJB 3.x モジュールの Bean のステートフル・セッション・タイムアウトを設定できるように ibm-ejb-jar-ext.xml ファイルを変更することができます。例えば、myBean Bean のステートフル・セッション・タイムアウト値を 15 分に設定するためのコードは次のとおりです。

<ejbExtensions xmi:type="ejbext:SessionExtension" xmi:id="SessionExtension"
  timeout="15">
    <enterpriseBean xmi:type="ejb:Session" href="META-INF/ejb-jar.xml#MyBean"/>
 </ejbExtensions>

@StatefulTimeout アノテーションを使用して、ステートフル・セッション Bean タイムアウトを構成できます。@StatefulTimeout アノテーションには、タイムアウト時間を示す必須値パラメーター、およびオプションの単位パラメーターを使用できます。オプションの単位パラメーターを指定しない場合には、デフォルトの単位は分です。 @StatefulTimeout アノテーションは、EJB 3.1 の一部として導入されました。

例えば、@StatefulTimeout アノテーションを使用すると、次のように 100 秒のタイムアウト値を宣言できます。

@StatefulTimeout(value=100 unit=java.util.concurrent.TimeUnit.SECONDS)

ejb-jar.xml デプロイメント記述子のステートフル・タイムアウト XML エレメントを使用して、ステートフル・セッション Bean タイムアウトを構成できます。ステートフル・タイムアウトのエレメントは、EJB 3.1 の一部として導入されました。

例えば、次のように 100 秒のタイムアウト値を設定できます。

<stateful-timeout>
     <timeout>100</timeout>
     <unit>Seconds</unit>
</stateful-timeout>

@StatefulTimeout アノテーションおよびステートフル・タイムアウト XML エレメントは、Bean ごとのタイムアウト値を宣言するための仕様定義されたメカニズムで、EJB 3.1 から導入されました。EJB 3.1 より以前では、Bean ごとにステートフル・セッション・タイムアウト値を宣言する仕様定義された手段がありませんでした。ステートフル・タイムアウトの XML エレメントまたは @StatefulTimeout アノテーションを使用する際、値 -1 は Bean がタイムアウトにならないことを、値 0 は Bean が即座に除去できることを意味します。

com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout システム・プロパティーを使用して、ステートフル・セッション Bean タイムアウトをグローバル (サーバー全体) で構成できます。com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout の時間単位は分です。指定値は 0 以上でなければならず、無効値が指定されると、代わりにデフォルト値の 10 分が使用されます。グローバル・タイムアウト値は、XML またはアノテーションを使用して構成できません。グローバル・タイムアウト値は、サーバーで実行中のすべてのステートフル・セッション Bean に適用されます。これには、EJB 2.x モジュールまたは EJB 3.x モジュール内のステートフル・セッション Bean も含まれます。

WebSphere Application Server バージョン 8.x では、Bean レベルのステートフル・タイムアウト設定が、サーバー全体のタイムアウト設定より優先されます。サーバー全体のタイムアウト設定は、デフォルト (未指定) のタイムアウトより優先されます。次の優先順位を使用して、WebSphere Application Server バージョン 8.x で実行中の Bean に対するステートフル・セッション・タイムアウト値が決まります。
  1. ステートフル・タイムアウトの XML エレメント
  2. @StatefulTimeout アノテーション
  3. ibm-ejb-jar-ext.xml または ibm-ejb-jar-ext.xmi
  4. com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout システム・プロパティー
  5. Bean レベルまたはサーバー全体のタイムアウト値が明示的に指定されていない場合は、デフォルト値である 10 分が適用されます。

Dcom.ibm.websphere.ejbcontainer.poolSize

アプリケーションが、プール内の大半の Bean インスタンスを使用している場合、これは Tivoli Performance Viewer に表示されます。 ほとんどの Bean インスタンスが使用されている場合、使い果たされたこれらの Bean プールのサイズを、JVM のカスタム・プロパティー・タグでこのパラメーターを追加することで、増やしてください。例を次に示します。

-Dcom.ibm.websphere.ejbcontainer.poolSize=<application_name>#<module_name>#
<enterprisebean_name>=<minSize>,<maxSize>

各部の意味は、次のとおりです。

<application_name> のエレメントは、プール・サイズを設定する Bean の、 エンタープライズ・アーカイブ (EAR) ファイル・デプロイメント記述子に定義された Java EE アプリケーション名です。

<module_name> のエレメントは、プール・サイズを設定する Bean の EJB モジュールの Java アーカイブ (JAR) ファイル名です。

<bean_name> のエレメントは、プール・サイズを設定する Bean の、EJB モジュール・デプロイメント記述子に定義された Java EE エンタープライズ Bean 名です。

<minSize> エレメントは、コンテナーがプールに保持する Bean インスタンスの 数です。Bean がプールに保持されていた時間とは無関係です (この数を超える Bean は 時間の経過とともにプールから消去され、 メモリーの使用量が最適化されます)

<maxSize> のエレメントは、それ以上の Bean は使用後にプールに入れないという、プール内の Bean インスタンスの数です (つまり、プールがこのサイズになったら、それ以降の Bean はプールに追加されずに破棄されます。これにより、プール内の Bean 数に上限が設定され、メモリー使用量が無制限に大きくなりません)。

プール内のインスタンス数を固定サイズにするには、minSize と maxSize のエレメントに 同じ値を設定します。アプリケーション・サーバーで実行される各 EJB タイプごとに、 別々のインスタンス・プールが存在します。それぞれのプールは、インスタンスを 含まずに開始します。Bean が使用され、プールに入れられるにつれて、インスタンスの数が 増えていきます。

コンテナーが Bean インスタンスを必要な場合にプールに使用可能な Bean がないとき、コンテナーは Bean インスタンスを作成して使用した後、プール内のインスタンス数が maxSize に達していなければ、そのインスタンスをプールに入れます。例えば、ステートメント
Dcom.ibm.websphere.ejbcontainer.poolSize=ivtApp#ivtEJB.jar#ivtEJBObject=125,1327  
は、アプリケーション ivtApp で、ivtEJB.jar ファイル内の ivtEJBObject という名前の Bean について、minSize を 125 に、maxSize を 1327 に設定します。

アプリケーション ivtApp が実際のアプリケーション名で置き換えられ、ivtEJB.jar ファイルはそのプール・サイズを増やす 必要のある Bean を含む JAR ファイルで置き換えられ、ivtEJBObject は、プール・サイズを増やす必要のあるエンタープライズ Bean の Bean 名 になります。 プールに保持される Bean の最小数は、125 です。プールに保持される Bean の最大数は、1327 です。 これらはプールからの除去がこれ以上発生しないように設定してください。 多くの場合、プールの増加および縮小が起こらないためにメモリーが十分にある場合は 等しく設定する必要があります。

Dcom.ibm.websphere.ejbcontainer.noPrimaryKeyMutation

製品内の CMP Bean および Bean 管理パーシスタンス (BMP) Bean によって使用される 1 次キー・オブジェクトの作成がアプリケーションでどのように処理されるかについて、理解しておく必要があります。

EJB コンテナーは、エンティティー Bean の 1 次キーを内部データ構造内で ID として使用し、パフォーマンスを最適化します。 ただし、EJB コンテナーでは、Bean への最初のアクセス時にこれらの 1 次キー・オブジェクトを コピーして、内部キャッシュ内に保管されたオブジェクトがアプリケーション内で使用された オブジェクトと分離されていることを確認する必要があります。 このプロセスは、アプリケーションが 1 次キーを変更または変化させた場合に、内部構造の整合性を保持 するために起こります。 アプリケーションで、エンティティー Bean の作成とその作成後に行われるそれらエンティティー Bean へのアクセスに使用されるどの 1 次キーも変化させない場合は、特別なフラグを使用することで、EJB コンテナーで 1 次キー・オブジェクトのコピーを確実にスキップできるようにします。これによって、プロセッサー・サイクルが節約されて、パフォーマンスが向上します。このメカニズムは、以下の –D プロパティーを JVM カスタム・プロパティー・フィールドに追加することによって、お客様自身の責任で使用可能にできます。
-Dcom.ibm.websphere.ejbcontainer.noPrimaryKeyMutation=true
サポートされる構成 サポートされる構成: エンティティー Bean は EJB 3.x 以降のモジュールではサポートされていません。sptcfg

この最適化のパフォーマンス上の利点は、 アプリケーションによって異なります。アプリケーションで、エンタープライズ Bean の 1 次キーにプリミティブ型を 使用している場合は、これらのオブジェクトは既に不変になっており、またコピーのメカニズムでもこのことが考慮されているため、利益はありません。 ただし、アプリケーションで多くの複合 1 次キー、すなわち、1 次キーまたは複数 フィールドのオブジェクトを使用している場合、このパラメーターでより大きな改善を 得ることができます。

Dcom.ibm.ws.pm.deferredcreate

パーシスタンス・マネージャーは、CMP エンティティー Bean からデータベースにデータを保管する際に EJB コンテナーによって使用されます。

ejbCreate メソッドを呼び出すことによってエンティティー Bean を作成する場合、デフォルトの設定によって、 パーシスタンス・マネージャーが即時にデータベース内の 1 次キーのみで 空の行を挿入します。 大部分の場合、Bean を作成した後に、その作成された Bean 内、または同じトランザクション内のその他の Bean 内のフィールドを変更する必要があります。データベースへの挿入をトランザクションの終了まで延期し、データベースへの片道トリップを除去する場合は、JVM カスタム・プロパティー・フィールド内にこの –D フラグを設定します。データはデータベースに挿入され、整合性が維持されます。
サポートされる構成 サポートされる構成: エンティティー Bean は EJB 3.x 以降のモジュールではサポートされていません。sptcfg
-Dcom.ibm.ws.pm.deferredcreate=true

この最適化のパフォーマンス上の利点は、 アプリケーションによって異なります。EJB アプリケーション・トランザクションが 挿入を徹底して実行する場合、アプリケーションはこの最適化から多くの利益を得ることが可能です。 アプリケーションがほとんど挿入を実行しない場合は、この最適化による利益は 少なくなります。

Dcom.ibm.ws.pm.batch

EJB アプリケーションが単一トランザクション内の複数の CMP Bean にアクセス する場合、更新、挿入、および読み込みなど、Bean 上で実行される操作によって、 データベースに対して発行される操作の数が、CMP Bean 上で実行される 操作と直接対応するようになります。 ご使用のデータベース・システムが更新ステートメントのバッチをサポートしている場合、 このフラグを使用可能にして、単一トランザクション内の 2 つより多い更新が関わる データベースとのすべての対話に関するパフォーマンスを向上させることができます。

サポートされる構成 サポートされる構成: エンティティー Bean は EJB 3.x 以降のモジュールではサポートされていません。sptcfg
このフラグを使用すると、すべての更新ステートメント を、データベースに対して発行される単一バッチ・ステートメントに追加するパーシスタンス・マネージャーがサポートされます。 この処理によって、データベースへの往復のトリップが省かれるため、パフォーマンスが向上します。 アプリケーションが単一トランザクション内で複数の CMP Bean を更新するという動作をし、しかもデータベースでバッチ更新をサポートするとわかっている場合は、この –D フラグを JVM カスタム・プロパティー・フィールド内に設定できます。例を次に示します。
-Dcom.ibm.ws.pm.batch=true

この最適化のパフォーマンス上の利点は、 アプリケーションによって異なります。アプリケーションがまったく、あるいはほとんど CMP Bean を更新しない、あるいはトランザクションごとに単一の Bean だけしか更新しない場合は、 パフォーマンス向上は得られません。 アプリケーションがトランザクションごとに複数の Bean を更新する場合は、この パラメーターによってアプリケーション・パフォーマンスが向上します。

以下の表に、バッチ更新をサポートするバックエンド・データベースの一覧を示します。
表 1. バッチ更新をサポートするバックエンド・データベース. 以下の表に、バッチ更新をサポートするバックエンド・データベースの一覧を示します。
データベース バッチ更新のサポート オプティミスティック並行性制御を使用したバッチ更新のサポート
DB2® あり なし
Oracle あり なし
DB2 Universal Driver あり あり
Informix® あり あり
SQLServer あり あり
Apache Derby あり あり
サポートされる構成 サポートされる構成: OCC を使用したバッチ更新は、アクセス・インテントで指定されている場合でも、これをサポートしていないデータベースに対しては実行できません。sptcfg

com.ibm.ws.pm.useLegacyCache

製品が javax.rmi.CORBA.UtilDelegate インターフェースの実装に使用する Java クラスの名前を指定します。

サポートされる構成 サポートされる構成: エンティティー Bean は EJB 3.x 以降のモジュールではサポートされていません。sptcfg
パーシスタンス・マネージャーでは、レガシー・キャッシュ2 レベル ・キャッシュ の 2 つのタイプのキャッシング・メカニズムを利用します。 通常、2 レベル・キャッシュは、このモードでの最適化によって、レガシー・キャッシュよりも効率的です。 デフォルトはレガシー・キャッシュですが、2 レベル・キャッシュをお勧めします。 この構成は、システム・プロパティーで次のように設定します。
com.ibm.ws.pm.useLegacyCache=false

com.ibm.ws.pm.grouppartialupdate and com.ibm.ws.pm.batch

部分更新フィーチャーにより、特定のシナリオでエンタープライズ Bean を使用するアプリケーションのパフォーマンスが向上します。 パーシスタンス・マネージャーでは、レガシー・キャッシュ2 レベル・キャッシュ の 2 つのタイプのキャッシング・メカニズムが使用可能です。通常、2 レベル・キャッシュでは、このモードでの最適化といった理由から、レガシー・キャッシュよりも パフォーマンスが向上します。

サポートされる構成 サポートされる構成: エンティティー Bean は EJB 3.x 以降のモジュールではサポートされていません。sptcfg
バッチ更新と部分更新の両方を実行する必要があるアプリケーションでは、双方の利点を得るために、以下のシステム・プロパティーを構成する必要があります。
'com.ibm.ws.pm.grouppartialupdate=true' and 'com.ibm.ws.pm.batch=true'

トピックのタイプを示すアイコン 参照トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rprf_ejbcontainer
ファイル名:rprf_ejbcontainer.html