| Oracle® Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング 11g リリース1 (10.3.6) B61002-05 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング 11g リリース1 (10.3.6) B61002-05 |
|
前 |
次 |
この章では、アプリケーション環境のWebLogic Server EJBのチューニング方法について説明します。
デプロイメント記述子は、スキーマ・ベースです。WebLogic Serverのこのリリースで新規の記述子は、DTDベースの記述子としては利用できません。
RequiresNewトランザクション・パラメータの使用は避けてください。RequiresNewを使用すると、現在のすべてのトランザクションがEJBコンテナによって一時停止され、新しいトランザクションが開始されます。これは、別のデータベース接続を含む、追加のリソースが割り当てられることを意味します。
同じアプリケーション内で、あるEJBがサーブレットまたはJSPによって呼び出されたり、別のEJBに呼び出される場合は、local-interfacesを使用するか、call-by-referenceをtrueに設定して、シリアライゼーションのオーバーヘッドを回避します。次の点に注意してください。
WebLogic Server 8.1より前のリリースでは、call-by-referenceはデフォルトでオンになっています。WebLogic Server 8.1以降のリリースでは、call-by-referenceはデフォルトでオフになっています。call-by-referenceが明示的にオンにされない8.1以降のWebLogic Serverに移行する古いアプリケーションでは、パフォーマンスが低下する場合があります。
この最適化は、異なるアプリケーション間の呼出しには適用されません。
可能な限り、ステートフル・セッションBeanよりもステートレス・セッションBeanを使用します。ステートレス・セッションBeanは、維持すべき状態情報が存在しないため、ステートフル・セッションBeanよりもスケーラビリティが高くなります。
WebLogic Serverでは、WebLogic Serverクラスタ内のEJBを使用するトランザクションのパフォーマンスも向上します。単一のトランザクションが複数のEJBを使用する場合、WebLogic Serverは異なるサーバーのEJBではなく、単一のWebLogic Serverインスタンスに存在するEJBインスタンスを使用します。この方法を使用すると、トランザクションのネットワーク・トラフィックを最小限に抑えることができます。場合によっては、トランザクションはクラスタ内の複数のWebLogic Serverインスタンスに存在するEJBを使用します。これは、すべてのEJBがすべてのWebLogic Serverインスタンスにデプロイされていない混成のクラスタで起こる場合があります。このような場合、WebLogic Serverは複数の直接接続ではなく1つの多層接続を使用してデータベースにアクセスします。この方法を使うと、リソースの使用量が減り、トランザクションのパフォーマンスが向上します。しかし、最高のパフォーマンスを得るには、クラスタを同一化する必要があります。
次の項では、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に同時にアクセスすると予想されるスレッドの数の積より大きくする必要はありません。
キャッシュの失敗率が高いエンティティBeanの場合、READY Beanインスタンスを保持しておくと、パフォーマンスに悪影響を与える場合があります。
disable-ready-instancesフラグをentity-descriptorのentity-cache要素で設定すると、READYインスタンスはキャッシュに保持されません。この機能がデプロイメント記述子で有効にされている場合、キャッシュにはACTIVEインスタンスしか保持されません。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要素に適用される際に、内部関係ファインダに対して同じ目的を持ちます。問合せは、次の状況で、問合せキャッシュから削除されます。
その問合せが最も使用量が少なく、query-cacheのサイズ制限に到達しています。
問合せ条件を満たすEJBのうち少なくとも1つが、エンティティBeanキャッシュから理由にかかわらず削除されています。
その問合せが、eager-relationship-cachingが有効化されたファインダに対応し、関連する内部関係ファインダの問合せが関連Beanの問合せキャッシュから削除されています。
エンティティ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と同じチューニング・パラメータを持ち、チューニング時には同じ要素が適用されます。通常、ほとんどのアプリケーションにおいて、デフォルト値が適切です。第11章「メッセージドリブンBeanのチューニング」を参照してください。
エンティティBeanプールには次の2つの目的があります。
リフレクションによるファインダの呼出し用のターゲット・オブジェクト。
キャッシュ内に特定の主キーのインスタンスが見つからない場合に、コンテナが補充できるBeanインスタンスのプール。
エンティティ・プールには匿名インスタンス(主キーを持たないインスタンス)が格納されます。これらの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にアクセスする場合にのみ使用します。『Oracle WebLogic Server WebLogic Enterprise JavaBeansのプログラミング』のリレーションシップ・キャッシングに関する項を参照してください。
このリリースのWebLogic Serverでは、CMRフィールドにrelationship-cachingとcascade-deleteの両方を指定すると、オーナーBeanおよび関連BeanがSQLにロードされ、パフォーマンスが向上します。
積極的なrelationship-cachingが有効になっている場合、EJBコンテナは常にCMP Beanファインダで外部結合を使用します。通常、内部結合の方が外部結合よりも実行が速くなりますが、内部結合の場合は、結合された対応する表内でデータが含まれていない行は返さないという難点があります。適用可能な場合は、非常に大規模なデータベースで内部結合を使用すると、CPUリソースを解放できる可能性があります。
WLS 10.3では、weblogic-cmp-rdbms-jar.xmlに、weblogic-rdbms-beanの属性としてuse-inner-joinが追加されました。
<weblogic-rdbms-bean>
<ejb-name>exampleBean</ejb-name>
...
<use-inner-join>true</use-inner-join>
</weblogic-rdbms-bean>
CMP Beanに関連するBeanをnullや空に設定できない場合は、この要素をtrueに設定してください。
デフォルト値はfalseです。この値をtrueに指定した場合、そのエンティティBeanに対するすべてのリレーションシップ・キャッシュ問合せでは、左外部結合の代わりに内部結合を使用して問合せ句を選択します。
JDBCバッチ処理は、EJBコンテナにおいてデフォルトでオンにされています。EJBコンテナは、データベースへのラウンド・トリップ数を減らすことによってパフォーマンスが向上する単一のバッチでの単純なデータベース操作を自動的に並べ替え、実行します。Oracleでは、バッチ処理を使用することをお薦めします。
エンティティ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のメソッド・パラメータが値で渡され、シリアライゼーションが伴います。可変で複合型の場合、これは大幅なコスト高になることがあります。以下の場合、優れたパフォーマンスを得るために、この使用を検討してください。
アプリケーションがcall-by-valueセマンティクスを必要としていません(メソッド・パラメータがEJBによって変更されない場合など)。
または
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の永続的なの状態が無効になる場合があります。それは、query-cachingを使用できる唯一の同時実行性方式です。「トランザクション間のキャッシング」を参照してください。
WebLogic Server管理コンソールでは、EJB実行時の様々なモニター統計が報告されます。それらの統計の多くがEJBのチューニングに役立ちます。この項では、統計の一部を利用してEJBのパフォーマンスをチューニングする方法について説明します。
管理コンソールに統計を表示するには、Oracle WebLogic Server管理コンソール・ヘルプのEJBの監視に関する項を参照してください。カスタム監視アプリケーションを書き込む場合、JMXまたはWLSTを使用して該当するランタイムMBeanにアクセスして監視統計にアクセスできます。Oracle WebLogic Server MBeanリファレンスのランタイムMBeanに関する項を参照してください。
キャッシュ・ミス率とは、コンテナがキャッシュ内でBeanを見つけようと試行した回数(キャッシュ・アクセス)に対する、コンテナがキャッシュ内にBeanを見つけられなかった回数(キャッシュ・ミス)の比率です。
Cache Miss Ratio = (Cache Total Miss Count / Cache Total Access Count) * 100
高いキャッシュ・ミス率は、キャッシュ・サイズが適切に設定されていないことを示している場合があります。アプリケーションでBeanの特定のサブセット(読取り主キー)が他のBeanよりも頻繁に使用される場合、頻繁に使用されるBeanがキャッシュ内に残り、あまり使用されないBeanが要求に応じてキャッシュの内と外を循環できるように、キャッシュ・サイズを十分な大きさに設定することが理想的です。このような性質を持つアプリケーションの場合、キャッシュの最大サイズを増やすと、キャッシュ・ミス率を大幅に下げられる場合があります。
特定のBeanのサブセットを他のBeanよりも頻繁に使用する必要がないアプリケーションの場合、キャッシュの最大サイズを増やしても、キャッシュ・ミス率には影響しません。最も低いキャッシュ・ミス率が得られる最大キャッシュ・サイズを判断するには、様々な最大キャッシュ・サイズでアプリケーションをテストすることをお薦めします。また、サーバーのメモリーの容量は限られているため、キャッシュ・サイズを増やす場合は常にトレードオフが伴うことに注意することも重要です。
Exclusive同時実行性戦略を使用する場合、ロック待機率とは、発行されたロック・リクエストの総数に対する、スレッドがBeanのロックを取得するために待機しなければならなかった回数の比率です。
Lock Waiter Ratio = (Current Waiter Count / Current Lock Entry Count) * 100
高いロック待機率は、Beanの同時実行性戦略が最適ではないことを示している場合があります。アプリケーションに適合している場合、DatabaseまたはOptimisticの同時実行性戦略を使用すると、Exclusive方式を使用する場合よりも多くの並行処理が可能になり、EJBコンテナ・レベルでのロックが不要になります。
通常、トランザクションが継続している間はロックが保持されるため、トランザクションの継続時間を減らすとBeanがより短時間で解放され、その結果ロック待機率を下げることができる場合があります。トランザクションの時間を短縮するには、特別に必要な場合以外は、1つのトランザクションに多量の作業をグループ化することを避けます。
Exclusive同時実行性戦略を使用する場合、ロック・タイムアウト率とは、ロック・マネージャのアクセス数に対する、タイムアウト数の比率です。
Lock Timeout Ratio =(Lock Manager Timeout Total Count / Lock Manager Total Access Count) * 100
ロック・タイムアウト率は、ロック待機率と密接に関連しています。Beanのロック・タイムアウト率を改善する必要がある場合、最初にロック待機率を調べてこの率を下げる対処方法(同時実行性戦略の変更など)を考慮してください。スレッドがBeanのロックを待機しなければならない回数を削減するかゼロにすることができれば、待機中に発生するタイムアウトの回数も減少するかゼロになります。
また、高いロック・タイムアウト率は、トランザクションのタイムアウト値が不適切であることを示している場合もあります。スレッドがロックを待機する最大時間は、現在のトランザクション・タイムアウト値と同じです。
トランザクション・タイムアウト値が非常に低く設定されていると、スレッドはBeanへのアクセスが可能になるまで待機せずにタイムアウトする場合があります。その場合、Beanのtrans-timeout-seconds値を大きくすると、ロック・タイムアウト率を下げることができます。
ただし、trans-timeout-seconds値を大きくする場合は注意が必要です。この値を大きくすると、貴重なサーバー・リソースであるスレッドが長時間1つのBeanを待機する場合があります。また、リクエスト時間が長くなり、その結果、タイムアウトまでの待機時間が長くなる場合もあります。
プール・ミス率は、プールにBeanをリクエストした総回数に対する、プールにBeanの取得をリクエストしたが利用できるBeanがなかった回数の比率です。
Pool Miss Ratio = (Pool Total Miss Count / Pool Total Access Count) * 100
プール・ミス率が高い場合、Beanインスタンスに発生している状況を判断する必要があります。Beanは、次の3つの状況になる場合があります。
使用中
破棄済み
削除済み
次の手順に従って、問題を診断します。
Bean破棄率を調べて、Beanインスタンスが破棄されていないことを確認します。
原因を特定し、状況に対処します。
EJBの需要を一定期間調べます。
これを確認する1つの方法は、管理コンソールに表示される、現在の使用中Bean数およびアイドルBean数を使用することです。一定期間にEJBの需要が急増すると、プールが空になって追加リクエストに対応できなくなるため、多くのプール・ミスが表示されます。
EJBの需要が減少してBeanがプールに戻されると、リクエストを処理するために作成されたBeanの多くは、プールに収まりきらずに削除されます。この場合、フリー・プールの最大サイズを増やすと、プール・ミスの回数を減らすことができる場合があります。この最大サイズを増やすと、ピーク期間中に需要を満たすために作成されたBeanがプール内に存続するため、再び需要が増えたときにこれらのBeanを再び使用できるようになります。
Bean破棄率とはBeanのリクエストの総数に対する、破棄されたBean数の比率です。
Destroyed Bean Ratio = (Total Destroyed Count / Total Access Count) * 100
Beanの破棄数を減らすには、Beanインスタンスを破棄する必要がある場合以外は、Beanコードから非アプリケーション例外をスローしないことをお薦めします。非アプリケーション例外は、java.rmi.RemoteException例外(RemoteExceptionから継承される例外を含む)、あるいはEJBのホーム・インタフェースまたはコンポーネント・インタフェースのメソッドのthrows句に定義されていない例外のいずれかです。
通常、Beanの破棄の原因となっている例外は、パフォーマンスを低下させている場合や、EJBまたはEJBで使用されるリソースの問題を示している場合があるため、その例外を特定する必要があります。
プール・タイムアウト率とは、行われたリクエストの総数に対する、プールからのBeanを待機していてタイムアウトしたリクエストの比率です。
Pool Timeout Ratio = (Pool Total Timeout Count / Pool Total Access Count) * 100
高いプール・タイムアウト率は、フリー・プールのサイズが適切に設定されていないことを示している場合があります。max-beans-in-free-pool設定を使用してフリー・プールの最大サイズを増やすと、サービス・リクエストに使用できるBeanインスタンスの数が増え、プール・タイムアウト率を下げることができる場合があります。
プール・タイムアウトの数に影響する別の要因は、Beanに対して構成されているトランザクション・タイムアウトです。スレッドがプールからのBeanを待機する最大時間は、Beanのデフォルトのトランザクション・タイムアウト値と同じです。weblogic-ejb-jar.xmlファイルのtrans-timeout-secondsの設定値を大きくすると、Beanインスタンスが使用可能になるまでのスレッドの待機時間が長くなります。
ただし、この値を大きくする場合は注意が必要です。この値を大きくすると、貴重なサーバー・リソースであるスレッドが長時間1つのBeanを待機する場合があります。また、リクエストがタイムアウトするまでの待機時間が長くなるため、リクエスト時間が長くなる場合があります。
トランザクション・ロールバック率とは、EJBに関与するトランザクションの総数に対する、ロールバックしたトランザクションの比率です。
Transaction Rollback Ratio = (Transaction Total Rollback Count / Transaction Total Count) * 100
トランザクション・ロールバック率が高い場合に原因を調査するには、管理コンソールに示されるトランザクション・タイムアウト率を最初に調べます。トランザクション・ロールバック率が予想よりも高い場合、最初にタイムアウトの問題に対処します。
予想外に高いトランザクション・ロールバック率には、いくつかの原因が考えられます。アプリケーションまたはアプリケーションで使用されるリソースの潜在的な問題を発見するには、トランザクション・ロールバックの原因を調査することをお薦めします。
トランザクション・タイムアウト率とは、EJBに関与するトランザクションの総数に対する、タイムアウトしたトランザクションの比率です。
Transaction Timeout Ratio = (Transaction Total Timeout Count / Transaction Total Count) * 100
不適切なトランザクション・タイムアウト値が原因でトランザクション・タイムアウト率が高くなる場合があります。たとえば、トランザクション・タイムアウトの値が小さすぎると、スレッドが必要な処理を完了する前にトランザクションがタイムアウトする場合があります。トランザクション・タイムアウト値を大きくすると、トランザクション・タイムアウト数を減らすことができる場合があります。
ただし、この値を大きくする場合は注意が必要です。この値を大きくすると、タイムアウトまでにスレッドが長時間1つのリソースを待機する場合があります。また、リクエストがタイムアウトするまでの待機時間が長くなるため、リクエスト時間が長くなる場合があります。
高いトランザクション・タイムアウト率の発生には、サーバー・リソースのボトルネックなど、多くの原因が考えられます。タイムアウトの原因を特定して問題に対処できるようにするには、トランザクション全体をトレースすることをお薦めします。
JDTコンパイラは、Javacに比べてパフォーマンスが向上しています。このリリースでは以下の点に注意してください。
JDTとJavacは両方ともEJBコンテナでサポートされています。JDTはデフォルトのオプションです。
appcとWLSで異なるコンパイラを使用するように設定できます。設定の詳細は以下のとおりです。
appcでは、-compilerを使用します(例: -java weblogic.appc -compiler javac ...)。
WLSでは、config.xmlファイルのejb-containerタグを使用します。例:
<ejb-container>
<java-compiler>jdt</java-compiler>
</ejb-container>
appcでJDTを使用する場合は、現在、-keepgeneratedおよび -forceGenerationコマンド・ライン・オプションのみがサポートされています。これらのオプションの意味はJavacを使用する場合と同じです。
