Oracle® Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング 12c リリース1 (12.1.1) B65905-02 |
|
前 |
次 |
この章では、メッセージドリブン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( |
カスタム・ワーク・マネージャ、制約有り |
|
警告: 表11-1内の情報は、 |
トランザクション対応の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)をオーバーライドするためには、 |
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は常にスレッド・プール・サイズを1に制限します。
トランザクション対応のMDBでトランザクション・バッチ処理が有効になっている場合は、MDBがトピックとキューのどちらでリスニングしているかによって動作が異なります。
トピックでリスニングしているMDB: 各デプロイ済みMDBは、プールされないスレッドのグループで作成される、専用のデーモン・ポーリング・スレッドを使用します。
トピック・メッセージ分散モード = 互換性: デプロイされた各MDBは、プールされていないスレッドのスレッド・グループで作成される専用のデーモン・ポーリング・スレッドを使用します。
トピック・メッセージ分散モード = One-Copy-Per-ServerまたはOne-Copy-Per-Application: キューと同様。
キューでリスニングしているMDB - 各デプロイ済みMDBは、専用のスレッドを使用する代わりに、トークン・ベースの同期ポーリング・メカニズムを使用します。このメカニズムでは常にdispatch-policy
から少なくとも1つのスレッドを使用します。「キュー/トピックにリスニングするトランザクション対応のMDBに対するトークン・ベースのメッセージ・ポーリング」を参照してください。
WebLogic Serverを外部宛先から消費されたMDBと相互運用するときのスレッドの割当て方法の詳細は、「外部宛先からのメッセージを処理するMDBのスレッドの使用」を参照してください。
topicMessagesDistributionMode
が「互換性」
であるとき、非トランザクション・トピックMDBのデフォルト動作は、メッセージ処理のマルチスレッド化です。この場合、予期しない例外や未処理のメッセージの確認応答など、トピックがWebLogic JMSトピックでないとき、MDBコンテナは再現可能な動作を提供できません。たとえば、アプリケーションがonmessage
からRuntimeException
をスローする場合、コンテナはメッセージを確認する可能性があります。トピックが外部ベンダー・トピックであるとき(WebLogic JMSトピックでないとき)、トピックMDBにおけるマルチスレッド化を防ぐために、デプロイメント記述子でmax-beans-in-free-pool
の値を1
に設定することをお薦めします。
警告: 非トランザクション外部トピック: 外部(WebLogic以外の)トピックと共に機能する非トランザクションMDBには、明示的に 順序単位: WebLogic JMSトピックから消費してWebLogic JMSの「順序単位」値を持つメッセージを処理する非トランザクション |
トランザクションCompatibility
モードMDBは、max-beans-in-free-pool
の設定に関係なく、強制的に自動で同時実行性を1
に設定します。
メッセージドリブンBeanは、分散トピックの使用時にスケーラビリティと高可用性を付与する多数のアプリケーション設計およびデプロイメント・オプションを提供します。詳細は、『Oracle WebLogic ServerメッセージドリブンBeanのプログラミング』の分散トピックを使用したMDBの構成およびデプロイに関する項を参照してください。
注意: ここでの「外部宛先」とは、WebLogic以外のJMSプロバイダによってホストされる宛先を示します。リモートWebLogic宛先のことではありません。 |
次の項では、外部宛先からのメッセージを消費する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は、同期ポーリング・メカニズムを使用して、次の場合にJMS宛先からメッセージを取得します。
WebLogic以外のキューのリスニング
WebLogicキューのリスニングおよびトランザクションのバッチ処理が有効化されている場合
次の場合のWebLogicトピックのリスニング。
トピック・メッセージ分散モード = One-Copy-Per-Serverおよびトランザクションのバッチ処理が有効化されている場合。
トピック・メッセージ分散モード = One-Copy-Per-Applicationおよびトランザクションのバッチ処理が有効化されている場合
同期ポーリングを使用すると、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メッセージ・コンシューマはキャッシュされるのではなく閉じられるため、メッセージが特定のコンシューマの宛先によって予約されることはありません。