EJB コンテナー・キャッシュのサイズに影響を与えるアプリケーションを使用する場合、誤ったサイズ設定により、アプリケーションのパフォーマンスが影響を受ける可能性があります。
Monitoring Tivoli Performance Viewer (TPV) は EJB コンテナーのキャッシュ・サイズの設定がご使用のアプリケーションに対して正しく調整されているかを診断する有効な方法です。
アプリケーションがキャッシュを埋めて除去を引き起こす場合は、TPV は呼び出される ejbStores() の大変高いレートおよびアプリケーション・サーバー・マシン上で予想されるよりも低い CPU 使用効率を示す可能性があります。
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 キャッシュのチューニング を参照してください。
アプリケーションがプール内のインスタンスの大多数を使用している場合、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 の最小数および最大数です。 これらはプールからの除去がこれ以上発生しないように設定されるべきで、ほとんどの場合、プールの増加および縮小が起こらないためにメモリーが十分にある場合は等しく設定されるべきです。
アプリケーション開発者および管理者は、アプリケーションがどのように 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 オブジェクト) を使用している場合、このパラメーターにより大きな改善を得ることができます。
IBM パーシスタンス・マネージャーは、EJB コンテナーによって使用されて、CMP Entity Bean からデータベースへ、データを保管します。 ejbCreate() メソッドを呼び出すことによって Entity Bean を作成する場合、パーシスタンス・マネージャーはデフォルトで、即時にデータベース内の 1 次キーのみで空の行を挿入します。 ほとんどの場合、アプリケーションは Bean を作成した後で、作成された Bean 内、または同じトランザクション内のその他の Bean 内のフィールドを変更します。 ユーザーがデータベースへの挿入をトランザクションの終了まで延期し、 データベースへの片道トリップを除去したい場合は、JVM カスタム・プロパティー・フィールド内で この -D フラグを設定することができます。 データはそれでもデータベース内に挿入され、一貫性は維持されています。
<tuning parameter> -Dcom.ibm.ws.pm.deferredcreate=trueこの最適化のパフォーマンス上の利点は、 アプリケーションによって異なります。EJB アプリケーション・トランザクションが挿入を非常に多く実行する場合、アプリケーションはこの最適化から多くの利益を得ることが可能です。 アプリケーションがほとんど挿入を実行しない場合は、この最適化による利益はかなり少なくなるでしょう。
EJB アプリケーションが単一トランザクション内の複数の CMP Bean にアクセスする場合、Bean (更新、挿入、読み込み) 上で実行されるオペレーションによって、データベースに発行されるオペレーションの数が直接、CMP Bean 上で実行されるオペレーションと対応します。 ご使用のデータベース・システムが更新ステートメントのバッチをサポートしている場合、このフラグを使用可能にして、すべての対話上で単一トランザクション内の 2 つ以上の更新に関わるデータベースと使用して、パフォーマンスを向上させることができます。 このフラグによって、パーシスタンス・マネージャーは、すべての更新ステートメントを、あとでデータベースに発行される単一バッチ・ステートメントに追加します。 これによって、往復のトリップがデータベースに保管され、従ってパフォーマンスが向上します。 単一トランザクション内の複数の CMP Bean の更新の振る舞いがそのアプリケーションで公開されること、 およびデータベースでバッチ更新がサポートされることを、ユーザーが知っている場合は、 この -D フラグを JVM カスタム・プロパティー・フィールド内に設定することもできます。
<tuning parameter> -Dcom.ibm.ws.pm.batch=trueこの最適化のパフォーマンス上の利点は、 アプリケーションによって異なります。アプリケーションがまったく、あるいはめったに CMP Bean を更新しないか、またはトランザクションごとに単一の Bean しか更新しない場合は、パフォーマンス向上はありません。 アプリケーションがトランザクションごとに複数の Bean を更新する場合は、このパラメーターによってご使用のアプリケーション・パフォーマンスが向上します。
データベース | バッチ更新のサポート | オプティミスティック並行性制御を使用したバッチ更新のサポート |
---|---|---|
DB2 | はい | いいえ |
Oracle | はい | いいえ |
DB2 Universal Driver | はい | はい |
Informix | はい | はい |
SQLServer | はい | はい |
Cloudscape | はい | はい |
com.ibm.ws.pm.useLegacyCache=false
‘com.ibm.ws.pm.grouppartialupdate=true’ および ‘com.ibm.ws.pm.batch=true’