| Oracle® Fusion Middleware Oracle WebLogic Serverのパフォーマンスのチューニング 12c (12.2.1.2.0) E82880-02 |
|
 前 |
 次 |
この章には次の項が含まれます:
次の項には、WebLogic JMSをチューニングするときに考慮する項目のチェックリストが記載されています。
必ず割当てを構成します。「割当ての定義」を参照してください
必要に応じて、デフォルトのページングの設定が適用されることを確認します。「メモリーを解放するためにメッセージをページ・アウト」を参照してください。ページングによりパフォーマンスが低下されますが、JVMメモリーが不足している場合には必要です。
大きなメッセージ・バックログを回避します。「大きなメッセージ・バックログの処理」を参照してください
すべてのアプリケーションでは、デフォルトの接続ファクトリではなく、カスタム接続ファクトリを使用します。MDBを使用するときも同じです。デフォルトの接続ファクトリは、チューニング不可能ですが、カスタム接続ファクトリには、パフォーマンス・チューニングの複数のオプションが用意されています。
JNDIコンテキストと参照、JMS接続、セッション、コンシューマまたはプロデューサなどのJMSクライアント・リソースをキャッシュして再利用できるように、アプリケーションを書込みます。これらのリソースを作成するには、比較的コストが高くなります。キャッシュの必要があるタイミングとビルトイン・プーリング機能については、「クライアント・リソースのキャッシュと再利用」を参照してください
非同期コンシューマおよびMDBについては、接続ファクトリ上のMessagesMaximumをチューニングします。MessagesMaximumを増加すると、パフォーマンスが向上され、MessagesMaximumを最小値までに減少すると、パフォーマンスが低減されますが、すでにメッセージ処理中のコンシューマのためにメッセージが確実に待機しないようにするのに役立ちます。「MessageMaximumのチューニング」を参照してください。
可能な場合はシングル・スレッド処理を実行しないでください。複数のコンカレント・コンシューマおよびプロデューサを使用して、それらを処理するのに十分なスレッドがあることを確認します。
インスタンスを十分に使用できるようにサーバー側アプリケーションをチューニングします。これらのアプリケーションのために専用スレッド・プールを作成することを検討してください。「メッセージドリブンBeanのチューニング」を参照してください
非同期コンシューマのあるクライアント側アプリケーションについては、「クライアント側スレッド・プール」を参照してクライアント側スレッド・プールをチューニングします
「WebLogic永続ストアのチューニング」に記載されているように永続性をチューニングしますそうすると、複数のJMSサーバー、宛先およびサービスとの間に同じストアを共有して、同時リクエストを単一の物理I/Oリクエストに集合することができ、JTAトランザクションでは、1つ以上のストアを適用しにくくなります。1つのストアが現在の負荷を処理していない場合のみ複数のストアの使用を検討する必要があります。
大きなメッセージがある場合は、「大きなメッセージのチューニング」を参照してください
接続ファクトリ・ターゲットを注意深く構成してクラスタへの不必要なメッセージのルーティングを防ぎます。メッセージはクライアントの接続ホストを通じてフローして、最後の宛先に移動するので、2つのサーバーを通じてルーティングされます。サーバー側のアプリケーションの場合、クラスタへの接続ファクトリをターゲットにします。クライアント側のアプリケーションの場合、分散宛先を操作し、分散宛先メンバーをホストするサーバーへの接続ファクトリのみをターゲットにします。クライアント側のアプリケーションの場合、シングルトン宛先を操作し、宛先をホストする同じサーバーへの接続ファクトリをターゲットにします。
JTAトランザクションにJMSとJDBCの両方の操作が含まれている場合、JDBC LLRの最適化を有効化を検討します。LLRは、一般的に使用される安全な「ACID」最適化で、パフォーマンスを大幅に向上しますが、いくつか短所があります。「トランザクションのチューニング」を参照してください。
Javaクライアントを使用している場合、小さいjarサイズがパフォーマンスより重要な場合を除いて、javaシン・クライアントを使用しないでください。シン・クライアントは、T3を指定しても低速IIOPプロトコルを使用するので、かわりにjavaフル・クライアントを使用します。スタンドアロン・クライアントの詳細は、『Oracle WebLogic Serverスタンドアロン・クライアントの開発』を参照してください。
WebLogic JMSストア・アンド・フォワードのチューニングに従って、JMSストア・アンド・フォワードをチューニングします
WebLogicメッセージング・ブリッジのチューニングに従って、WebLogicメッセージング・ブリッジをチューニングします
非永続な非トランザクションリモート・プロデューサ・クライアントを使用している場合、一方向コールの有効化を検討します。「一方向のメッセージ送信の使用」を参照してください
JMS分散キューを使用します。『Oracle WebLogic Server JMSアプリケーションの開発』の分散キューの使用に関する項を参照してください。
すでに分散キューを使用している場合、「分散キューのチューニング」を参照してください
上級分散トピック機能(PDT)の使用を考慮します。『Oracle WebLogic Server JMSアプリケーションの開発』の上級パブリッシュ/サブスクライブ・アプリケーションの開発に関する項を参照してください。
アプリケーションがトピックを使用する場合、トピックのチューニングを参照してください
優先度によってソートされた宛先などのソート済宛先を構成しないでください。FIFO宛先またはLIFO宛先は、最も効率のよい宛先です。大きなメッセージ・バックログがある場合、宛先のソート処理はコストの高い処理であり、数百のメッセージのバックログの場合はパフォーマンスが低減されます。
セレクタ設計を使用します。『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージのフィルタ処理に関する項を参照してください。
宛先をホストしているのと同じWebLogic Serverでアプリケーションを実行します。これにより、ネットワーキングおよび一部またはすべてのマーシャリング・オーバーヘッドが削除され、ネットワークとCPUの使用率を大幅に減少できます。また、確実にトランザクションは1つのサーバーに対してローカルにできます。これは、アプリケーション・サーバーの組込みメッセージングを使用する主な利点の1つです。
メッセージ送信者がコンシューマより速くメッセージを挿入する場合、メッセージはメッセージのバックログに蓄積されます。次の例のような理由で大きなバックログが問題になる場合があります。
コンシューマが受信メッセージ・ロードを処理できない、失敗している、または分散キューで正常にロード・バランスされていないことを示しています。
サーバーがメモリー不足になり、サーバーが動作しなくなる可能性があります。
高ガベージ・コレクション(GC)オーバーヘッドになる可能性があります。JVMのGCオーバーヘッドは、JVM内のライブ・オブジェクト数に部分的に比例しています。
確認する必要がある領域の一つとして、メッセージ処理パフォーマンス全体の向上があります。いくつかの提案を次に示します。
「JMSパフォーマンス&チューニング・チェック・リスト」に記載されているJMSチューニングに関する推奨に従います
新規に開発されたアプリケーションにおけるプログラム・エラーを確認します。特に、非トランザクション・コンシューマがメッセージを承認していること、トランザクション・コンシューマがトランザクションをコミットしていること、プレーンjavax.jmsアプリケーションがjavax.jms.Connection.start()を呼出したこと、および特定のアプリケーションのニーズによってトランザクション・タイムアウトがチューニングされていることなどを確認します。プログラミング・エラーの現象としては、コンシューマがメッセージを何も受信しない(start()を呼出したことを確認する)、多くのキューが保留状態になっている、シャットダウンおよび再起動後に、すでに処理されている永続メッセージが再表示される、遅延後に、すでに処理されたトランザクション・メッセージが再表示される(デフォルトJTAタイムアウトは30秒で、デフォルト処理済セッション・タイムアウトは1時間)といった現象があげられます。
コンシューマによって処理されていないキューのWebLogic統計を確認します。分散キューに関する問題については、「分散キューのチューニング」を参照してください
保留カウントの高いトピックのWebLogic統計を確認します。これによって、通常は現在サービスが提供されていないトピック・サブスクリプションがあることが示されます。メッセージの処理を担当するコンシューマ・クライアントのレスポンスが遅延したり応答しない場合がある、永続サブスクリプションがもう必要ないため削除する必要がある可能性がある、あるいは遅延分散トピックの転送によってメッセージが蓄積していく可能性があります。WebLogic Server管理コンソールで個別の永続サブスクリプションの統計を確認できます。アプリケーションでは、大きなバックログの永続サブスクリプションが作成され、削除されていない場合があります。処理されていない永続サブスクリプションは、管理上破棄されないかぎり、または標準JMSクライアントによってサブスクライブ解除されるまでは、継続して累積されます。
すべてのメンバーがアクティブとは限らない場合、分散トピックの動作を理解します。分散トピックでは、特定のトピックのメンバーに対して生成したすべてのメッセージがリモートのトピックのメンバーにトランスポートされます。リモートのトピック・メンバーが利用不可能な場合、生成されたメッセージがローカル・トピック・メンバーに格納され、後でトランスポートされます。そのため、トピックのメンバーが長期間にわたって利用不可能な場合、アクティブなメンバーに大きなバックログが生成されます。いくつかのアプリケーションでは、これらのバックログにメッセージの有効期限を設定して対処できます。「メッセージ有効期限ポリシーの定義」を参照してください
ある特定のアプリケーションでは、処理されていない古いメッセージが自動的に削除されても問題ありません。「期限切れのメッセージの処理」を参照してください
トランザクションMDBの場合は、MDBトランザクション・バッチングを使用します。これにより、いくつかの使用例において5倍向上できます。
分散キューを使用して、クラスタにJVMをさらに追加します(分散キュー・メンバーのインスタンスをさらに追加するために)。たとえば、200,000個のメッセージ・バックログをJVM当たり100,000個のメッセージではなく、50,000個のメッセージが存在するように4つのJVMに分割します。
クライアント・アプリケーションの場合は、同期コンシューマではなく、非同期コンシューマを使用します。非同期コンシューマを使用すると、ネットワーク・オーバーヘッドおよび待機時間が少なくて、メッセージ待ちの間にスレッドがブロックされません。
同期コンシューマ・クライアント・メッセージの場合は、CLIENT_ACKNOWLEDGEを使用してプリフェッチを有効にして、一度に複数の使用済メッセージを承認できるようにし、AUTO_ACKNOWLEDGEではなく、DUPS_OK_ACKNOWLEDGEを使用することを考慮します。
非同期コンシューマ・クライアント・アプリケーションの場合は、AUTO_ACKNOWLEDGEではなくDUPS_OK_ACKNOWLEDGEの使用を検討します。
一括処理を使用します。たとえば、各トランザクションに複数のメッセージを含めるか、または複数の小さいメッセージではなく大きなメッセージを1つ送信します。
非恒久サブスクライバ・クライアント側のアプリケーションによって処理されていません(「削除済」)メッセージについては、MULTICAST_NO_ACKNOWLEDGEを調べます。このモードを使用すると、メッセージが同時にUDPマルチキャスト上のサブスクライバにブロードキャストされます。
確認する必要があるもう一つの領域は、メッセージ生成の遅延または停止です。いくつかの提案を次に示します。
割当てを低く設定します。「割当ての定義」を参照してください。
プロデューサ・スレッド数を小さくします。
「割当て条件内での送信者のブロック」に記載されているように、割当て条件内で発生する送信者のブロックのタイムアウトをチューニングします。タイムアウトは、接続ファクトリでチューニング可能です。
しきい値条件においてプロデューサのコールを自動的に遅くするプロデューサ・フロー制御をチューニングします。「JMSサーバーと宛先上のメッセージ・フローの制御」を参照してください
アプリケーションを変更してフロー制御を実装します。たとえば、いくつかのアプリケーションでは、コンシューマによって前に生成されたメッセージのバッチ(ウィンドウ・プロトコル)が正常に処理されるまで、プロデューサは追加のメッセージを挿入できません。その他のアプリケーションでは、リクエストまたはレスポンス・アルゴリズムを実装して、前の応答を受信しないかぎり、新しいリクエストが送信されません(基本的に、ウィンドウのサイズが1であるウィンドウ・プロトコル)。いくつかの場合は、RMI/EJB/Servletからの同期フローが十分であるためJMSをチューニングする必要はありません。
メッセージ処理の遅延または停止には、少なくとも次の2つの短所があります。
プロデューサをコールする下流フローにバックプレッシャをかけます。下流フローによっては、バックプレッシャを処理することができないものもあり、プロデューサの背後に作成されるバックログを処理するのが困難です。バックログの場所は、プロデューサのコール先によって異なります。たとえば、サーブレットによってプロデューサがコールされる場合、バックログがパケットとして発生され、受信するネットワーク・ソケットまたはネットワーク・カード上に累積されます。
サーバー・スレッド上のコールをブロックすると、スレッド・スタベーション、アクティブなスレッド数の過多またはデッド・ロックなどの問題が発生する可能性があります。通常、この問題を解決するには、プロデューサ・スレッドがサイズを制限した専用のスレッド・プールで実行されていることを確認する必要があります。これにより、ブロック・スレッドは他のスレッド・プールのアクティビティに影響を与えないことを確認できます。たとえば、EJBまたはサーブレットによって「send」が呼出され、長い時間の間ブロックされる可能性がある場合、最大スレッド数制約を持つカスタム・ワーク・マネージャを構成し、EJB/servletのdispatch-policyを設定して、このワーク・マネージャを参照します。
送受信メッセージに比べてJMSクライアントのリソースを作成するのは、コストの高い操作です。これらのリソースを各メッセージごとに再作成するのではなく、キャッシュまたはプールして再利用する必要があります。これには、コンテキスト、宛先、接続ファクトリ、接続、セッション、コンシューマまたはプロデューサが含まれます。
また、これらのリソースの使用が安全に終了した後、アプリケーションでは、コンテキスト、接続、セッション、コンシューマまたはプロデューサをクローズすることが重要です。使用されていないリソースをクローズしないと、メモリー・リークの問題が発生し、JVM全体のパフォーマンスが低減されます。これにより、メモリー不足になってJVMに失敗します。JNDIコンテキストにはclose()メソッドがあり、JMS接続を自動的にクローズすると、接続を使用して作成されたすべてのセッション、コンシューマおよびプロデューサがクローズされることに注意してください。
サーバー側アプリケーションの場合は、WebLogicは、リソース参照を使用してアクセスされたJMSリソースを自動的にラップしプールします。『Oracle WebLogic Server JMSアプリケーションの開発』のEJBやサーブレットと組み合せたWebLogic JMSの使用に対する拡張サポートに関する項を参照してください。このプーリング・コードは、ターゲット宛先が頻繁に変更する場合、プロデューサのプーリングを適切に行いません。ただし、この問題を回避するために、次の操作を実装します。アプリケーションがcreateProducer()を呼出すと、宛先にnullを渡して無名プロデューサを使用して、そのかわりに、目的の宛先を各送信コールに引き渡します。
JMSリソースが多く割り当てられていたり、またはリークしていないか確認するには、mbeanの統計を監視するか、JVMに組み込まれている特定の機能を使用します。コンソール、WLSTまたはjavaコードを使用して、mbeanの統計を監視できます。
JVMヒープ統計でメモリー・リークまたは予期しない高い割当て数を確認します。
同じように、WebLogicの統計における、メモリー・リークまたは予期しない高い割当て数を確認します。
作成されたメッセージがすべての分散キュー・メンバーの間に均等にロード・バランスされていない場合、プロデューサ接続ファクトリの構成を変更して、サーバー・アフィニティ(デフォルトで有効に設定されています)を無効に設定してください。
いったん作成されると、JMSコンシューマは特定のキュー・メンバーに固定されます。これにより、コンシューマがすべての分散キュー・メンバーの間に均等にロード・バランスされないという問題が発生する可能性があります。特に、すべてのコンシューマの初期化後、新しいメンバーが利用可能な場合に、この問題が発生します。コンシューマがすべての分散キュー・メンバーの間に均等にロード・バランスしない場合、メッセージを処理するために設計されたクラスタにターゲット指定されたMDBを使用するのが、ベストな方法です。WebLogic MDBは、すべての分散キュー・メンバーが処理されていることを自動的に確認します。MDBのオプションが存在しない場合に、コンシューマのロード・バランシングを向上するための提案を、次に示します。
アプリケーションでは、コンシューマが十分作成され、コンシューマの接続ファクトリは、利用可能なロード・バランシングのオプションを使用してチューニングされていることを確認します。特に、デフォルトのサーバー・アフィニティ設定を無効にすることを検討します。
コンシューマが定期的にクローズされ、再作成されるようにアプリケーションを変更します。これにより、コンシューマにバランスが再ロードされます。
分散キューの論理名からではなく、個別のキュー・メンバーから使用します。各分散キュー・メンバーは、JNDIでjms-server-name@distributed-destination-jndi-nameとして個別に通知されています。
トランスポートを有効にするには、分散キューを構成します。分散キューをトランスポートすると、コンシューマのないメンバー宛先にアイドルになっているメッセージが自動的と内部的にコンシューマのあるメンバーにトランスポートされます。この方法は、メッセージ・ロードの高いアプリケーションに対しては、現実的ではない場合があります。
注意:
キュー・トランスポートは、WebLogic JMSのUnit-of-Order機能と互換性がありません。この機能を使用すると、トランスポートするメッセージが機能しなくなる場合があります。
『Oracle WebLogic Server JMSアプリケーションの開発』の分散宛先の使用に関する項、および『Oracle WebLogic Server JMSリソースの管理』の高度なJMSシステム・リソースの構成に関する項を参照してください。
次の項では、WebLogicトピックのチューニング方法について説明します。
シングルトン・トピックを分散トピックに変換する場合があります。パーティション化されたポリシーを持つ分散トピックは、通常、レプリケートされたポリシーを選ぶよりもパフォーマンスが優れます。
特に分散トピックを取り扱うときなど、トピック・メッセージの処理にMDBを活用することを強くお薦めします。MDBを使用すると、複数のサブスクリプションの作成とサービス提供が自動化されるとともに、高度な拡張性オプションを利用して複数の分散トピック・メンバー全体で1つのサブスクリプションのメッセージを自動的に配信できます。
共有可能なサブスクリプションの拡張があり、これを使用すると単一トピックのサブスクリプション上のメッセージを複数のJVM上で複数のサブスクリプションによって並列で処理されるようにできます。WebLogic MDBは、互換性 モードでないとき、この機能を活用します。
作成されたメッセージがPartitioned Distributed Topicのメンバーの間に均等にロード・バランスされていない場合、プロデューサ接続ファクトリの構成を変更して、サーバー・アフィニティ(デフォルトで有効に設定されています)を無効に設定してください。
これらの前述の上級機能を使用する前に、次の関連ドキュメントをじっくりと確認することをお薦めします。
『Oracle WebLogic ServerメッセージドリブンBeanの開発』の分散トピックを使用したMDBの構成およびデプロイに関する項
『Oracle WebLogic Server JMSリソースの管理』の上級パブリッシュ/サブスクライブ・アプリケーションの開発に関する項
『Oracle WebLogic Server JMSリソースの管理』のJMS宛先可用性ヘルパーAPIと分散宛先を使用した高度なプログラミングに関する項
WebLogic Server 9.0以降では、非恒久トピック・メッセージ・パブリッシュ・リクエストは、現在メッセージの処理準備ができているすべてのコンシューマにメッセージが送られるまでブロックします。このため、コンシューマの数が多い非恒久トピック・パブリッシャで、メッセージの公開に予想よりも時間がかかる場合があります。コンシューマを待機せず、メッセージがJMSサーバーに達したことを確認するまで待機するパブリッシュに戻すには、次のプロパティを使用します。
-Dweblogic.messaging.DisableTopicMultiSender=true
メッセージ数の割当てを必ず構成することを強くお薦めします。割当てを構成すると、メモリー不足の原因になる大きなメッセージ・バックログが発生しません。WebLogic JMSでは、割当てがデフォルトで設定されていません。
割当てを設定するために複数のオプションがありますが、多くの場合は、宛先レベルの割当てを使用するより、Messages Maximum割当てを各JMSサーバーに設定するのみで十分です。現在のすべてのJMSメッセージでは、メッセージがページ・アウトされても、JVMメモリーが消費されます。これは、ページングにより、メッセージ・ヘッダーではなく、メッセージ本文のみページ・アウトされるためです。キューに関する原則として、現在のすべてのJMSメッセージでは、512バイトのメモリーが消費されることが推測されます。トピックに関する原則として、現在のJMSメッセージでは、256バイトのメモリーとメッセージをまだ承認していないサブスクライバのために追加の256バイトのメモリーが消費されることが推測されます。たとえば、トピック上に3つのサブスクライバがある場合、いずれかのサブスクライバによって処理されていない1つの発行されたメッセージに対して、メッセージがページ・アウトされた場合でも、256 + 256*3 = 1024バイトのメモリーが消費されます。ベスト・プラクティスは、メッセージ・ヘッダー・メモリー使用量が原則によって示された量より大幅に小さいとしても、メモリー使用量に対して控えめな推定を行うことです。
以前のリリースでは、複数のレベルの割当てがありました。宛先には独自の割当てがあり、同時にJMSサーバー内の割当てをめぐって競合する必要もありました。このリリースでは、割当てのレベルは1つだけです。宛先では、独自のプライベートの割当てを使用することも、共有割当てを使用して他の宛先と競合することもできます。
独自の割当てを定義する宛先は、JMSサーバーの割当てのスペースを共有しません。JMSサーバーでは、引き続きメッセージとバイトの割当てを直接構成できますが、これらのオプションは割当てリソースを参照しない宛先の割当てを定義するためにのみ使用できます。
割当てとは、構成可能な名前付きのJMSモジュール・リソースです。割当てでは、メッセージおよびバイトの最大数を定義します。これを1つまたは複数の宛先に関連付けることで、定義した最大数を強制することができます。同じ割当てを参照する複数の宛先は、割当てリソースの共有ポリシーに従ってその割当てを共有します。
割当てリソースでは、次のパラメータを構成できます。
表13-1割当てのパラメータ
| 属性 | 説明 |
|---|---|
最大バイト数と最大メッセージ数 |
割当ての「最大メッセージ数」および「最大バイト数」パラメータでは、その割当てリソースで使用できるメッセージとバイトの最大数を定義します。保留中のメッセージは考慮されません - つまり、処理中であったり遅延されていたり、もしくは配信が抑制されているメッセージが、メッセージ数やバイト数の割当てに突き合わせて計数されます。 |
割当ての共有 |
割当てリソースの「共有」パラメータでは、同じ割当てリソースを参照する複数の宛先が、リソースの使用において相互に競合するかどうかを定義します。 |
割当てポリシー |
「ポリシー」パラメータでは、使用できる割当てがない場合に、個々のクライアントが割当てをめぐってどのように競合するかを定義します。「サイズの大きなメッセージのチューニング」で説明されているとおり、接続ファクトリで送信タイムアウト機能が有効になっている場合、このパラメータは送信リクエストのブロックが解除される順序に影響します。 |
割当ての構成パラメータの詳細は、Oracle WebLogic Server MBeanリファレンスのQuotaBeanを参照してください。WebLogic Server管理コンソールを使用した割当てリソースの構成に関する指示については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの宛先用割当ての作成に関する項を参照してください。
宛先では、割当てのバイトおよびメッセージの最大数は定義しないことになりました。代わりに、これらの値を定義した割当てリソースと、共有および競合に関する割当てポリシーを使用できます。
宛先の「割当て」パラメータでは、その宛先に割当てを強制するためにどの割当てリソースを使用するかを定義します。この値は動的で、いつでも変更できます。ただし、割当てリソースを変更した時点でその割当ての未処理リクエストがあると、そうしたリクエストはjavax.jms.ResourceAllocationExceptionで失敗します。
注意:
割当ての未処理リクエストは、割当てリソースが変更されたときに失敗します。これは、宛先の割当てを他の割当てに切り替えたときに失敗することを意味し、割当てリソースのメッセージ属性やバイト属性を変更したときには失敗しません。
宛先で割当てを構成しない場合もあります。JMSサーバーの割当てを使用すると、これらの「割当てを構成していない」宛先で使用するリソースを制限できます。「割当て」属性が明示的に設定されていないすべての宛先は、それらがデプロイされているJMSサーバーの割当てを共有します。この場合の動作は、「共有」パラメータが有効になっている各JMSサーバーに特別な割当てリソースが定義されている場合とまったく同じです。
JMSサーバーの割当てのインタフェースは、以前のリリースから変更されていません。JMSサーバーの割当ては、JMSServerMBeanのメソッドを使用して完全に制御できます。JMSサーバーの割当ての割当てポリシーは、JMSサーバーで「ブロッキング時の送信ポリシー」パラメータを使用して設定します。詳細については、「JMSサーバーでの「ブロッキング時の送信ポリシー」の指定」を参照してください。JMSサーバーの割当ての割当てポリシーも、他の割当てのポリシー設定と同じように機能します。それは、他の割当てのポリシー設定と同じように機能します。
割当て条件内で(送信タイムアウトを定義して)プロデューサをブロックすると、アプリケーションのパフォーマンス、および割当て失敗時のメッセージ送信の継続した再試行におけるベンチマークが大幅に向上します。「送信タイムアウト」機能を使用すると、宛先でスペースを利用できるようになるまで指定の時間にわたってメッセージの生成を待機できるため、メッセージ送信処理をより細かく制御できます。たとえば、プロデューサがリクエストを行い、十分なスペースが存在しない場合、プロデューサはスペースが利用可能になるまでブロックされるか、または処理がタイムアウトになります。別のフロー制御方法については、「JMSサーバーおよび宛先のメッセージのフロー制御」を参照してください。
WebLogic Server管理コンソールを使用して、宛先がメッセージの最大割当てを超過したときにJMS接続ファクトリがメッセージのリクエストをブロックする時間を定義する手順は次のとおりです。
WebLogic JMSでは、非同期コンシューマ(または、メッセージ・リスナーとして知られている)またはプリフェッチを有効にした同期コンシューマに送信されたメッセージがパイプラインされます。これにより、パフォーマンスが向上します。これは、メッセージがサーバーからクライアントへに内部的にプッシュされと集合するためです。接続ファクトリのMessagesMaximumの設定を構成すると、JMSサーバーとクライアント間のメッセージ・バックログ(パイプラインのサイズ)をチューニングできます。『Oracle WebLogic Server JMSアプリケーションの開発』の非同期のメッセージ・パイプラインに関する項を参照してください。
一部の環境では、MessagesMaximumパラメータをチューニングすることでパフォーマンスが大幅に向上することがあります。たとえば、JMSアプリケーションで確認応答やコミットが保留されている場合などです。この場合、MessagesMaximumに次の値を設定することをお薦めします。
2 * (ack or commit interval) + 1
たとえば、JMSアプリケーションで一度に50メッセージを確認応答する場合、MessagesMaximumの値を101に設定します。
MessagesMaximumの値が大きすぎると、以下のような状況になることがあります。
クライアントのメモリー使用量が増加します。
既存のクライアントのパイプラインがメッセージで一杯になり処理が集中します。たとえば、MessagesMaximumに10,000,000を設定した場合、最初に接続するコンシューマ・クライアントで、すでに宛先に届いているすべてのメッセージが取得されます。この場合、他のコンシューマは1つもメッセージのない状態のままで、最初のコンシューマで不要なメッセージのメッセージのバックログが作成され、システムのメモリーが不足することがあります。
パケットが大きすぎるという例外が発生し、コンシューマが膠着状態になります。コンシューマに送信されたメッセージの合計サイズが、現在のプロトコルの最大メッセージ・サイズ(デフォルト・サイズは10MB。コンソールを使用してWebLogic Serverインスタンスごとに、また-Dweblogic.MaxMessageSizeコマンド行プロパティを使用してクライアントごとに構成されている)より大きいと、メッセージの配信が失敗します。
大きなメッセージを送受信するときに、WebLogic ServerインスタンスのみではなくWebLogicクライアントも構成する必要があります。
多くのプロトコル(T3を含む)は、WLSでのネットワーク・コールのサイズがデフォルトで10MBに制限されています。個別のJMSメッセージのサイズまたは同じネットワーク・コールに一括処理されている一連のJMSメッセージのサイズは、制限値を超える場合、パッケージのサイズが大きすぎるという例外が発生するか、またはコンシューマが停止する可能性があります。非同期コンシューマを使用すると、複数のJMSメッセージが同じネットワーク・コールに一括処理されます。このように一括処理されたメッセージのサイズを制御する場合は、「MessageMaximumの制限のチューニング」を参照してください
サーバーのインスタンスにメッセージの最大サイズを設定するには、含まれるすべてのデフォルトのチャネルまたはカスタム・チャネルに対して、サポート済の各プロトコルの最大のメッセージ・サイズをチューニングしてください。このコンテキストでは、「メッセージ」とは指定したプロトコル上のJMSコールのみではなく、すべてのネットワーク・コールを意味します。
次のコマンド行プロパティを使用して、クライアント上の最大のメッセージ・サイズを設定します。
-Dweblogic.MaxMessageSize
注意:
この設定は、JMS関連パケットのみでなく、クライアントに配信されるすべてのWebLogic Serverネットワーク・パケットに対して適用されます。
メッセージ圧縮のしきい値は、WLMessageProducerインタフェースのJMS API拡張機能を使用することによってプログラム的に設定するか、接続ファクトリまたはJMS SAFリモート・コンテキストで「デフォルト圧縮しきい値」を指定することによって管理的に設定できます。メッセージの種類によっては、圧縮によって実際にはサイズが大きくなることがあるため、圧縮されたメッセージが宛先の割当てに影響するおそれがあります。
WebLogic Server管理コンソールを使用してデフォルト圧縮しきい値を構成する手順については、次を参照してください。
接続ファクトリ: Oracle WebLogic Server管理コンソール・オンライン・ヘルプのデフォルトの配信パラメータの構成に関する項。
ストア・アンド・フォワード(SAF)リモート・コンテキスト: Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAFリモート・コンテキストの構成に関する項。
構成されたメッセージ圧縮は、クライアント送信の場合はプロデューサ、メッセージ受信またはメッセージ・ブラウズの場合は接続ファクトリに対して、またはSAF転送を通じて実行されます。メッセージはGZIPで圧縮されます。圧縮は、メッセージのプロデューサとコンシューマが別々のサーバー・インスタンスに配置されていてメッセージがJVM境界をまたぐ場合(通常は、WebLogicドメインが別のマシンにあってネットワーク接続をまたぐ場合)にのみ発生します。解凍は、メッセージのコンテンツがアクセスされたときに、クライアント・サイドで自動的に発生します。ただし、以下の状況でも解凍が発生します。
圧縮形式のXMLメッセージでメッセージ・セレクタを使用すると、解凍の問題が発生します。これは、メッセージ本文は、メッセージをフィルタするためにアクセスする必要があるからです。XMLメッセージ・セレクタの定義の詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージのフィルタ処理に関する項を参照してください。
以前のバージョンのWebLogic Serverと相互運用していると、解凍が発生することがあります。たとえば、メッセージング・ブリッジを使用している場合、現在のリリースのWebLogic Serverから送信されたメッセージが以前のバージョンのWebLogic Serverで受信されると、受信サイドでメッセージが解凍されます。
サーバー側では、ディスクに書き込まれるときでも、メッセージは常に圧縮されたままです。
メッセージ・ページング機能を使用すると、メッセージ負荷のピークときにJMSサーバーによって自動的に仮想メモリーの開放が試行されます。この機能は、大容量のメッセージ領域を使用するアプリケーションでは大きなメリットがあります。JMSサーバーでは常にメッセージ・ページングが有効になっており、メッセージ・ページング・ディレクトリは自動的に作成されるため構成する必要はありません。ただし、「ページング・ディレクトリ」オプションを使用してディレクトリを指定することもでき、その場合はページングされたメッセージがこのディレクトリ内のファイルに書き込まれます。
JMSサーバーでは、ページング・ディレクトリに加え、ファイル・ストアまたはJDBCストアを使用して、永続メッセージが格納されます。ファイル・ストアは、ユーザー定義またはサーバーのデフォルトのストアのことです。ページングされたJDBCストアの永続メッセージは、JDBCストアとJMSサーバーのページング・ディレクトリの両方にコピーされます。ページングされたファイル・ストアの永続メッセージの小さいメッセージは、ファイル・ストアとJMSサーバーのページング・ディレクトリの両方にコピーされます。ページングされた大きなファイル・ストアのメッセージは、ページング・ディレクトリにコピーされません。「永続ストアを使用するときのベスト・プラクティス」を参照してください。
ただし、ページアウトされるメッセージは消費するメモリーのすべてを解放することはありません。メッセージ・ヘッダーは、メッセージ本文と一緒にページアウトされるすべてのユーザー・プロパティを除いて、検索/ソート/フィルタリングで使用するためにメモリーに残るからです。ページングされるメッセージの選択にセレクタを使用するキュー・アプリケーションでは、ページアウトされたメッセージをページ・インして戻す必要があるため、パフォーマンスが大幅に低下する場合があります。これは、メッセージ・ヘッダー・フィールド(CorrelationIDなど)に基づきメッセージを選択するトピックまたはアプリケーションに適用されません。原則として、各メッセージは、ページ・アウトしたときにJVMメモリーの512バイトを使用することを仮定します。
ページング・ディレクトリが指定されていない場合、ページングされたメッセージの本文はドメインのルート・ディレクトリのservernameサブディレクトリ内にある、デフォルトの\tmpディレクトリに書き込まれます。たとえば、デフォルトのページング・ディレクトリが指定されていない場合、次のディレクトリがデフォルトになります。
oracle_home\user_projects\domains\domainname\servers\servername\tmp
domainnameは、ドメインのルート・ディレクトリ(通常はc:\Oracle\Middleware\Oracle_Home\user_projects\domains\domainname)です。これは、WebLogic Serverプログラム・ファイルが格納されるディレクトリ(通常はc:\Oracle\Middleware\Oracle_Home\wlserver)に対応するディレクトリです。
メッセージ・ページング・ディレクトリ属性を構成するには、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバーの一般的なプロパティの構成に関する項を参照してください。
「メッセージ・バッファ・サイズ」オプションでは、ディスクにページングされる前のメモリー内のメッセージ本文を格納するために使用するメモリーの量を指定します。「メッセージ・バッファ・サイズ」のデフォルト値は、JVMの最大ヒープ・サイズのおよそ3分の1、または最大値の512MBになります。このパラメータの設定値を大きくするほど、多くのメッセージがキューまたはトピックに待機している際にJMSでより多くのメモリーが消費されます。このしきい値を超えると、JMSはメモリー使用量をしきい値未満に抑えようとして、「ページング・ディレクトリ」オプションで指定したディレクトリに、メッセージ本文を書き込むことがあります。
このパラメータは割当てではない点に留意してください。サーバー上のメッセージ数がしきい値を超えると、サーバーはメッセージをディスクに書き込み、できるだけ速やかにメモリーから削除してメモリー使用量を減らします。ただし、新しいメッセージの受信を休止することはありません。それでも、メッセージ受信速度がページング速度を上回る場合は、メモリー不足になる可能性があります。メッセージ負荷の大きいユーザーができるかぎり高い可用性をサポートするには、割当てを設定するか、しきい値を設定してフロー制御を有効にすることで、サーバー上でのメモリー使用量を減らすことを検討してください。
フロー制御機能を使うと、過負荷状態になっていると判断したJMSサーバーや宛先は、メッセージ・プロデューサの処理速度を遅くすることができます。「メッセージの圧縮」を参照してください。
次の項では、フロー制御の仕組みと、接続ファクトリでフロー制御を構成する方法について説明します。
JMSサーバーまたはその宛先は、指定のバイト数またはメッセージ数のしきい値を超えると防御され、メッセージ・フロー(1秒当たりのメッセージ数)を制限するようプロデューサに指示します。
プロデューサは、JMS接続ファクトリを通じてプロデューサ用に構成された一連のフロー制御属性に基づき、生成率を制限します。プロデューサは、指定した最大フローのメッセージ数から開始して、所定の間隔ごとに(たとえば、10秒間、60秒ごとに)、サーバー/宛先がまだ防御されているかを評価します。その時点において、サーバー/宛先がまだ防御されていれば、プロデューサは所定の最小フロー値まで本番率を低下させます。
プロデューサの処理速度が低下するにつれ、しきい値条件は徐々に補正されます。これはサーバー/宛先が防御を解除されるまで行われます。この時点で、プロデューサは生成率を上げることができるようになりますが、必ずしも最大限まで上げる必要はありません。実際には、メッセージ・フローは、所定の最大フローに達してフロー制御の対象でなくなる時点までは(サーバー/宛先が防御を解除されていても)引き続き制御されます。
プロデューサは、セッションから一連のフロー制御属性を受信します。セッションは接続から、接続は接続ファクトリから、この属性を受信します。これらの属性により、プロデューサはメッセージ・フローを調整できます。
具体的には、プロデューサはフローを最小値から最大値までの範囲内に制限する属性を受信します。プロデューサは、条件が悪くなると最小値側に移動し、改善されると最大値側に移動します。最小値側および最大値側への移行は、移行率を指定する2つの追加属性によって定義されます。また、最小値側および最大値側への移行の必要性は構成された間隔ごとに評価されます。
次の表では、フロー制御オプションについて説明します。
表13-2 フロー制御パラメータ
| 属性 | 説明 |
|---|---|
フロー制御を有効化 |
プロデューサがJMSサーバーによってフロー制御可能かどうかを決定します。 |
最大フロー |
しきい値の条件に達したプロデューサに対する秒当たりの最大メッセージ数。 しきい値の条件に達したときにプロデューサでフローを制限していない場合、そのプロデューサの初期フロー制限が最大フローに設定されます。しきい値の条件に達したときにプロデューサがすでにフローを制限している場合(フロー制限は最大フロー未満)、プロデューサは次にフローが評価されるまで現在のフロー制限で処理を継続します。 いったん、しきい値条件への抵触を回避してからは、プロデューサはフロー限度を無視できなくなります。このフロー制限が「最大フロー」未満の場合、プロデューサはフローが評価されるたびにそのフローを徐々に最大フローまで増やす必要があります。プロデューサが最大フローに達すると、そのフロー制限を無視し、そのフローを制限せずに送信できます。 |
最小フロー |
しきい値の条件に達したプロデューサに対する秒当たりの最小メッセージ数。これはプロデューサのフロー制限の下限値。つまり、フロー制限が最小フローに達したプロデューサの処理速度はWebLogic JMSによってそれ以上落とされません。 |
フロー間隔 |
プロデューサが最大フローのメッセージ数から最小フローに、またはその反対にフローを調整するときの調整期間(秒単位)。 |
フロー・ステップ |
プロデューサがフローを最大フローのメッセージ数から最小フローに、またはその反対にフローを調整する場合に使用されるステップ数。具体的には、フロー間隔の調整期間がフロー・ステップ数に分割されます(たとえば、60秒を6ステップで除算するとステップあたり10秒になります)。 また、最大フローと最小フローの差をステップに分割することにより、移動(調整率)が計算されます。各フロー・ステップでは、次のように、現在の条件に基づき必要に応じてフローが上方または下方に調整されます。 下方への移動は、フロー間隔で指定した時間の経過に伴い、フロー・ステップで指定した値に従って幾何的に減衰する(たとえば、100、50、25、12.5)。 上方移動は線形です。差は単にフロー・ステップ数で除算されます。 |
フロー制御フィールドおよびこのフィールドの有効な値とデフォルト値については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMS接続ファクトリ: 構成: フロー制御を参照してください。
バイト数またはメッセージ数のしきい値の構成に使用する属性は、JMSサーバーまたはその宛先の一部として定義されます。表13-3に、上限しきい値と下限しきい値がJMSサーバーまたはJMS宛先のフロー制御を開始および停止する仕組みを示します。
表13-3 フロー制御しきい値パラメータ
| 属性 | 説明 |
|---|---|
最大バイトしきい値/最大メッセージしきい値 |
バイト数またはメッセージ数がこのしきい値を超えると、JMSサーバー/宛先は防御され、プロデューサに対してメッセージ・フローを制限するよう指示します。 |
最小バイトしきい値/または最小メッセージしきい値 |
バイト数またはメッセージ数がこのしきい値を下回ると、JMSサーバー/宛先は防御を解除され、プロデューサに対してメッセージ・フローを増やし始めるよう指示します。 フロー制御は、メッセージの最大フローを下回っているプロデューサについては、引き続き有効です。プロデューサは、最大フローに到達してフロー制御が行われなくなるまで、生成率を上げ続けることができます。 |
JMSサーバーおよび宛先のその他のしきい値フィールドと割当てフィールドの詳細、およびそれらの有効値とデフォルト値については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次のページを参照してください。
次の項では、メッセージの有効期限ポリシーとアクティブな有効期限処理という2つのメッセージ有効期限機能について説明します。これらの機能を使用すると、期限切れメッセージを検索する方法とそれらを検出したときの処理方法をより細かく制御できます。
アクティブなメッセージ有効期限を使用すると、期限切れメッセージが即座に消去されます。さらに期限切れメッセージの監査を使用すると、メッセージがいつ期限切れになったかをログに書き込むか、または期限切れメッセージを定義済のエラー宛先にリダイレクトすることによって、期限切れメッセージを追跡できます。
有効期限ポリシーを使用して、メッセージが期限切れになったときに実行するアクションを定義します。「宛先」ノードの「有効期限ポリシー」属性では、宛先ごとに有効期限ポリシーを設定できます。「有効期限ポリシー」属性を使用すると、期限切れメッセージの検出時に宛先で実行されるアクション(メッセージの破棄、メッセージの破棄とログへの書き込み、またはエラー宛先へのリダイレクト)を定義できます。
また、JMSテンプレートを使用して複数の宛先を構成する場合、「有効期限ポリシー」フィールドを使用して、すべての宛先の有効期限ポリシーをすばやく構成できます。特定の宛先に関するテンプレートの有効期限ポリシーをオーバーライドするには、その宛先の有効期限ポリシーを変更します。
有効期限ポリシーの構成手順については、次のリンクをクリックしてください。
JMSテンプレートを使用せずにトピックの有効期限ポリシーを構成する場合は、次の手順に従います。特定のトピックに有効期限ポリシーを設定すると、JMSテンプレートに定義されている設定はオーバーライドされます。
JMSテンプレートを使用せずにキューの有効期限ポリシーを構成する場合は、次の手順に従います。特定のキューに有効期限ポリシーを設定すると、JMSテンプレートに定義されている設定はオーバーライドされます。
JMSテンプレートを使用すると、似た属性設定を持つ複数の宛先(トピックまたはキュー)を効率的に定義できます。このため、宛先用の既存のテンプレート上でメッセージ有効期限ポリシーを構成できます。
この項では、有効期限ポリシーについて説明します。
「有効期限ロギング・ポリシー」パラメータはこのリリースのWebLogic Serverでは非推奨となっています。代わりに、メッセージ・ライフ・サイクルのロギング機能を使用することをお薦めします。この機能を使用すると、JMSサーバーに届いたJMSメッセージに発生する基本的なイベントを、詳細な有効期限データも含め包括的に把握できます。メッセージのライフサイクルのロギング・オプションの詳細は、『Oracle WebLogic Server JMSリソースの管理』のメッセージのライフサイクルのロギングに関する項を参照してください。
たとえば、次のいずれかの値を指定できます。
JMSPriority、Name、Address、City、State、Zip
%header%、Name、Address、City、State、Zip
JMSCorrelationID、%properties%
JMSMessageIDフィールドは常にログに書き込まれ、無効にはできません。したがって、有効期限ポリシーが定義されていない(「なし」)か、空の文字列として定義されている場合、ログ・ファイルへの出力にはメッセージのJMSMessageIDのみが含まれます。
期限切れメッセージがログに書き込まれる場合、メッセージのテキスト部分(タイムスタンプ、重大度、スレッド情報、セキュリティIDなどを除く)は次のフォーマットに準拠します。
<ExpiredJMSMessage JMSMessageId='$MESSAGEID' > <HeaderFields Field1='Value1' [Field2='Value2'] … ] /> <UserProperties Property1='Value1' [Property='Value2'] … ] /> </ExpiredJMSMessage>
$MESSAGEIDはMessage.getJMSMessageID()によって返される文字列です。
例:
<ExpiredJMSMessage JMSMessageID='ID:P<851839.1022176920343.0' > <HeaderFields JMSPriority='7' JMSRedelivered='false' /> <UserProperties Make='Honda' Model='Civic' Color='White'Weight='2680' /> </ExpiredJMSMessage>
ヘッダー・フィールドが表示されない場合、ヘッダー・フィールド行は表示されません。ユーザー・プロパティが表示されない場合、その行は表示されません。ヘッダー・フィールドとプロパティが存在しない場合、開始タグは閉じカッコ(/>)で閉じることができるので終了タグ</ExpiredJMSMessage>は必要ありません。
例:
<ExpiredJMSMessage JMSMessageID='ID:N<223476.1022177121567.1' />
すべての値は引用符で区切られます。すべての文字列値は32文字に制限されます。リクエストされたフィールドまたはプロパティが存在しない場合、それらは表示されません。リクエストされたフィールドまたはプロパティが存在するが値がない(null値)場合、それらはnullとして(単一引用符なしで)表示されます。リクエストされたフィールドまたはプロパティが空文字の場合、それらは1組の単一引用符(間にスペースなし)として表示されます。
例:
<ExpiredJMSMessage JMSMessageID='ID:N<851839.1022176920344.0' > <UserProperties First='Any string longer than 32 char ...' Second=null Third='' /> </ExpiredJMSMessage>
アクティブな有効期限処理機能を使用すると、期限切れメッセージをそれが送信またはパブリッシュされた宛先から削除するタイミングを定義できます。メッセージは必ずしも有効期限に削除されず、ユーザー定義の秒数以内に削除されます。秒数が少ないほど、メッセージの削除が実際の有効期限に近づきます。
JMSサーバーが宛先をアクティブにスキャンして期限切れメッセージを処理する方法を定義するには、次の手順に従います。デフォルト値は30秒です。つまり、JMSサーバーは各スキャンの間で30秒待機します。
設計上の選択には、JMSアプリケーションのパフォーマンスに影響を与えるものが多数あります。信頼性、スケーラビリティ、管理容易性、モニター、ユーザー・トランザクション、メッセージドリブンBeanのサポート、アプリケーション・サーバーとの統合などの要素がパフォーマンスに影響します。また、WebLogic JMSの拡張と機能もパフォーマンスに直接的な影響を与えます。
JMSのアプリケーションの設計の詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』のアプリケーション設計のベスト・プラクティスに関する項を参照してください。
メッセージ順序単位はWebLogic Serverの付加価値機能です。スタンドアロンのメッセージ・プロデューサや、単体として動作するプロデューサのグループは、この機能を使用して複数のメッセージを処理順序(下位順序)に応じた1つの単位にグループ化できます。この単位を順序単位(UOO)と呼び、この単位にまとめられたすべてのメッセージは作成順に従って処理されます。以下の複雑な設計パターンについてUOOを使用するように置き換えます。
下位順序ごとに一意のセレクタを持つ専用コンシューマ
下位順序ごとに1つの新しい宛先、宛先ごとに1つのコンシューマ。
『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージ順序単位の使用に関する項を参照してください。
次の項では、UOO使用時のベスト・プラクティスについて説明します。
厳格なメッセージ順序要件があるアプリケーションにおいて理想的です。UOOにより管理やアプリケーション設計が簡略化され、ほとんどのアプリケーションでパフォーマンスが向上します。
MDBバッチ処理を使用すると以下のことが可能になります。
単一の下位順序内のメッセージ処理が高速化します。
同じトランザクションにおいて一度に複数のメッセージを消費します。
「メッセージドリブンBeanのチューニング」を参照してください
宛先にはデフォルトのUOOを構成できます。宛先では一度に1つだけのコンシューマがデフォルトのUOOのメッセージを処理します。
分散宛先を使用している場合、厳格なメッセージ順序を確実に適用するために、各UOOは特定の物理宛先のインスタンスに固定されます。所定のUOOに対して自動的に適切な物理宛先を決定するため、以下の2つのオプションが用意されています。
ハッシュ処理 - 通常、より高速なUOOの設定です。ハッシュ処理では物理宛先を決定するために、UOO名に対してハッシュ関数を使用します。この方法は次の点でデメリットがあります。
分散宛先に対する物理宛先の管理的な削除または追加を正しく処理できません。
UOOが利用不可能な宛先にハッシュ化された場合、メッセージの送信が失敗します。
パス・サービス - UOOごとに物理宛先をマップする、単一サーバーのUOOディレクトリ・サービスです。パス・サービスは通常、1秒間に異なる名前のUOOが数多く作成された場合、ハッシュ処理よりも低速です。この場合、メッセージの送信前に、新しいUOO名のそれぞれによってパス・サービスのチェックが暗黙的に強制されます。1秒間に作成されるUOOの数が制限されている場合、UOOのパスがクラスタ全体でキャッシュされるのでパス・サービスのパフォーマンスが問題になることはありません。
WebLogic Server 9.0より前のリリースでは、厳格なメッセージ順序要件のあるアプリケーションで次のことを行う必要がありました。
1つの物理宛先を1つのコンシューマと一緒に使用します。
非同期コンシューマの最大メッセージ・バックログ(接続ファクトリのMessagesMaximumパラメータ)は必ず1に設定します。
UOOでは、任意のサイズの複数のコンシューマおよび非同期コンシューマ・メッセージ・バックログが利用できるので、これらの要件が幅広く緩和されています。UOOを使用するために古いアプリケーションを移行するには、デフォルトのUOO名を物理宛先に設定してください。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続ファクトリの順序単位パラメータの構成に関する項、および『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージの順序付き再配信に関する項を参照してください。
一方向メッセージ送信は、送信側によってボトルネックとされているアプリケーションのパフォーマンスを大幅に向上させることが可能ですが、それを行うとQOS(サービス品質)が低下するリスクが生じます。JMSプロデューサからの一般的なメッセージ送信は、内部リクエストおよび内部レスポンスの両方が含まれることから、双方向送信と呼ばれています。プロデューサ・アプリケーションがsend()を呼び出すと、この呼出しは、アプリケーションのメッセージが含まれるリクエストを生成し、そのメッセージの受信を確認するまでJMSサーバーからのレスポンスを待機します。この呼出し/レスポンス・メカニズムでは、プロデューサが制御されます。これは、プロデューサ・アプリケーションは、別の送信呼出しを行うことができるようになるまで、JMSサーバーのレスポンスを待機するように強いられるためです。レスポンス・メッセージをなくすことによって、この待機時間もなくなり、一方向送信となります。WebLogic Serverでは、非永続、非トランザクションのメッセージ処理に対して構成可能な一方向送信オプションがサポートされています。この機能は、アプリケーション・コードを変更することなく利用できます。
一方向送信モードのオプションを有効にすると、ユーザー定義の接続ファクトリで作成したメッセージ・プロデューサで、一方向メッセージ送信ができるようになります(可能な場合)。一方向メッセージ送信が可能な場合、関連付けられたプロデューサは、ターゲット宛先のホストJMSサーバーからのレスポンスを内部で待機することなく、メッセージを送信できます。キュー・センダーおよびトピック・パブリッシャに一方向送信を許可したり、この機能をトピック・パブリッシャのみに制限したりできます。一方向ウィンドウ・サイズを指定して、追加の一方向送信を続行する前に、プロデューサを制御するために双方向メッセージが必要になる時期を決定する必要があります。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続ファクトリ・フロー制御の構成に関する項に記載されているように、WebLogic Server管理コンソールを使用して接続ファクトリに一方向のメッセージ送信パラメータを構成します。FlowControlParamsBean MBeanを通じて、WebLogic Scripting Tool (WLST)またはJMXを使用することもできます。
注意:
接続ファクトリが「XA対応」として構成されている場合、一方向メッセージ送信は無効になります。この設定では、送信側が実際にトランザクションを使用しているかどうかに関係なく、一方向送信が無効になります。
宛先が1つの場合のクラスタで一方向送信をサポートするには、宛先をホストしているJMSサーバーと接続ファクトリが、同じWebLogicサーバーにターゲット指定されていることを確認します。接続ファクトリが、クラスタ内のその他のWebLogic Serverインスタンスにターゲット指定されている場合はサポートされません。
同じ名前を共有する宛先が複数ある場合のクラスタで一方向送信をサポートするには、クライアント接続をホストしているWebLogic Serverインスタンスでもその宛先を確実にホストする必要があります。1つのソリューションを次に示します。
このソリューションでは、EJBホームおよびJMS接続ファクトリを含む、クラスタリングされたRMIオブジェクト用のRMIレベルのロード・バランシングは無効にされます。クライアントはJNDIコンテキストの確立に使用されるネットワーク・アドレスにのみ基づいて接続および宛先を効率的に取得します。ロード・バランシングは、WebLogic Serverアドレスのカンマ区切りのリストが含まれる複数のURL、または、ネットワーク管理者によって構成されるIPアドレスのround-robinセットに解決されるDNS名を指定する複数のURLに対して行われる、ネットワーク・ロード・バランシングを利用することによって達成されます。
クラスタ用サーバー・アフィニティの詳細は、『Oracle WebLogic Serverクラスタの管理』のEJBとRMIオブジェクトのロード・バランシングに関する項を参照してください。
一方向送信は、ターゲット宛先をホストしているJMSサーバーとクライアント・プロデューサの接続ホストが、同じWebLogic Serverインスタンスである場合にサポートされます。そうでない場合、一方向モード設定は無視され、標準の双方向送信が代わりに使用されます。
クライアントのホスト接続ファクトリが「XA対応」として構成されている場合、一方向メッセージ送信は無効になります。この設定では、送信側が実際にトランザクションを使用しているかどうかに関係なく、一方向送信が無効になります。
次に示す、より高度なQOS機能が検出された場合には、一方向モードの設定は無視され、代わりに標準の双方向送信が使用されます。
XA
トランザクション・セッション
永続メッセージ
順序単位
作業単位
分散宛先
ターゲット宛先で指定された割当てを超過している場合、その割当てがクリアになるまで標準の双方向送信が使用されます。
割当てを超過する一方向メッセージは、例外がクライアントに即座に返されることなく、通知のないまま削除されます。クライアントは、次の双方向送信が行われる際、宛先が割当てをまだ超過している場合に、割当ての例外を取得することになります。(一方向モードでも、クライアントは、クライアントの接続ファクトリで構成された「一方向送信ウィンドウ・サイズ」のメッセージ数ごとに双方向メッセージを送信します。)
割当て条件内で通知なしにメッセージが削除されるのを回避できる1つの方法は、接続ファクトリで構成される「Blocking Send Timeout」の値を増やすことです(「メッセージの圧縮」を参照)。一方向メッセージは、即座に削除されることはありませんが、メッセージが消費されるか、期限切れになることによって割当て条件がクリアになるまでの一定時間、JMSサーバーで待機することになります。クライアントの送信側は、双方向メッセージを送信するまでブロックすることはありません。各クライアントに対して、一方向ウィンドウ・サイズの数を超えるメッセージが割当て条件がクリアになるのを待機してサーバー上で蓄積されることはありません。
サーバー側のセキュリティ・ポリシーで変更があると、JMSクライアントがその変更をセキュリティ・ステータスで通知されることなく、一方向メッセージ送信ができなくなる場合があります。
JMSサーバーまたはターゲット宛先が管理者によってアンデプロイされているとき、または、生成休止/再開の機能を使用してJMSサーバーあるいはターゲット宛先上のメッセージの生成が休止されている場合、一方向の送信を無効化することができます。『Oracle WebLogic Server JMSリソースの管理』の生成の休止と再開に関する項を参照してください。
一方向のメッセージ送信は、クライアントが論理的な分散宛先名を使用しないで、直接物理分散宛先メンバーを参照する場合、分散宛先で動作します。『Oracle WebLogic Server JMSアプリケーションの開発』の分散宛先の使用に関する項を参照してください。
ハードウェアまたはネットワークに障害があると、一方向送信は無効になります。こうした場合、JMSプロデューサは、OnExceptionまたは次の双方向メッセージ送信によって通知されます(一方向モードでも、クライアントは、クライアントの接続ファクトリで構成された「一方向送信ウィンドウ・サイズ」のメッセージ数ごとに双方向メッセージを送信します。)さらに、プロデューサが閉じられます。最悪の場合、障害が発生した直前の最後の双方向メッセージまでのすべてのメッセージが失われる場合があります。
一般的な非永続メッセージングで一方向送信モードを使用する場合は、次のQOS関連のガイドラインを使用します。
送信のブロック機能とともに使用し、正常に実行されているシステム上で一方向送信を使用すると、双方向送信モードを使用する場合と同様のQOSを達成できます。
トピック・パブリッシャの一方向送信モードは、JMS仕様で設定されているQOSガイドラインの範囲内に収まりますが、双方向モード(WebLogic Serverのデフォルト・モード)より低いQOSとなります。
『Oracle WebLogic Server JMSアプリケーションの開発』の非同期コンシューマに対する同期コンシューマに関する項に記載されているように、JMSコンシューマ・アプリケーションがシステムのボトルネックの場合、一方向送信モードでパフォーマンスが改善されない場合があります。
送信のバッチ・サイズ(ウィンドウ)の増加に対応するには、クライアントとサーバーの双方またはいずれかでJVMのヒープ・サイズを増やすことを検討します。可能メモリー使用量は、構成されたウィンドウのサイズおよび送信者の数に比例します。
送信側アプリケーションは、すべての割当て例外を受け取るわけではありません。割当てを超過する一方向メッセージは、例外が送信側クライアントに返されることなく、通知のないまま削除されます。詳細および考えられる回避策については、「宛先割当てを超過している」を参照してください。
接続ファクトリで一方向送信を構成すると、接続ファクトリで構成されているメッセージ・フロー制御パラメータが効率よく無効にされます。
デフォルトでは一方向ウィンドウ・サイズは1に設定されています。これによって、各一方向メッセージが双方向送信にアップグレードされるため、一方向送信は事実上無効化されます。(一方向モードでも、クライアントは、クライアントの接続ファクトリで構成された「一方向送信ウィンドウ・サイズ」のメッセージ数ごとに双方向メッセージを送信します。)したがって、一方向送信のウィンドウ・サイズはもっと大きな値に設定する必要があります。ウィンドウ・サイズは最初に300に設定し、後からアプリケーションの要件に応じて調整するようにすることが推奨されます。
クライアント・アプリケーションは、ネットワークまたはサーバーの障害に関する例外を即座に受け取るわけではなく、WebLogic Serverで障害が検出され、プロデューサが自動的に閉じられるまで、一部のメッセージは送信はされるものの、通知なしで削除される場合があります。詳細は、「ハードウェアに障害がある」を参照してください。
注意:
これは、ファイン・チューニングの詳細オプションです。通常は、ます初めに他のチューニング・オプションを検討するのが最良です。
JMS宛先の「メッセージング・パフォーマンス・プリファレンスのオプション」というチューニング・オプションを使用すると、コンシューマに配信可能なメッセージの完全なバッチが作成されるまで宛先が待機する時間(必要がある場合)を制御できるようになります。最小値の場合、バッチ処理は無効になります。デフォルト値よりも大きな値にチューニングすると、使用できるメッセージをバッチ処理するまで宛先が待機する時間が延長されます。完全なバッチの最大メッセージ数は、JMS接続ファクトリの「セッションあたりの最大メッセージ数」設定で制御されます。
この高度なオプションはWebLogic Server管理コンソールから利用できます。スタンドアロンおよび共通分散宛先(DestinationBean APIでも可能)、またはJMSテンプレート(TemplateBean APIでも可能)の全般構成のページを使用して設定します。
具体的に言うと、JMS宛先には、メッセージをバッチにまとめてコンシューマへ配信することにより、自動的にパフォーマンスを最適化しようとする内部アルゴリズムがあります。メッセージ・レートや他の要因の変化に応じて、こうしたアルゴリズムでバッチのサイズや配信時間が変更されます。ただし、このようなアルゴリズムですべてのメッセージング環境のパフォーマンスを最適化することはできません。「メッセージング・パフォーマンス・プリファレンスのオプション」を指定することで、メッセージ・レートや他の要因の変更に応じたアルゴリズムの対応方法を変更して、システムのパフォーマンスを調整できます。
「メッセージング・パフォーマンス・プリファレンスのオプション」には、次の構成パラメータがあります。
表13-4 「メッセージング・パフォーマンスのオプション」の値
| WebLogic Server管理コンソール値 | MBeanの値 | 説明 |
|---|---|---|
メッセージをバッチ処理しない |
0 |
メッセージのバッチ処理を事実上無効にします。利用可能なメッセージは即座にコンシューマへ配信されます。 これは、接続ファクトリの「セッションあたりの最大メッセージ数」フィールドを「1」に設定した場合に相当します。 |
待機せずメッセージをバッチ処理 |
25 (デフォルト) |
完全に満たないバッチが、利用可能なメッセージを含んだ状態で即座に配信されます。 これは、接続ファクトリの「セッションあたりの最大メッセージ数」フィールドに設定した値に相当します。 |
メッセージ・バッチ処理の最小待機しきい値 |
50 |
短期間だけ待機した後で、完全に満たないバッチが利用可能なメッセージを含んだ状態で配信されます。 |
メッセージ・バッチ処理の中間待機しきい値 |
75 |
場合に応じてより長く待機した後で、完全に満たないバッチが利用可能なメッセージを含んだ状態で配信されます。 |
メッセージ・バッチ処理の最大待機しきい値 |
100 |
場合に応じてさらに長く待機した後で、完全に満たないバッチが利用可能なメッセージを含んだ状態で配信されます。 |
ご使用のシステムに最適な値を見つけるためには、ある程度の実験が必要な場合もあります。たとえば、並列する多数のメッセージ・コンシューマが設定されたキューの場合、WebLogic Server管理コンソールで「メッセージをバッチ処理しない」の値を選択(またはDestinationBean MBeanに「0」を指定)すると、そのキューではコンシューマが利用可能になるとすぐに、できるかぎり早くそのコンシューマにメッセージをスローしようとします。反対に、迅速なレスポンスが求められないメッセージ・コンシューマが1つだけ設定されているキューの場合、管理コンソールで「メッセージ・バッチ処理の最大待機しきい値」という値を選択(またはDestinationBean MBeanに「100」を指定)すると、そのキューではメッセージをバッチの形でのみコンシューマにスローしようとし、結果として待機時間は増加しますが、スロー回数が少なくなるのでサーバー全体のスループットが向上する場合があります。
スタンドアロンの宛先、共通分散宛先、またはJMSテンプレートに対して、WebLogic Server管理コンソールで「メッセージング・パフォーマンスのプリファレンス」パラメータを構成する手順については、管理コンソール・オンライン・ヘルプの次の項を参照してください。
これらのパラメータの詳細は、Oracle WebLogic Server MBeanリファレンスのDestinationBeanとTemplateBeanを参照してください。
「メッセージング・パフォーマンス・プリファレンスのオプション」は、非同期メッセージ・パイプラインを使用する非同期コンシューマに対応しています。また、同期コンシューマのプリフェッチ・モード機能(非同期メッセージ・パイプラインをシミュレートする機能)を使用する同期コンシューマにも対応します。ただし、「最大メッセージ数」に設定されている値が小さすぎると、宛先のより高いレベルのパフォーマンス・アルゴリズム(たとえば、「メッセージ・バッチ処理の最小待機しきい値」、「メッセージ・バッチ処理の中間待機しきい値」、「メッセージ・バッチ処理の最大待機しきい値」)の影響が無効になる場合があります。非同期メッセージ・パイプラインの詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージの受信に関する項を参照してください。
多くのjavaクライアント側のアプリケーションでは、クライアント・スレッド・プールのデフォルト・サイズとして、5個のスレッドで十分です。アプリケーションに大量の非同期コンシューマがある場合、非同期コンシューマに設定されている数よりも少し多いスレッド数を割り当てると役に立ちます。これにより、さらに多くの非同期コンシューマを同時に実行できます。
WebLogicクライアント・プールの構成方法は、WebLogic serverスレッド・プールの構成方法とは異なり、自動チューニングされていません。WebLogicクライアントでは、サーバーから受信されるリクエストのためにJMS MessageListenerの起動など、特定のスレッド・プールが使用されています。このプールは、次のコマンド行プロパティを使用して構成できます。
-Dweblogic.ThreadPoolSize=n
ここでは、nは、スレッド数を示します。
クライアント側のスレッド・ダンプを使用して、この設定が有効になっていることを確認できます。
次に、JMS .NETクライアント・アプリケーションの作成時に使用するパフォーマンス関連のベスト・プラクティスを簡単に示します。
アイドル接続が失敗した場合にアプリケーションが対応する必要がある場合は、IConnectionを使用して接続例外リスナーを常に登録します。
複数の.NETクライアント・スレッドで1つのコンテキストを共有して、1つのソケットを使用するようにします。
コンテキスト、接続、セッション、プロデューサ、宛先、接続ファクトリなど、頻繁にアクセスするJMSリソースはキャッシュして再利用します。これらのリソースを作成してクローズすると、CPUとネットワーク帯域幅がかなり消費されます。
クラスタ内の複数のJMS .NETクライアント・ホスト・サーバーにわたってJMS .NETクライアントをロード・バランシングする場合は、DNS別名かカンマ区切りのアドレスを使用します。
JMS .NETクライアント・アプリケーションのベスト・プラクティスおよびその他のプログラミングに関する考慮事項については、『Oracle WebLogic Server JMS .NETクライアント・アプリケーションの開発』のプログラミングの考慮事項に関する項を参照してください。
次の項では、Oracle Data Guardを含むWebLogic JMS環境の構成に関する考慮事項を示します。
Oracle Data Guardの詳細は、http://www.oracle.com/us/products/database/options/active-data-guard/overview/index.htmlを参照してください。
メンテナンス時間が計画されている場合、本番データベース・インスタンスからスタンバイ・インスタンスへの切替えを開始する前に、影響を受けるJMS宛先を停止します。スタンバイ・データベースが本番に遷移したら、JMS宛先を再開します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの実行時のJMSサーバー・メッセージ操作の停止に関する項を参照してください。
