WebSphere Application Server for z/OS, Version 6.1   
             オペレーティング・システム: z/OS

             目次と検索結果のパーソナライズ化

EJB コンテナーの調整

EJB コンテナー・キャッシュのサイズに影響を与えるアプリケーションを使用する場合、誤ったサイズ設定により、アプリケーションのパフォーマンスが影響を受ける可能性があります。

EJB キャッシュの調整

Monitoring Tivoli Performance Viewer (TPV) は EJB コンテナーのキャッシュ・サイズの設定がご使用のアプリケーションに対して正しく調整されているかを診断する有効な方法です。

アプリケーションがキャッシュを埋めて除去を引き起こす場合は、TPV は呼び出される ejbStores() の大変高いレートおよびアプリケーション・サーバー・マシン上で予想されるよりも低い CPU 使用効率を示す可能性があります。

以下の式の合計が 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) + 
(Number of stateful Session Beans active during typical workload) + 
(Number of stateless SessionBean types used during typical workload)

各部の意味は、次のとおりです。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 start to become more beans in the cache than the cache 
size has been set to. 

Stateful Session Beans are held in the EJB cache until they are removed by the 
application, or 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 being executed on that stateless Session 
Bean. If two or more methods are being executed simultaneously on the same 
stateless Session Bean type, each method executes on its own bean instance, but 
only one cache location is used for all of these instances. 

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

<tuning parameter>
This setting can be found under Servers > Application Servers > serverName > 
         EJB Container > EJB Cache Settings

また、EJB キャッシュ・サイズの調整中に、EJB コンテナー管理スレッド・パラメーターをアプリケーションの必要に合うように調整することができます。 この管理スレッドは、クリーンアップ間隔設定を介して制御されます。 この設定は、WebSphere Application Server 内のデーモン・スレッドがどの程度頻繁にウェイクアップするかを制御し、また Bean インスタンスの数をキャッシュ・サイズ以下に保とうとして、最近使用されていないキャッシュから Bean インスタンスを除去しようとします。 これにより、EJB コンテナーは可能な限り迅速にキャッシュ内に項目を配置し検索することができます。 通常はこの間隔をデフォルトに設定することが最適ですが、この間隔を減少させた方がよい場合もあります。

EJB キャッシュ・トレース・サービスを使用した、EJB キャッシュをさらに詳細な度合いへ調整する方法についての情報は、トレース・サービスを使用する EJB キャッシュのチューニング を参照してください。

EJB コンテナー・プール・サイズ

アプリケーションがプール内のインスタンスの大多数を使用している場合、TPV によって表示されます。 これが発生した場合は、使い果たされたこれらの Bean プールのサイズを増加しなければなりません。 これは JVM のカスタム・プロパティー・タグ内に以下のパラメーターを追加することによって行われます。

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

各部の意味は、次のとおりです。 <application_name> is the J2EE application name as defined in the application 
archive (.ear) file deployment descriptor, for the bean whose pool size is being 
set
<module_name> is the .jar file name of the EJB module, for the bean whose pool size
 is being set,

<bean_name> is the J2EE Enterprise Bean name as defined in the EJB module 
deployment descriptor, for the bean whose pool size is being set

<minSize> is the number of bean instances the container maintains in the pool,
 irrespective of how long the beans have been in the pool (beans greater than this
 number are cleared from the pool over time to optimize memory usage)

<maxSize> is the number of bean instances in the pool where no more bean instances
 are placed in the pool after they are used (that is, once the pool is at this
 size, any additional beans are discarded rather than added into the pool -- 
this ensures the number of beans in the pool has an upper limit so memory usage 
does not grow in an unbounded fashion).

To keep the number of instances in the pool at a fixed size, minSize and maxSize 
can be set to the same number. Note that there is a separate instance pool for 
every EJB type running in the application server, and that every pool starts out
with no instances in it - that is, the number of instances grows as beans are 
used and then placed in the pool. When a bean instance is needed by the container
and no beans are available in the pool, the container creates a new bean 
instance, uses it, then places that instance in the pool (unless there are 
already maxSize instances in the pool).

For example, the statement
-Dcom.ibm.websphere.ejbcontainer.poolSize=ivtApp#ivtEJB.jar#ivtEJBObject=125,1327

would set a minSize of 125 and a maxSize of 1327 on the bean named "ivtEJBObject"
within the ivtEJB.jar file, in the application "ivtApp". 
ivtApp が実際のアプリケーション名に置き換えられると、 ivtEJB.jar はそのプール・サイズを増やす必要のある Bean を含む jar によって置き換えられ、 ivtEJBObject がプール・サイズを増やすべき Enterprise Bean の Bean 名 になります。 125,1327 は、プール内に保留される Bean の最小数および最大数です。 これらはプールからの除去がこれ以上発生しないように設定されるべきで、ほとんどの場合、プールの増加および縮小が起こらないためにメモリーが十分にある場合は等しく設定されるべきです。

EJB コンテナー 1 次キー突然変異

アプリケーション開発者および管理者は、アプリケーションがどのように WebSphere Application Server 内のコンテナー管理パーシスタンス (CMP) Bean および Bean 管理パーシスタンス (BMP) Bean によって使用される 1 次キー・オブジェクトの作成を処理するかについて、良いアイデアを持たなければなりません。 IBM EJB コンテナーは、Entity Bean の 1 次キーを、パフォーマンスを最適化するために多くの内部データ構造内で ID として使用します。 しかし、EJB コンテナーはこれらの 1 次キー・オブジェクトを最初の Bean へのアクセスでコピーし、アプリケーションが 1 次キーを変更または変化させた場合に内部構造の一貫性を保持するするように、内部キャッシュ内で保管されたオブジェクトがアプリケーション内で使用されたオブジェクトと分離されていることを確認しなければなりません。

アプリケーションが作成のために使用されるどの 1 次キーも変化させず、また作成後に Entity Bean にアクセスしない場合は、特別なフラグが使用され、EJB コンテナーは 1 次キー・オブジェクトのコピーをスキップすることができ、従って CPU サイクルが節約されパフォーマンスが向上します。 この手段は、以下の -D プロパティーを JVM カスタム・プロパティー・フィールドに追加することによって、 お客様自身の責任で 使用可能にできます。

<tuning parameter>
-Dcom.ibm.websphere.ejbcontainer.noPrimaryKeyMutation=true
この最適化のパフォーマンス上の利点は、 アプリケーションによって異なります。アプリケーションがプリミティブ型の Enterprise Bean の 1 次キーを使用している場合は、これらのオブジェクトは既に不変で、コピー手段もこのことを考慮に入れているので、利益はありません。 しかし、アプリケーションが多くの複合 1 次キー (すなわち、1 次キーまたは複数のフィールドの And オブジェクト) を使用している場合、このパラメーターにより大きな改善を得ることができます。

EJB 作成上のパーシスタンス・マネージャーの据え置き挿入

IBM パーシスタンス・マネージャーは、EJB コンテナーによって使用されて、CMP Entity Bean からデータベースへ、データを保管します。 ejbCreate() メソッドを呼び出すことによって Entity Bean を作成する場合、パーシスタンス・マネージャーはデフォルトで、即時にデータベース内の 1 次キーのみで空の行を挿入します。 ほとんどの場合、アプリケーションは Bean を作成した後で、作成された Bean 内、または同じトランザクション内のその他の Bean 内のフィールドを変更します。 ユーザーがデータベースへの挿入をトランザクションの終了まで延期し、 データベースへの片道トリップを除去したい場合は、JVM カスタム・プロパティー・フィールド内で この -D フラグを設定することができます。 データはそれでもデータベース内に挿入され、一貫性は維持されています。

<tuning parameter>
-Dcom.ibm.ws.pm.deferredcreate=true
この最適化のパフォーマンス上の利点は、 アプリケーションによって異なります。EJB アプリケーション・トランザクションが挿入を非常に多く実行する場合、アプリケーションはこの最適化から多くの利益を得ることが可能です。 アプリケーションがほとんど挿入を実行しない場合は、この最適化による利益はかなり少なくなるでしょう。

EJB 更新上のパーシスタンス・マネージャーのデータベース・バッチ

EJB アプリケーションが単一トランザクション内の複数の CMP Bean にアクセスする場合、Bean (更新、挿入、読み込み) 上で実行されるオペレーションによって、データベースに発行されるオペレーションの数が直接、CMP Bean 上で実行されるオペレーションと対応します。 ご使用のデータベース・システムが更新ステートメントのバッチをサポートしている場合、このフラグを使用可能にして、すべての対話上で単一トランザクション内の 2 つ以上の更新に関わるデータベースと使用して、パフォーマンスを向上させることができます。 このフラグによって、パーシスタンス・マネージャーは、すべての更新ステートメントを、あとでデータベースに発行される単一バッチ・ステートメントに追加します。 これによって、往復のトリップがデータベースに保管され、従ってパフォーマンスが向上します。 単一トランザクション内の複数の CMP Bean の更新の振る舞いがそのアプリケーションで公開されること、 およびデータベースでバッチ更新がサポートされることを、ユーザーが知っている場合は、 この -D フラグを JVM カスタム・プロパティー・フィールド内に設定することもできます。

<tuning parameter>
-Dcom.ibm.ws.pm.batch=true
この最適化のパフォーマンス上の利点は、 アプリケーションによって異なります。アプリケーションがまったく、あるいはめったに CMP Bean を更新しないか、またはトランザクションごとに単一の Bean しか更新しない場合は、パフォーマンス向上はありません。 アプリケーションがトランザクションごとに複数の Bean を更新する場合は、このパラメーターによってご使用のアプリケーション・パフォーマンスが向上します。
次の表に、バッチ更新をサポートするバックエンド・データベースの一覧を示します。
表 1.
データベース バッチ更新のサポート オプティミスティック並行性制御を使用したバッチ更新のサポート
DB2 はい いいえ
Oracle はい いいえ
DB2 Universal Driver はい はい
Informix はい はい
SQLServer はい はい
Cloudscape はい はい
注: OCC を使用したバッチ更新は、アクセス・インテントで指定されている場合でも、これをサポートしていないデータベースに対しては実行できません。

パーシスタンス・マネージャー・キャッシュの調整

パーシスタンス・マネージャーでは 2 つの異なるタイプのキャッシング・メカニズムが使用可能です。レガシー・キャッシュ2 レベル・キャッシュ です。 通常、2 レベル・キャッシュでは、このモードの最適化により、レガシー・キャッシュよりもパフォーマンスが向上します。 デフォルトはレガシー・キャッシュですが、2 レベル・キャッシュをお勧めします。 この構成は、システム・プロパティーで次のように設定します。
com.ibm.ws.pm.useLegacyCache=false

パーシスタンス・マネージャー部分更新の調整

部分更新フィーチャーにより、特定のシナリオでエンタープライズ Bean を使用するアプリケーションのパフォーマンスが向上します。 パーシスタンス・マネージャーでは 2 つの異なるタイプのキャッシング・メカニズムが使用可能です。レガシー・キャッシュと 2 レベル・キャッシュです。 通常、2 レベル・キャッシュでは、このモードの最適化により、レガシー・キャッシュよりもパフォーマンスが向上します。 バッチ更新と部分更新の両方を実行する必要があるアプリケーションでは、 両方の利点を活かすために、 以下のシステム・プロパティーを構成する必要があります。
‘com.ibm.ws.pm.grouppartialupdate=true’ および ‘com.ibm.ws.pm.batch=true’




関連概念
EJB コンテナー
関連タスク
アプリケーション・サービス提供環境のチューニング
EJB コンテナーの管理
タスクの概説: アプリケーションでのエンタープライズ Bean の使用
トレース・サービスを使用する EJB キャッシュのチューニング
参照トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 9:12:22 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/zseries/ae/rprf_ejbcontainer.html