| Oracle® Fusion Middleware Oracle WebLogic Server パフォーマンス チューニング ガイド 11g リリース 1 (10.3.1) B55570-01 |
|
 戻る |
 次へ |
| Oracle® Fusion Middleware Oracle WebLogic Server パフォーマンス チューニング ガイド 11g リリース 1 (10.3.1) B55570-01 |
|
戻る |
次へ |
以下の節では、メッセージ駆動型 Bean (MDB) のチューニングとベスト プラクティスについて説明します。
MDB のトランザクション バッチ処理では、複数の JMS メッセージを 1 つのコンテナ管理によるトランザクションで処理できます。バッチ処理を行うと複数のメッセージを扱うトランザクションのコストが償却され、適切に使用した場合には 2PC 処理と 1PC 処理のスループットの差が軽減したり、解消されたりすることもあります。『Oracle Fusion Middleware Oracle WebLogic Server エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「MDB のトランザクション バッチ処理」を参照してください。
バッチ処理を使用する場合、同時に扱う MDB インスタンス数を減らす必要があることもあります。使用できる MDB インスタンスが多すぎる場合、メッセージはバッチ処理ではなく並行処理される可能性があります。「MDB スレッド管理」を参照してください。
通常、バッチ処理ではスループットが向上しますが、レイテンシ (個々のメッセージの MDB 処理が完了するまでの時間) も増大する場合があります。
MDB のスレッド管理については、同時実行性、すなわち同時にアクティブになれる MDB インスタンス数の観点から説明します。以下の節では、MDB の同時実行性について説明します。
表 10-1 は、1 つのサーバ インスタンスに対して同時に実行する MDB インスタンスを確定する方法を示しています。
表 10-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 実行キューを使用する。「WebLogic 8.1 のスレッド プール モデルの使用」を参照してください。
MDB 実行キューを、max-threads-constraint パラメータおよび高いフェア シェア設定がコンフィグレーションされたカスタム ワーク マネージャに変換する。
|
注意 : デフォルトの同時実行数 (16) をオーバーライドするためには、max-threads-constraint パラメータをコンフィグレーションする必要があります。 |
WebLogic Server 8.1 では、デフォルトのプールを拡張すると同時実行できる MDB の最大数も大きくなることから、デフォルトの実行キューのサイズを増加できた。WebLogic Server 9.0 で更新されたデフォルト スレッド プールの MDB は、最大数が 16 に固定されています。同時実行する MDB 数を 16 よりも大きくするには、カスタム ワーク マネージャまたはカスタム実行キューを作成する必要があります。表 10-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 Server の動作について説明します。
外部 MDB の使用時には、WebLogic Server により表 10-1 のように同時方式が確定されます。
以下の節では、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 メッセージ コンシューマはキャッシュされるのではなく閉じられるため、メッセージが特定のコンシューマの送り先によって予約されることはありません。
