EJB コンテナーの調整
Enterprise JavaBeans (EJB) コンテナー・キャッシュのサイズに影響を与えるアプリケーションを使用する場合、誤ったサイズ設定により、アプリケーションのパフォーマンスが影響を受ける可能性があります。このトピックでは、コンテナー管理対象パーシスタンス (CMP) について説明しますが、EJB 3.x モジュールではエンティティー Bean がサポートされていないことを認識しておくことが重要です。
EJB キャッシュ・サイズ
Tivoli® Performance Viewer をモニターして、EJB コンテナーのキャッシュ ・サイズの設定がご使用のアプリケーションに対して正しく調整されているかどうかを診断します。
アプリケーションでキャッシュを埋めてしまったために除去が引き起こされる場合、Tivoli Performance Viewer には、ejbStores メソッドの非常に高い呼び出し率、およびワークステーション・マシン上で予想を下回るプロセッサー使用率が表示される可能性があります。
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 キャッシュ・サイズは、管理コンソールの
で設定できます。また、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 システム・プロパティーを使用して構成することもできます。

ただし、Java EE 5 以降のモジュールが、Java EE 5 より前のファイルを含み .xmi ファイル名拡張子を使用する アプリケーション内に存在することは可能です。
ibm-webservices-ext.xmi、ibm-webservices-bnd.xmi、ibm-webservicesclient-bnd.xmi、ibm-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 のセッション・タイムアウト設定の 定義に関する情報を参照してください。
<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 も含まれます。
- ステートフル・タイムアウトの XML エレメント
- @StatefulTimeout アノテーション
- ibm-ejb-jar-ext.xml または ibm-ejb-jar-ext.xmi
- com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout システム・プロパティー
- 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 が使用され、プールに入れられるにつれて、インスタンスの数が 増えていきます。
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 次キー・オブジェクトの作成がアプリケーションでどのように処理されるかについて、理解しておく必要があります。
-Dcom.ibm.websphere.ejbcontainer.noPrimaryKeyMutation=true

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

-Dcom.ibm.ws.pm.deferredcreate=true
この最適化のパフォーマンス上の利点は、 アプリケーションによって異なります。EJB アプリケーション・トランザクションが 挿入を徹底して実行する場合、アプリケーションはこの最適化から多くの利益を得ることが可能です。 アプリケーションがほとんど挿入を実行しない場合は、この最適化による利益は 少なくなります。
Dcom.ibm.ws.pm.batch
EJB アプリケーションが単一トランザクション内の複数の CMP Bean にアクセス する場合、更新、挿入、および読み込みなど、Bean 上で実行される操作によって、 データベースに対して発行される操作の数が、CMP Bean 上で実行される 操作と直接対応するようになります。 ご使用のデータベース・システムが更新ステートメントのバッチをサポートしている場合、 このフラグを使用可能にして、単一トランザクション内の 2 つより多い更新が関わる データベースとのすべての対話に関するパフォーマンスを向上させることができます。

-Dcom.ibm.ws.pm.batch=true
この最適化のパフォーマンス上の利点は、 アプリケーションによって異なります。アプリケーションがまったく、あるいはほとんど CMP Bean を更新しない、あるいはトランザクションごとに単一の Bean だけしか更新しない場合は、 パフォーマンス向上は得られません。 アプリケーションがトランザクションごとに複数の Bean を更新する場合は、この パラメーターによってアプリケーション・パフォーマンスが向上します。
データベース | バッチ更新のサポート | オプティミスティック並行性制御を使用したバッチ更新のサポート |
---|---|---|
DB2® | あり | なし |
Oracle | あり | なし |
DB2 Universal Driver | あり | あり |
Informix® | あり | あり |
SQLServer | あり | あり |
Apache Derby | あり | あり |

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

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

'com.ibm.ws.pm.grouppartialupdate=true' and 'com.ibm.ws.pm.batch=true'