| Oracle® Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング 11g リリース1 (10.3.3) B61002-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング 11g リリース1 (10.3.3) B61002-01 |
|
前 |
次 |
次の項では、メッセージドリブンBean (MDB)のチューニングとベスト・プラクティスについて説明します。
MDBトランザクションのバッチ処理を使用すると、複数のJMSメッセージを1つのコンテナ管理トランザクションに管理できます。バッチ処理を使用すると、複数のメッセージのトランザクション・コストが償却されます。また、適切に使用すると、2PC処理と1PC処理の間のスループットの差も削減、または排除できます。『Oracle Fusion Middleware Oracle WebLogic ServerメッセージドリブンBeanのプログラミング』のMDBのトランザクションのバッチ処理に関する項を参照してください。
バッチ処理を使用する場合、同時に扱うMDBインスタンス数を減らす必要があることもあります。使用できるMDBインスタンスが多すぎる場合、メッセージはバッチ処理ではなく並行処理される可能性があります。「MDBスレッド管理」を参照してください。
通常、バッチ処理ではスループットが向上しますが、待機時間(個々のメッセージのMDB処理が完了するまでの時間)も増大する場合があります。
MDBのスレッド管理については、同時実行性、すなわち同時にアクティブになれるMDBインスタンス数の観点から説明します。次の項では、MDBの同時実行性について説明します。
表11-1では、サーバー・インスタンスに対して同時実行しているMDBインスタンス数の確定方法に関する情報を提供します。
表11-1 WebLogic Server MDBの同時実行性の確定
| ワーク・マネージャまたは実行キューのタイプ | スレッド |
|---|---|
|
デフォルトのワーク・マネージャまたは制約のないワーク・マネージャ |
最大でMin( |
|
デフォルトのワーク・マネージャ、自動チューニングを無効化 |
Min( これは、WebLogic Server 8.1でのデフォルト・スレッド・プールの同時実行方式でもあります。 |
|
カスタム実行キュー |
Min( |
|
カスタム・ワーク・マネージャ、制約有り |
|
トランザクション対応のWebLogic MDBは、A) WebLogic以外のキューをリスニングしている場合、またはB) WebLogicキューをリスニングしていて、トランザクション・バッチ処理が有効になっている場合、同期的なポーリング・メカニズムを使用してJMS宛先からメッセージを取得します。「キューでリスニングするトランザクション対応MDBでのトークン・ベースのメッセージ・ポーリング」を参照してください。
次の項では、アプリケーションに対して同時実行性方式を選択するための全般的な情報を示します。
|
注意: アプリケーションにはそれぞれに固有特性があります。同時実行性はアプリケーションがその環境でどのように動作するのかに基づいて選択します。 |
ほとんどの状況において、メッセージ・ストリームにメッセージの急増が見られる場合には、制約のないワーク・マネージャを高いフェア・シェアで使用するのが適切。急増したメッセージ群が処理されると、スレッドは自動チューニング・プールに返されます。
ほとんどの状況において、メッセージの到着率を高いレベルで一定させるか、待機時間を小さくすることが求められる場合、MDBに対してスレッドを予約すると有効です。スレッドを予約するには、ワーク・マネージャにmin-threads-constraintを指定するか、カスタム実行キューを使用します。
カスタムMDB実行キューを備えたWebLogic Server 8.1のアプリケーションを移行する場合、以下の設定が可能です。
カスタムMDB実行キューを引き続き使用します。付録A「WebLogic 8.1スレッド・プール・モデルの使用」を参照してください。
MDB実行キューを、max-threads-constraintパラメータおよび高いフェア・シェア設定が構成されたカスタム・ワーク・マネージャに変換します。
|
注意: デフォルトの同時実行性数(16)をオーバーライドするためには、max-threads-constraintパラメータを構成する必要があります。 |
WebLogic Server 8.1では、デフォルトのプールを拡張すると同時実行性MDBの最大数も大きくなることから、デフォルトの実行キューのサイズを増加できました。WebLogic Server 9.0でアップグレードされたデフォルト・スレッド・プールのMDBは、最大数が16に固定されています。同時実行するMDB数を16よりも大きくするには、カスタム・ワーク・マネージャまたはカスタム実行キューを作成する必要があります。表11-1を参照してください。
次の項では、WebLogic ServerとWebLogic宛先が相互運用する場合のスレッドの割当て方法について説明します。
トランザクション非対応のWebLogic MDBでは、処理すべき新しいメッセージがある場合、必要に応じて、dispatch-policyで指定されているスレッド・プールからスレッドを割り当てます。MDBが正常にソース宛先に接続したものの処理するメッセージがない場合、MDBはスレッドを使用しません。
トランザクション対応のWebLogic MDBでトランザクション・バッチ処理が無効になっている場合は、トランザクション非対応のMDBと同じ動作になります。
トランザクション対応のMDBでトランザクション・バッチ処理が有効になっている場合は、MDBがトピックとキューのどちらでリスニングしているかによって動作が異なります。
トピックでリスニングしているMDB - 各デプロイ済みMDBは、プールされないスレッドのグループで作成される、専用のデーモン・ポーリング・スレッドを使用します。
キューでリスニングしているMDB - 各デプロイ済みMDBは、専用のスレッドを使用する代わりに、トークン・ベースの同期ポーリング・メカニズムを使用します。このメカニズムでは常にdispatch-policyから少なくとも1つのスレッドを使用します。「キューでリスニングするトランザクション対応MDBでのトークン・ベースのメッセージ・ポーリング」を参照してください。
WebLogic Serverを外部宛先から消費されたMDBと相互運用するときのスレッドの割当て方法の詳細は、「外部宛先からのメッセージを処理するMDBのスレッドの使用」を参照してください。
非トランザクション・トピックMDBのデフォルト動作では、メッセージをマルチスレッドで処理します。この場合、トピックがWebLogic JMSトピックでない場合、MDBコンテナは、予期しない例外および処理されていないメッセージの承認など再現性の動作に失敗します。たとえば、アプリケーションがonmessageからRuntimeExceptionをスローする場合、コンテナがメッセージを承認する場合があります。
トピックがWebLogic JMSトピックではなく、外部ベンダーのトピックの場合、トピックMDBでのマルチスレッド化を避けるためにデプロイメント記述子のmax-beans-in-free-poolの値を1に設定することをお薦めします。
|
注意: このコンテキストでの「外部宛先」という用語は、リモートWebLogic宛先ではなく、WebLogic JMSプロバイダ以外にホストされている宛先を示します。 |
次の項では、外部宛先からのメッセージを消費するMDBを使用したときのWebLogic Serverの動作について説明します。
外部プロバイダによってホストされている宛先(WebLogic JMS以外の宛先)からのメッセージを消費するMDBの同時実行性は、WebLogic JMS宛先に使用するアルゴリズムと同じアルゴリズムを使用して決定されます。
次の項では、WebLogic Serverが外部宛先からのメッセージを処理するMDBと相互運用するときのスレッドの割当て方法について説明します。
トランザクション非対応のMDBは外部ベンダーのスレッドを使用し、WebLogic Serverのスレッドは使用しません。この場合、dispatch-policyは同時実行性方式の決定以外では無視されます。
トランザクション対応のMDBは、次のようにWebLogic Serverスレッドで動作します。
トピックでリスニングしているMDB - 各デプロイ済みMDBは、プールされないスレッドのグループで作成される、専用のデーモン・ポーリング・スレッドを使用します。
キューでリスニングしているMDB - 各デプロイ済みMDBは、専用のスレッドを使用する代わりに、トークン・ベースの同期ポーリング・メカニズムを使用します。このメカニズムでは常にdispatch-policyから少なくとも1つのスレッドを使用します。「キューでリスニングするトランザクション対応MDBでのトークン・ベースのメッセージ・ポーリング」を参照してください。
トランザクション対応のWebLogic MDBは、A) WebLogic以外のキューをリスニングしている場合、またはB) WebLogicキューをリスニングしていて、トランザクション・バッチ処理が有効になっている場合、同期的なポーリング・メカニズムを使用してJMS宛先からメッセージを取得します。同期的なポーリングでは、1つまたは複数のWebLogicポーリング・スレッドがMDBのソース宛先からメッセージを同期的に受信し、MDBアプリケーションのonMessageコールバックを呼び出します。
WebLogic 10.3では、メッセージの負荷が変動する状況で同時ポーラー・スレッド数を制御しやすくなるように、ポーリング・メカニズムがトークン・ベースの手法に変更されました。以前のリリースでは、特定の状況において、スレッド数の増加が緩やかすぎる場合がありました。また、特定の外部JMSプロバイダでは、子ポーラーを一度起動すると、数を減らしてプールに戻すことができない場合もありました。
トークン・ベースのポーリングでは、スレッドがスレッド・プールに戻されるとき、スレッドの内部JMSコンシューマはキャッシュされるのではなく、閉じられます。そのため、コンシューマに対応するポーリング・スレッドはなくなり、メッセージが特定の外部JMSプロバイダによって暗黙的にプリフェッチされることがなくなります。
また、各MDBは、特定のポーラー・スレッドに別スレッドの作成を許可する単一のトークンを保持します。
メッセージの受信時: すでにトークンを持っているポーラー・スレッド、または、他に所有されていなかったのでトークンを獲得できたポーラー・スレッドが、追加のポーラー・スレッドを起動します。まだ同時実行性スレッドの最大数に達していない場合は、そのトークンを新しいポーラーに与えます。同時実行性スレッドの最大数に達している場合は、(他のポーラーで使用できるように)単にトークンを解放します。
空のキューの検出時 - ポーラーはトークンの獲得を試み、獲得できた場合は、そのキューの定期的なポーリングを試みます。トークンを獲得できない場合、ポーラーは自身をプールに返します。したがって、空のキューに対しても、少なくとも1つのポーラーがメッセージをチェックしていることになります。
WLSバージョン10.0以前では、バッチ処理が有効になっているトランザクション対応MDBは、デプロイ済みの各MDBごとに専用のポーリング・スレッドを作成していました。このポーリング・スレッドはdispatch-policyで指定されたプールから割り当てられるものではなく、システムで動作している他のすべてのスレッドに追加される、完全に新しいスレッドでした。「トランザクション・バッチの使用」を参照してください。
トークン・ベースのポーリングの動作をオーバーライドしてWLS 10.0以前の動作を実装するには、以下のいずれかを行います。
サーバー・レベルでは、weblogic.mdb.message.81StylePolling システム・プロパティをTrueに設定して、トークン・ベース・ポーリングの動作をオーバーライドします。
MDBレベルでは、message-driven-descriptorの下のuse81-style-polling要素を設定して、トークン・ベース・ポーリングの動作をオーバーライドします。WLS 8.1方式のポーリング・フラグで外部のトランザクション対応MDBを使用する場合、外部ベンダーの中には同時実行するMDBインスタンスごとに恒久的にスレッドを割り当てる必要があるものもあります。このようなスレッドはdispatch-policyで指定されたプールから取得され、MDBがアンデプロイされるまでプールに返されません。こうしたスレッドは共有されないため、MDBが同じプール内の他のリソースの処理を妨げることがあります。このような場合、必要に応じてプールのスレッド数を増加します。このような外部ベンダーの場合にトークン・ベースのポーリング方式を使用した場合、スレッドの内部的なJMSメッセージ・コンシューマはキャッシュされるのではなく閉じられるため、メッセージが特定のコンシューマの宛先によって予約されることはありません。
