ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング
12c リリース1 (12.1.1)
B65905-02
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストヘ移動
製品		 目次へ移動
目次
前
前 		 次
次		  

14 WebLogic JMSのチューニング

この章では、WebLogic JMSの管理パフォーマンス・チューニング機能を実装することによってアプリケーションを最大限に活用する方法について説明します。

JMSパフォーマンス&チューニング・チェック・リスト

次の項には、WebLogic JMSをチューニングするときに考慮する項目のチェックリストが記載されています。

大きなメッセージ・バックログの処理

メッセージ送信者がコンシューマより速くメッセージを挿入する場合、メッセージはメッセージのバックログに蓄積されます。次の例のような理由で大きなバックログが問題になる場合があります。

メッセージ処理パフォーマンスの向上

確認する必要がある領域の一つとして、メッセージ処理パフォーマンス全体の向上があります。いくつかの提案を次に示します。

  • 「JMSパフォーマンス&チューニング・チェック・リスト」に記載されているJMSチューニングに関する推奨に従います。

  • 新規に開発されたアプリケーションにおけるプログラム・エラーを確認します。特に、非トランザクション・コンシューマがメッセージを承認していること、トランザクション・コンシューマがトランザクションをコミットしていること、プレーンjavax.jmsアプリケーションがjavax.jms.Connection.start()を呼出したこと、および特定のアプリケーションのニーズによってトランザクション・タイムアウトがチューニングされていることなどを確認します。プログラミング・エラーの現象としては、コンシューマがメッセージを何も受信しない(start()を呼出したことを確認する)、多くのキューが保留状態になっている、シャットダウンおよび再起動後に、すでに処理されている永続メッセージが再表示される、遅延後に、すでに処理されたトランザクション・メッセージが再表示される(デフォルトJTAタイムアウトは30秒で、デフォルト処理済セッション・タイムアウトは1時間)といった現象があげられます。

  • コンシューマによって処理されていないキューのWebLogic統計を確認します。分散キューに関する問題については、「分散キューのチューニング」を参照してください。

  • 保留カウントの高いトピックのWebLogic統計を確認します。これによって、通常は現在サービスが提供されていないトピック・サブスクリプションがあることが示されます。メッセージの処理を担当するコンシューマ・クライアントのレスポンスが遅延したり応答しない場合がある、永続サブスクリプションがもう必要ないため削除する必要がある可能性がある、あるいは遅延分散トピックの転送によってメッセージが蓄積していく可能性があります。管理コンソールで個別の永続サブスクリプションの統計を確認できます。アプリケーションでは、大きなバックログの永続サブスクリプションが作成され、削除されていない場合があります。処理されていない永続サブスクリプションは、管理上破棄されないかぎり、または標準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のプログラミング』のWebLogic JMSにおけるEJBとサーブレットを使用した拡張されたサポートに関する項を参照してください。このプーリング・コードは、ターゲット宛先が頻繁に変更する場合、プロデューサのプーリングを適切に行いません。ただし、この問題を回避するために、次の操作を実装します。アプリケーションがcreateProducer()を呼出すと、宛先にnullを渡して無名プロデューサを使用して、そのかわりに、目的の宛先を各送信コールに引き渡します。

分散キューのチューニング

作成されたメッセージがすべての分散キュー・メンバーの間に均等にロード・バランスされていない場合、プロデューサ接続ファクトリの構成を変更して、サーバー・アフィニティ(デフォルトで有効に設定されています)を無効に設定してください。

いったん作成されると、JMSコンシューマは特定のキュー・メンバーに固定されます。これにより、コンシューマがすべての分散キュー・メンバーの間に均等にロード・バランスされないという問題が発生する可能性があります。特に、すべてのコンシューマの初期化後、新しいメンバーが利用可能な場合に、この問題が発生します。コンシューマがすべての分散キュー・メンバーの間に均等にロード・バランスしない場合、メッセージを処理するために設計されたクラスタにターゲット指定されたMDBを使用するのが、ベストな方法です。WebLogic MDBは、すべての分散キュー・メンバーが処理されていることを自動的に確認します。MDBのオプションが存在しない場合に、コンシューマのロード・バランシングを向上するための提案を、次に示します。

トピックのチューニング

次の項では、WebLogicトピックのチューニング方法について説明します。

サイズの大きなメッセージのチューニング

次の項では、サイズの大きなメッセージを処理する際にJMSのパフォーマンスを向上させる方法について説明します。

割当ての定義

メッセージ数の割当てを必ず構成することを強くお薦めします。割当てを構成すると、メモリー不足の原因になる大きなメッセージ・バックログが発生しません。WebLogic JMSでは、割当てがデフォルトで設定されていません。

割当てを設定するために複数のオプションがありますが、多くの場合は、宛先レベルの割当てを使用するより、Messages Maximum割当てを各JMSサーバーに設定するのみで十分です。現在のすべてのJMSメッセージでは、メッセージがページ・アウトされても、JVMメモリーが消費されます。これは、ページングにより、メッセージ・ヘッダーではなく、メッセージ本文のみページ・アウトされるためです。キューに関する原則として、現在のすべてのJMSメッセージでは、512バイトのメモリーが消費されることが推測されます。トピックに関する原則として、現在のJMSメッセージでは、256バイトのメモリーとメッセージをまだ承認していないサブスクライバのために追加の256バイトのメモリーが消費されることが推測されます。たとえば、トピック上に3つのサブスクライバがある場合、いずれかのサブスクライバによって処理されていない1つの発行されたメッセージに対して、メッセージがページ・アウトされた場合でも1024(256 + 256*3)バイトのメモリーが消費されます。ベスト・プラクティスは、メッセージ・ヘッダー・メモリー使用量が原則によって示された量より大幅に小さいとしても、メモリー使用量に対して控えめな推定を行うことです。

以前のリリースでは、複数のレベルの割当てがありました。宛先には独自の割当てがあり、同時にJMSサーバー内の割当てをめぐって競合する必要もありました。このリリースでは、割当てのレベルは1つだけです。宛先では、独自のプライベートの割当てを使用することも、共有割当てを使用して他の宛先と競合することもできます。

独自の割当てを定義する宛先は、JMSサーバーの割当てのスペースを共有しません。JMSサーバーでは、引続きメッセージとバイトの割当てを直接構成できますが、これらのオプションは割当てリソースを参照しない宛先の割当てを定義するためにのみ使用できます。

割当てリソース

割当てとは、構成可能な名前付きのJMSモジュール・リソースです。割当てでは、メッセージおよびバイトの最大数を定義します。これを1つまたは複数の宛先に関連付けることで、定義した最大数を強制することができます。同じ割当てを参照する複数の宛先は、割当てリソースの共有ポリシーに従ってその割当てを共有します。

割当てリソースでは、次のパラメータを構成できます。

表14-1 割当てパラメータ

属性 説明

最大バイト数と最大メッセージ数

割当ての「最大メッセージ数」および「最大バイト数」パラメータでは、その割当てリソースで使用できるメッセージとバイトの最大数を定義します。保留中のメッセージは考慮されません - つまり、処理中であったり遅延されていたり、もしくは配信が抑制されているメッセージが、メッセージ数やバイト数の割当てに突き合わせて計数されます。

割当ての共有

割当てリソースの「共有」パラメータでは、同じ割当てリソースを参照する複数の宛先が、リソースの使用において相互に競合するかどうかを定義します。

割当てポリシー

「ポリシー」パラメータでは、使用できる割当てがない場合に、個々のクライアントが割当てをめぐってどのように競合するかを定義します。「サイズの大きなメッセージのチューニング」で説明されているとおり、接続ファクトリで送信タイムアウト機能が有効になっている場合、このパラメータは送信リクエストのブロックが解除される順序に影響します。

割当ての構成パラメータの詳細は、Oracle WebLogic Server MBeanリファレンスのQuotaBeanを参照してください。管理コンソールを使用して割当てリソースの構成に関する指示については、Oracle WebLogic Server管理コンソール・ヘルプの宛先用割当ての作成に関する項を参照してください。

宛先レベルの割当て

宛先では、割当てのバイトおよびメッセージの最大数は定義しないことになりました。代わりに、これらの値を定義した割当てリソースと、共有および競合に関する割当てポリシーを使用できます。

宛先の「割当て」パラメータでは、その宛先に割当てを強制するためにどの割当てリソースを使用するかを定義します。この値は動的で、いつでも変更できます。ただし、割当てリソースを変更した時点でその割当ての未処理リクエストがあると、そうしたリクエストはjavax.jms.ResourceAllocationExceptionで失敗します。


注意:

割当ての未処理リクエストは、割当てリソースが変更されたときに失敗します。これは、宛先の割当てを他の割当てに切り替えたときに失敗することを意味し、割当てリソースのメッセージ属性やバイト属性を変更したときには失敗しません。

JMSサーバー・レベルの割当て

宛先で割当てを構成しない場合もあります。JMSサーバーの割当てを使用すると、これらの「割当てを構成していない」宛先で使用するリソースを制限できます。「割当て」属性が明示的に設定されていないすべての宛先は、それらがデプロイされているJMSサーバーの割当てを共有します。この場合の動作は、「共有」パラメータが有効になっている各JMSサーバーに特別な割当てリソースが定義されている場合とまったく同じです。

JMSサーバーの割当てのインタフェースは、以前のリリースから変更されていません。JMSサーバーの割当ては、JMSServerMBeanのメソッドを使用して完全に制御できます。JMSサーバーの割当ての割当てポリシーは、JMSサーバーで「ブロッキング時の送信ポリシー」パラメータを使用して設定します。詳細については、「JMSサーバーでの「ブロッキング時の送信ポリシー」の指定」を参照してください。JMSサーバーの割当ての割当てポリシーも、他の割当てのポリシー設定と同じように機能します。それは、他の割当てのポリシー設定と同じように機能します。

割当て条件内での送信者のブロック

接続ファクトリでの送信タイムアウトの定義

割当て条件内で(送信タイムアウトを定義して)プロデューサをブロックすると、アプリケーションのパフォーマンス、および割当て失敗時のメッセージ送信の継続した再試行におけるベンチマークが大幅に向上します。「送信タイムアウト」機能を使用すると、宛先でスペースを利用できるようになるまで指定の時間にわたってメッセージの生成を待機できるため、メッセージ送信処理をより細かく制御できます。たとえば、プロデューサがリクエストを行い、十分なスペースが存在しない場合、プロデューサはスペースが利用可能になるまでブロックされるか、または処理がタイムアウトになります。別のフロー制御方法については、「JMSサーバーおよび宛先のメッセージのフロー制御」を参照してください。

管理コンソールを使用して、宛先がメッセージの最大割当てを超過したときにJMS接続ファクトリがメッセージのリクエストをブロックする時間を定義するには:

  1. Oracle WebLogic Server管理コンソール・ヘルプのメッセージ・フロー制御の構成に記載されている指示に従って、「JMS接続ファクトリ」: 「構成」: 「フロー制御」ページに移動します。

  2. 「送信タイムアウト」フィールドに、メッセージ宛先に十分なスペースが存在しない場合に送信側がメッセージをブロックする時間をミリ秒単位で入力します。ここで指定した期間が経過すると、次のいずれかの結果が発生します。

    • タイムアウト期間の終了前に十分なスペースが利用できるようになった場合、操作は続行されます。

    • タイムアウト期間の終了前に十分なスペースが利用できない場合、「リソース割当て」例外が発生します。

      値を0に設定してブロッキング時の送信ポリシーを有効にしない場合、宛先で十分なスペースが利用できないときに「リソース割当て」例外が発生します。

      送信タイムアウト・フィールドの詳細は、Oracle WebLogic Server管理コンソール・ヘルプのJMS接続ファクトリ : 構成 : フロー制御に関する項を参照してください。

  3. 「保存」をクリックします。

JMSサーバーでのブロッキング時の送信ポリシーの指定

ブロッキング時の送信ポリシーを使用すると、メッセージ割当てを超過した宛先で複数のプロデューサによるスペースの競合が存在するときに、小さいメッセージを大きいメッセージより先に送信するかどうかに関するJMSサーバーのブロック動作を定義できます。

管理コンソールを使用して、宛先がメッセージ割当てを超過したときにJMSサーバーがメッセージ・リクエストをブロックする方法を定義するには:

  1. Oracle WebLogic Server管理コンソール・ヘルプのJMS serverにおけるしきいと割当ての構成に関する項に記載されている指示に従って、管理コンソールの「JMSサーバー」: 「構成」: 「しきい値と割当」ページに移動します。

  2. 「ブロッキング時の送信ポリシー」リスト・ボックスから、次のいずれかのオプションを選択します。

    • 「FIFO」 - 同じ宛先に対するすべての送信リクエストは、スペースが使用できるようになるまで1つずつキューに入れられます。送信リクエストの実行は、スペースを待機する別の送信リクエストがその前に存在する限り許可されません。

    • 「プリエンプティブ」 - スペースが使用可能な場合、送信操作が別のブロックしている送信操作よりも先に処理できることを示します。つまり、現在のリクエストに対する十分なスペースが存在する場合、スペースを待機している他のリクエストがその前に存在する場合でもそのスペースが使用されます。

    • ブロッキング時の送信ポリシー・フィールドの詳細は、Oracle WebLogic Server管理コンソール・ヘルプのJMSサーバー : 構成 : しきい値と割当てに関する項を参照してください。

  3. 「保存」をクリックします。

MessageMaximumのチューニング

WebLogic JMSでは、非同期コンシューマ(または、メッセージ・リスナーとして知られている)またはプリフェッチを有効にした同期コンシューマに送信されたメッセージがパイプラインされます。これにより、パフォーマンスが向上します。これは、メッセージがサーバーからクライアントへに内部的にプッシュされと集合するためです。接続ファクトリのMessagesMaximumの設定を構成すると、JMSサーバーとクライアント間のメッセージ・バックログ(パイプラインのサイズ)をチューニングできます。『Oracle WebLogic Server JMSのプログラミング』の非同期メッセージ・パイプラインに関する項を参照してください。

一部の環境では、MessagesMaximumパラメータをチューニングすることでパフォーマンスが大幅に向上することがあります。たとえば、JMSアプリケーションで確認応答やコミットが保留されている場合などです。この場合、MessagesMaximumに次の値を設定することをお薦めします。

2 * (ack or commit interval) + 1

たとえば、JMSアプリケーションで一度に50メッセージを確認応答する場合、MessagesMaximumの値を101に設定します。

MessageMaximum制限のチューニング

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リモート・コンテキストで「デフォルト圧縮しきい値」を指定することによって管理的に設定できます。メッセージの種類によっては、圧縮によって実際にはサイズが大きくなることがあるため、圧縮されたメッセージが宛先の割当てに影響するおそれがあります。

管理コンソールを使用してデフォルト圧縮しきい値を構成する手順については、次を参照してください。

構成されたメッセージ圧縮は、クライアント送信の場合はプロデューサ、メッセージ受信またはメッセージ・ブラウズの場合は接続ファクトリに対して、またはSAF転送を通じて実行されます。メッセージはGZIPで圧縮されます。圧縮は、メッセージのプロデューサとコンシューマが別々のサーバー・インスタンスに配置されていてメッセージがJVM境界をまたぐ場合(通常は、WebLogicドメインが別のマシンにあってネットワーク接続をまたぐ場合)にのみ発生します。解凍は、メッセージのコンテンツがアクセスされたときに、クライアント・サイドで自動的に発生します。ただし、以下の状況でも解凍が発生します。

サーバー側では、ディスクに書き込まれるときでも、メッセージは常に圧縮されたままです。

メッセージのページングによるメモリーの解放

メッセージ・ページング機能を使用すると、メッセージ負荷のピークときにJMSサーバーによって自動的に仮想メモリーの開放が試行されます。この機能は、大容量のメッセージ領域を使用するアプリケーションでは大きなメリットがあります。JMSサーバーでは常にメッセージ・ページングが有効になっており、メッセージ・ページング・ディレクトリは自動的に作成されるため構成する必要はありません。ただし、「ページング・ディレクトリ」オプションを使用してディレクトリを指定することもでき、その場合はページングされたメッセージがこのディレクトリ内のファイルに書き込まれます。

JMSサーバーでは、ページング・ディレクトリに加え、ファイル・ストアまたはJDBCストアを使用して、永続メッセージが格納されます。ファイル・ストアは、ユーザー定義またはサーバーのデフォルトのストアのことです。ページングされたJDBCストアの永続メッセージは、JDBCストアとJMSサーバーのページング・ディレクトリの両方にコピーされます。ページングされたファイル・ストアの永続メッセージの小さいメッセージは、ファイル・ストアとJMSサーバーのページング・ディレクトリの両方にコピーされます。ページングされた大きなファイル・ストアのメッセージは、ページング・ディレクトリにコピーされません。「永続ストアを使用するときのベスト・プラクティス」を参照してください。

ただし、ページアウトされるメッセージは消費するメモリーのすべてを解放することはありません。メッセージ・ヘッダーは、メッセージ本文と一緒にページアウトされるすべてのユーザー・プロパティを除いて、検索/ソート/フィルタリングで使用するためにメモリーに残るからです。ページングされるメッセージの選択にセレクタを使用するキュー・アプリケーションでは、ページアウトされたメッセージをページ・インして戻す必要があるため、パフォーマンスが大幅に低下する場合があります。これは、メッセージ・ヘッダー・フィールド(CorrelationIDなど)に基づきメッセージを選択するトピックまたはアプリケーションに適用されません。原則として、各メッセージは、ページ・アウトしたときにJVMメモリーの512バイトを使用することを仮定します。

メッセージ・ページング・ディレクトリの指定

ページング・ディレクトリが指定されていない場合、ページングされたメッセージの本文はドメインのルート・ディレクトリのservernameサブディレクトリ内にある、デフォルトの\tmpディレクトリに書き込まれます。たとえば、デフォルトのページング・ディレクトリが指定されていない場合、次のディレクトリがデフォルトになります。

mw_home\user_projects\domains\domainname\servers\servername\tmp

domainnameはドメインのルート・ディレクトリ(通常はc:\Oracle\Middleware\user_projects\domains\domainname)です。これは、WebLogic Serverプログラム・ファイルが格納されるディレクトリ(通常はc:\Oracle\Middleware\wlserver_10.x)に対応するディレクトリです。

メッセージ・ページング・ディレクトリ属性を構成するには、Oracle WebLogic Server管理コンソール・ヘルプの一般的なJMSサーバーのプロパティの構成に関する項を参照してください。

「メッセージ・バッファ・サイズ」オプションのチューニング

「メッセージ・バッファ・サイズ」オプションでは、ディスクにページングされる前のメモリー内のメッセージ本文を格納するために使用するメモリーの量を指定します。「メッセージ・バッファ・サイズ」のデフォルト値は、JVMの最大ヒープ・サイズのおよそ3分の1、または最大値の512MBになります。このパラメータの設定値を大きくするほど、多くのメッセージがキューまたはトピックに待機している際にJMSでより多くのメモリーが消費されます。このしきい値を超えると、JMSはメモリー使用量をしきい値未満に抑えようとして、「ページング・ディレクトリ」オプションで指定したディレクトリに、メッセージ本文を書き込むことがあります。

このパラメータは割当てではない点に留意してください。サーバー上のメッセージ数がしきい値を超えると、サーバーはメッセージをディスクに書き込み、できるだけ速やかにメモリーから削除してメモリー使用量を減らします。ただし、新しいメッセージの受信を休止することはありません。それでも、メッセージ受信速度がページング速度を上回る場合は、メモリー不足になる可能性があります。メッセージ負荷の大きいユーザーができるかぎり高い可用性をサポートするには、割当てを設定するか、しきい値を設定してフロー制御を有効にすることで、サーバー上でのメモリー使用量を減らすことを検討してください。

JMSサーバーおよび宛先のメッセージのフロー制御

フロー制御機能を使うと、過負荷状態になっていると判断したJMSサーバーや宛先は、メッセージ・プロデューサの処理速度を遅くすることができます。「メッセージの圧縮」を参照してください。

次の項では、フロー制御の仕組みと、接続ファクトリでフロー制御を構成する方法について説明します。

フロー制御の仕組み

JMSサーバーやその宛先が指定のバイト数またはメッセージ数のしきい値を超えた場合、対処機能が作動し、メッセージ・フロー(1秒当たりのメッセージ数)を制限するようプロデューサに指示が出されます。

プロデューサは、JMS接続ファクトリを通じてプロデューサ用に構成された一連のフロー制御属性に基づき、生成率を制限します。プロデューサは、指定した最大フローのメッセージ数から開始して、所定の間隔ごとに(たとえば、10秒間、60秒ごとに)、サーバーや宛先がまだ対処機能を作動させたままであるかどうかを評価します。その時点において、サーバーや宛先で対処機能が作動したままであれば、プロデューサは所定のフロー最小値まで本番率を低下させます。

プロデューサの処理速度が低下するにつれ、しきい値条件は徐々に補正されます。これはサーバーや宛先の対処機能が解除されるまで行われます。この時点で、プロデューサは生成率を上げることができるようになりますが、必ずしも最大限まで上げる必要はありません。実際には、メッセージ・フローは、所定の最大フローに達してフロー制御の対象でなくなる時点までは(サーバーや宛先が対処機能を解除していても)引続き制御されます。

フロー制御の構成

プロデューサは、セッションから一連のフロー制御属性を受信します。セッションは接続から、接続は接続ファクトリから、この属性を受信します。これらの属性により、プロデューサはメッセージ・フローを調整できます。

具体的には、プロデューサはフローを最小値から最大値までの範囲内に制限する属性を受信します。プロデューサは、条件が悪くなると最小値側に移動し、改善されると最大値側に移動します。最小値側および最大値側への移行は、移行率を指定する2つの追加属性によって定義されます。また、最小値側および最大値側への移行の必要性は構成された間隔ごとに評価されます。

次の表では、フロー制御オプションについて説明します。

表14-2 フロー制御パラメータ

属性 説明

フロー制御を有効化

プロデューサがJMSサーバーによってフロー制御可能かどうかを決定します。

最大フロー

しきい値の条件に達したプロデューサに対する秒当たりの最大メッセージ数。

しきい値の条件に達したときにプロデューサでフローを制限していない場合、そのプロデューサの初期フロー制限が「最大フロー」に設定されます。しきい値の条件に達したときにプロデューサがすでにフローを制限している場合(フロー制限は「最大フロー」未満)、プロデューサは次にフローが評価されるまで現在のフロー制限で処理を継続します。

いったん、しきい値条件への抵触を回避してからは、プロデューサはフロー限度を無視できなくなります。このフロー制限が「最大フロー」未満の場合、プロデューサはフローが評価されるたびにそのフローを徐々に「最大フロー」まで増やす必要があります。プロデューサが「最大フロー」に達すると、そのフロー制限を無視し、そのフローを制限せずに送信できます。

最小フロー

しきい値の条件に達したプロデューサに対する秒当たりの最小メッセージ数。これはプロデューサのフロー制限の下限値。つまり、フロー制限が「最小フロー」に達したプロデューサの処理速度はWebLogic JMSによってそれ以上落とされません。

フロー間隔

プロデューサが「最大フロー」のメッセージ数から「最小フロー」に、またはその反対にフローを調整するときの調整期間(秒単位)。

フロー・ステップ

プロデューサがフローを「最大フロー」のメッセージ数から「最小フロー」に、またはその反対にフローを調整する場合に使用されるステップ数。具体的には、「フロー間隔」の調整期間が「フロー・ステップ」数に分割されます(たとえば、60秒を6ステップで除算するとステップあたり10秒になります)。

また、「最大フロー」と「最小フロー」の差をステップに分割することにより、移動(調整率)が計算されます。各フロー・ステップでは、次のように、現在の条件に基づき必要に応じてフローが上方または下方に調整されます。

下方への移動は、「フロー間隔」で指定した時間の経過に伴い、「フロー・ステップ」で指定した値に従って幾何的に減衰する(たとえば、100、50、25、12.5)。

上方移動は線形です。差は単にフロー・ステップ数で除算されます。

フロー制御フィールドおよびこのフィールドの有効な値とデフォルト値については、Oracle WebLogic Server管理コンソール・ヘルプのJMS接続ファクトリ : 構成 : フロー制御に関する項を参照してください。

フロー制御のしきい値

バイト数またはメッセージ数のしきい値の構成に使用する属性は、JMSサーバーまたはその宛先の一部として定義されます。表14-2に、上限しきい値と下限しきい値がJMSサーバーまたはJMS宛先のフロー制御を開始および停止する仕組みを示します。

表14-3 フロー制御しきい値パラメータ

属性 説明

「最大バイトしきい値」または「最大メッセージしきい値」

バイト数またはメッセージ数がこのしきい値を超えると、JMSサーバーまたはJMS宛先は防御状態になり、プロデューサに対してメッセージ・フローを制限するよう指示が行われます。

「最小バイトしきい値」または「最小メッセージしきい値」

バイト数またはメッセージ数がこのしきい値を下回った場合、JMSサーバーまたはJMS宛先は防御状態になり、プロデューサに対してメッセージ・フローを増やし始めるよう指示が行われます。

フロー制御は、メッセージの最大フローを下回っているプロデューサについては、引続き有効です。プロデューサは、最大フローに到達してフロー制御が行われなくなるまで、生成率を上げ続けることができます。

JMSサーバーおよび宛先のその他のしきい値フィールドと割当てフィールドの詳細、およびそれらの有効値とデフォルト値については、管理コンソール・オンライン・ヘルプの次のページを参照してください。

期限切れメッセージの処理

次の項では、メッセージの有効期限ポリシーとアクティブな有効期限処理という2つのメッセージ有効期限機能について説明します。これらの機能を使用すると、期限切れメッセージを検索する方法とそれらを検出したときの処理方法をより細かく制御できます。

アクティブなメッセージ有効期限を使用すると、期限切れメッセージが即座に消去されます。さらに期限切れメッセージの監査を使用すると、メッセージがいつ期限切れになったかをログに書き込むか、または期限切れメッセージを定義済みのエラー宛先にリダイレクトすることによって、期限切れメッセージを追跡できます。

メッセージ有効期限ポリシーの定義

有効期限ポリシーを使用して、メッセージが期限切れになったときに実行するアクションを定義します。「宛先」ノードの「有効期限ポリシー」属性では、宛先ごとに有効期限ポリシーを設定できます。「有効期限ポリシー」属性を使用すると、期限切れメッセージの検出時に宛先で実行されるアクション(メッセージの破棄、メッセージの破棄とログへの書き込み、またはエラー宛先へのリダイレクト)を定義できます。

また、JMSテンプレートを使用して複数の宛先を構成する場合、「有効期限ポリシー」フィールドを使用して、すべての宛先の有効期限ポリシーをすばやく構成できます。特定の宛先に関するテンプレートの有効期限ポリシーをオーバーライドするには、その宛先の有効期限ポリシーを変更します。

有効期限ポリシーの構成手順については、次のリンクをクリックしてください。

トピックの有効期限ポリシーを構成する

JMSテンプレートを使用せずにトピックの有効期限ポリシーを構成する場合は、次の手順に従います。特定のトピックに有効期限ポリシーを設定すると、JMSテンプレートに定義されている設定はオーバーライドされます。

  1. Oracle WebLogic Server管理コンソール・ヘルプのトピック・メッセージ配信の失敗オプションの構成に関する項に記載されている指示に従って、「JMSトピック」: 「構成」: 「配信の失敗」ページに移動します。

  2. 「有効期限ポリシー」リスト・ボックスから、有効期限ポリシー・オプションを選択します。

    • 「破棄」 - 期限切れのメッセージがメッセージング・システムから削除されます。削除はログに記録されず、メッセージは別の場所にリダイレクトされません。

    • 「ログ」 - 期限切れのメッセージを削除し、メッセージがシステムから削除されたことを示すエントリをサーバー・ログ・ファイルに書き込みます。次の手順で、ログに書き込まれる実際の情報を「有効期限ロギング・ポリシー」フィールドで定義します。

    • 「リダイレクト」 - 期限切れメッセージを現在の場所からトピックに対して定義されたエラー宛先に移動します。

      トピックの有効期限ポリシー・オプションの詳細は、Oracle WebLogic Server管理コンソール・ヘルプのJMSトピック : 構成 : 配信の失敗に関する項を参照してください。

  3. 前の手順で「ログ」ポリシーを選択した場合、「有効期限ロギング・ポリシー」フィールドを使用して、メッセージのどの情報をログに記録するかを定義します。

    「有効期限ロギング・ポリシー」の有効値の詳細は、「有効期限ロギング・ポリシーを定義する」を参照してください。

  4. 「保存」をクリックします。

キューの有効期限ポリシーを構成する

JMSテンプレートを使用せずにキューの有効期限ポリシーを構成する場合は、次の手順に従います。特定のキューに有効期限ポリシーを設定すると、JMSテンプレートに定義されている設定はオーバーライドされます。

  1. Oracle WebLogic Server管理コンソール・ヘルプのキューに関するメッセージ配信の失敗オプションの構成に関する項に記載されている指示に従って、「JMSキュー」: 「構成」: 「配信の失敗」ページに移動します。

  2. 「有効期限ポリシー」リスト・ボックスから、有効期限ポリシー・オプションを選択します。

    • 「破棄」 - 期限切れのメッセージがメッセージング・システムから削除されます。削除はログに記録されず、メッセージは別の場所にリダイレクトされません。

    • 「ログ」 - 期限切れメッセージをキューから削除し、メッセージがシステムから削除されたことを示すエントリをサーバー・ログ・ファイルに書き込みます。次の手順で、ログに書き込まれる実際の情報を「有効期限ロギング・ポリシー」フィールドで定義します。

    • 「リダイレクト」 - 期限切れメッセージをキューから、キューに対して定義されたエラー宛先に移動します。

    • キューの有効期限ポリシー・オプションの詳細は、Oracle WebLogic Server管理コンソール・ヘルプのJMSキュー : 構成 : 配信の失敗に関する項を参照してください。

  3. 前の手順で「ログ」ポリシーを選択した場合、「有効期限ロギング・ポリシー」フィールドを使用して、メッセージのどの情報をログに記録するかを定義します。

    「有効期限ロギング・ポリシー」の有効値の詳細は、「有効期限ロギング・ポリシーを定義する」を参照してください。

  4. 「保存」をクリックします。

テンプレートの有効期限ポリシーを構成する

JMSテンプレートを使用すると、似た属性設定を持つ複数の宛先(トピックまたはキュー)を効率的に定義できます。このため、宛先用の既存のテンプレート上でメッセージ有効期限ポリシーを構成できます。

  1. Oracle WebLogic Server管理コンソール・ヘルプのJMSテンプレートに関するメッセージ配信の失敗オプションの構成に関する項に記載されている指示に従って、「JMSテンプレート」: 「構成」: 「配信の失敗」ページに移動します。

  2. 「有効期限ポリシー」リスト・ボックスから、有効期限ポリシー・オプションを選択します。

    • 「破棄」 - 期限切れのメッセージがメッセージング・システムから削除されます。削除はログに記録されず、メッセージは別の場所にリダイレクトされません。

    • 「ログ」 - 期限切れのメッセージを削除し、メッセージがシステムから削除されたことを示すエントリをサーバー・ログ・ファイルに書き込みます。ログに書き込まれる実際の情報は、次の手順に示す「有効期限ロギング・ポリシー」で定義します。

    • 「リダイレクト」 - 期限切れメッセージを現在の場所から宛先に対して定義したエラー宛先に移動します。

    • テンプレートの有効期限ポリシーオプションの詳細は、Oracle WebLogic Server管理コンソール・ヘルプのJMSテンプレート : 構成 : 配信の失敗に関する項を参照してください。

  3. 手順4で有効期限を記録するポリシーを選択した場合、「有効期限ロギング・ポリシー」フィールドを使用して、メッセージのどの情報をログに記録するかを定義します。

    「有効期限ロギング・ポリシー」の有効値の詳細は、「有効期限ロギング・ポリシーを定義する」を参照してください。

  4. 「保存」をクリックします。

有効期限ロギング・ポリシーを定義する

この項では、有効期限ポリシーについて説明します。

「有効期限ロギング・ポリシー」パラメータはこのリリースの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サーバーを構成する

JMSサーバーが宛先をアクティブにスキャンして期限切れメッセージを処理する方法を定義するには、次の手順に従います。デフォルト値は30秒です。つまり、JMSサーバーは各スキャンの間で30秒待機します。

  1. Oracle WebLogic Server管理コンソール・ヘルプのJMSサーバーの一般的なプロパティの構成に関する項に記載されている指示に従って、管理コンソールの「JMSサーバー」: 「構成」: 「一般」ページに移動します。

  2. 「有効期限スキャン間隔」フィールドに、JMSサーバーが宛先をスキャンして期限切れメッセージを処理するサイクルの休止間隔を秒数で入力します。

    アクティブなスキャンを無効にするには、0を入力します。期限切れメッセージは、検出時にシステムからパッシブに削除されます。

    有効期限スキャン間隔属性の詳細は、Oracle WebLogic Server管理コンソール・ヘルプのJMSサーバー : 構成 : 一般に関する項を参照してください。

  3. 「保存」をクリックします。

設計上の選択には、JMSアプリケーションのパフォーマンスに影響を与えるものが多数あります。信頼性、スケーラビリティ、管理容易性、モニター、ユーザー・トランザクション、メッセージドリブンBeanのサポート、アプリケーション・サーバーとの統合などの要素がパフォーマンスに影響します。また、WebLogic JMSの拡張と機能もパフォーマンスに直接的な影響を与えます。

JMSのアプリケーションの設計の詳細は、『Oracle WebLogic Server JMSのプログラミング』のアプリケーション設計のベスト・プラクティスに関する項を参照してください。

順序単位を使用したアプリケーションのチューニング

メッセージ順序単位はWebLogic Serverの付加価値機能です。スタンドアロンのメッセージ・プロデューサや、単体として動作するプロデューサのグループは、この機能を使用して複数のメッセージを処理順序(下位順序)に応じた1つの単位にグループ化できます。この単位を順序単位(UOO)と呼び、この単位にまとめられたすべてのメッセージは作成順に従って処理されます。以下の複雑な設計パターンについてUOOを使用するように置き換えます。

『Oracle WebLogic Server JMSのプログラミング』のメッセージ順序単位の使用に関する項を参照してください。

ベスト・プラクティス

次の項では、UOO使用時のベスト・プラクティスについて説明します。

  • 厳格なメッセージ順序要件があるアプリケーションにおいて理想的です。UOOにより管理やアプリケーション設計が簡略化され、ほとんどのアプリケーションでパフォーマンスが向上します。

  • MDBバッチ処理を使用すると以下のことが可能になります。

  • 宛先にはデフォルトのUOOを構成できます。宛先では一度に1つだけのコンシューマがデフォルトのUOOのメッセージを処理します。

UOOと分散宛先の使用

分散宛先を使用している場合、厳格なメッセージ順序を確実に適用するために、各UOOは特定の物理宛先のインスタンスに固定されます。所定のUOOに対して自動的に適切な物理宛先を決定するため、以下の2つのオプションが用意されています。

  • ハッシュ処理 - 通常、より高速なUOOの設定です。ハッシュ処理では物理宛先を決定するために、UOO名に対してハッシュ関数を使用します。この方法は次の点でデメリットがあります。

    • 分散宛先に対する物理宛先の管理的な削除または追加を正しく処理できません。

    • UOOが利用不可能な宛先にハッシュ化された場合、メッセージの送信が失敗します。

  • パス・サービス - UOOごとに物理宛先をマップする、単一サーバーのUOOディレクトリ・サービスです。パス・サービスは通常、1秒間に異なる名前のUOOが数多く作成された場合、ハッシュ処理よりも低速です。この場合、メッセージの送信前に、新しいUOO名のそれぞれによってパス・サービスのチェックが暗黙的に強制されます。1秒間に作成されるUOOの数が制限されている場合、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管理コンソール・ヘルプの接続ファクトリ・フロー制御の構成に関する項に記載されているように、管理コンソールを使用して接続ファクトリに一方向のメッセージ送信パラメータを構成してください。FlowControlParamsBean MBeanを通じて、WebLogic Scripting Tool (WLST)またはJMXを使用することもできます。


注意:

接続ファクトリが「XA対応」として構成されている場合、一方向メッセージ送信は無効になります。この設定では、送信側が実際にトランザクションを使用しているかどうかに関係なく、一方向送信が無効になります。

宛先が1つの場合のクラスタにおける一方向送信のサポート

宛先が1つの場合のクラスタで一方向送信をサポートするには、宛先をホストしているJMSサーバーと接続ファクトリが、同じWebLogicサーバーにターゲット指定されていることを確認します。接続ファクトリが、クラスタ内のその他のWebLogic Serverインスタンスにターゲット指定されている場合はサポートされません。

宛先が複数の場合のクラスタにおける一方向送信のサポート

同じ名前を共有する宛先が複数ある場合のクラスタで一方向送信をサポートするには、クライアント接続をホストしているWebLogic Serverインスタンスでもその宛先を確実にホストする必要があります。1つのソリューションを次に示します。

  1. クラスタ全体のRMIロード・バランシング・アルゴリズムを「サーバー・アフィニティ」に構成します。

  2. 2つの宛先が同じWebLogic Serverインスタンスでホストされていないことを確認します。

  3. 各宛先が同じlocal-jndi-nameを持つように構成します。

  4. 宛先をホストしているWebLogic Serverインスタンスにのみターゲット指定されている接続ファクトリを構成します。

  5. JNDIコンテキストから接続ファクトリおよび宛先を取得するために、送信側クライアントにおいて、ステップ3および4で構成したJNDI名が使用されるようにします。

  6. ステップ3の宛先をホストしているWebLogic Serverインスタンスにのみ制限されているURLを送信側クライアントが使用するようにします。

このソリューションでは、EJBホームおよびJMS接続ファクトリを含む、クラスタリングされたRMIオブジェクト用のRMIレベルのロード・バランシングは無効にされます。クライアントはJNDIコンテキストの確立に使用されるネットワーク・アドレスにのみ基づいて接続および宛先を効率的に取得します。ロード・バランシングは、WebLogic Serverアドレスのカンマ区切りのリストが含まれる複数のURL、または、ネットワーク管理者によって構成されるIPアドレスの「ラウンドロビン」セットに解決されるDNS名を指定する複数のURLに対して行われる、「ネットワーク・ロード・バランシング」を利用することによって達成されます。

クラスタ用サーバー・アフィニティの詳細は、『Oracle WebLogic Serverクラスタの使用』のEJBとRMIオブジェクトのロード・バランシングに関する項を参照してください。

一方向送信がサポートされないケース

この項では、一方向送信がサポートされないケースを示します。一方向送信がサポートされない場合、送信のQOSは、標準の双方向に自動的にアップグレードされます。

異なるクライアントと宛先ホスト

一方向送信は、ターゲット宛先をホストしているJMSサーバーとクライアント・プロデューサの接続ホストが、同じWebLogic Serverインスタンスである場合にサポートされます。これらが同じでない場合、一方向モード設定は無視され、標準の双方向送信が代わりに使用されます。

クライアントのホスト接続ファクトリでのXA対応

クライアントのホスト接続ファクトリが「XA対応」として構成されている場合、一方向メッセージ送信は無効になります。この設定では、送信側が実際にトランザクションを使用しているかどうかに関係なく、一方向送信が無効になります。

高度なQOSの検出

次に示す、より高度なQOS機能が検出された場合には、一方向モードの設定は無視され、代わりに標準の双方向送信が使用されます。

  • XA

  • トランザクション・セッション

  • 永続メッセージ

  • 順序単位

  • 作業単位

  • 分散宛先

宛先割当ての超過

ターゲット宛先で指定された割当てを超過している場合、その割当てがクリアになるまで標準の双方向送信が使用されます。

割当てを超過する一方向メッセージは、例外がクライアントに即座に返されることなく、通知のないまま削除されます。クライアントは、次の双方向送信が行われる際、宛先が割当てをまだ超過している場合に、割当ての例外を取得することになります。(一方向モードでも、クライアントは、クライアントの接続ファクトリで構成された「一方向送信ウィンドウ・サイズ」のメッセージ数ごとに双方向メッセージを送信します。)

割当て条件内で通知なしにメッセージが削除されるのを回避できる1つの方法は、接続ファクトリで構成される「Blocking Send Timeout」の値を増やすことです(「メッセージの圧縮」を参照)。一方向メッセージは、即座に削除されることはありませんが、メッセージが消費されるか、期限切れになることによって割当て条件がクリアになるまでの一定時間、JMSサーバーで待機することになります。クライアントの送信側は、双方向メッセージを送信するまでブロックすることはありません。各クライアントに対して、一方向ウィンドウ・サイズの数を超えるメッセージが割当て条件がクリアになるのを待機してサーバー上で蓄積されることはありません。

サーバー・セキュリティ・ポリシーにおける変更

サーバー側のセキュリティ・ポリシーで変更があると、JMSクライアントがその変更をセキュリティ・ステータスで通知されることなく、一方向メッセージ送信ができなくなる場合があります。

JMSサーバーまたは宛先ステータスにおける変更

JMSサーバーまたはターゲット宛先が管理者によってアンデプロイされているとき、または、生成休止/再開の機能を使用してJMSサーバーあるいはターゲット宛先上のメッセージの生成が休止されている場合、一方向の送信を無効化することができます。『Oracle WebLogic Server JMSの構成と管理』の生成休止と生成再開に関する項を参照してください。

論理分散宛先名のルックアップ

一方向のメッセージ送信は、クライアントが論理的な分散宛先名を使用しないで、直接物理分散宛先メンバーを参照する場合、分散宛先で動作します。『Oracle WebLogic Server JMSのプログラミング』の分散宛先の使用に関する項を参照してください。

ハードウェア障害

ハードウェアまたはネットワークに障害があると、一方向送信は無効になります。こうした場合、JMSプロデューサは、OnExceptionまたは次の双方向メッセージ送信によって通知されます(一方向モードでも、クライアントは、クライアントの接続ファクトリで構成された「一方向送信ウィンドウ・サイズ」のメッセージ数ごとに双方向メッセージを送信します。)さらに、プロデューサが閉じられます。最悪の場合、障害が発生した直前の最後の双方向メッセージまでのすべてのメッセージが失われる場合があります。

一方向送信のQOSのガイドライン

一般的な非永続メッセージングで一方向送信モードを使用する場合は、次のQOS関連のガイドラインを使用します。

  • 送信のブロック機能とともに使用し、正常に実行されているシステム上で一方向送信を使用すると、双方向送信モードを使用する場合と同様のQOSを達成できます。

  • トピック・パブリッシャの一方向送信モードは、JMS仕様で設定されているQOSガイドラインの範囲内に収まりますが、双方向モード(WebLogic Serverのデフォルト・モード)より低いQOSとなります。

  • 『Oracle WebLogic Server JMSのプログラミング』の非同期コンシューマに対する同期コンシューマに関する項に記載されているように、JMSコンシューマ・アプリケーションは、システムのボトルネックの場合、一方向送信モードが向上されない場合があります。

  • 送信のバッチ・サイズ(ウィンドウ)の増加に対応するには、クライアントとサーバーの双方またはいずれかでJVMのヒープ・サイズを増やすことを検討します。可能メモリー使用量は、構成されたウィンドウのサイズおよび送信者の数に比例します。

  • 送信側アプリケーションは、すべての割当て例外を受け取るわけではありません。割当てを超過する一方向メッセージは、例外が送信側クライアントに返されることなく、通知のないまま削除されます。詳細および考えられる回避策については、「宛先割当てを超過している」を参照してください。

  • 接続ファクトリで一方向送信を構成すると、接続ファクトリで構成されているメッセージ・フロー制御パラメータが効率よく無効にされます。

  • デフォルトでは一方向ウィンドウ・サイズは1に設定されている。これによって、各一方向メッセージが双方向送信にアップグレードされるため、一方向送信が効率よく無効にされます。(一方向モードでも、クライアントは、クライアントの接続ファクトリで構成された「一方向送信ウィンドウ・サイズ」のメッセージ数ごとに双方向メッセージを送信します。)したがって、一方向送信のウィンドウ・サイズはもっと大きな値に設定する必要があります。ウィンドウ・サイズは最初に300に設定し、後からアプリケーションの要件に応じて調整するようにすることが推奨されます。

  • クライアント・アプリケーションは、ネットワークまたはサーバーの障害に関する例外を即座に受け取るわけではなく、WebLogic Serverで障害が検出され、プロデューサが自動的に閉じられるまで、一部のメッセージは送信はされるものの、通知なしで削除される場合があります。詳細は、「ハードウェアに障害がある」を参照してください。

「メッセージング・パフォーマンスのプリファレンス」オプションのチューニング


注意:

これは、ファイン・チューニングの詳細オプションです。通常は、ます初めに他のチューニング・オプションを検討するのが最良です。

JMS宛先の「メッセージング・パフォーマンス・プリファレンスのオプション」というチューニング・オプションを使用すると、コンシューマに配信可能なメッセージの完全なバッチが作成されるまで宛先が待機する時間(必要がある場合)を制御できるようになります。最小値の場合、バッチ処理は無効になります。デフォルト値よりも大きな値にチューニングすると、使用できるメッセージをバッチ処理するまで宛先が待機する時間が延長されます。完全なバッチの最大メッセージ数は、JMS接続ファクトリの「セッションあたりの最大メッセージ数」設定で制御されます。

この高度なオプションは管理コンソールから利用できます。スタンドアロンおよび共通分散宛先(DestinationBean APIでも可能)、またはJMSテンプレート(TemplateBean APIでも可能)の全般構成のページを使用して設定します。

具体的に言うと、JMS宛先には、メッセージをバッチにまとめてコンシューマへ配信することにより、自動的にパフォーマンスを最適化しようとする内部アルゴリズムがあります。メッセージ・レートや他の要因の変化に応じて、こうしたアルゴリズムでバッチのサイズや配信時間が変更されます。ただし、このようなアルゴリズムですべてのメッセージング環境のパフォーマンスを最適化することはできません。「メッセージング・パフォーマンス・プリファレンスのオプション」を指定することで、メッセージ・レートや他の要因の変更に応じたアルゴリズムの対応方法を変更して、システムのパフォーマンスを調整できます。

メッセージング・パフォーマンスの構成パラメータ

「メッセージング・パフォーマンス・プリファレンスのオプション」には、次の構成パラメータがあります。

表14-4 メッセージング・パフォーマンス・プリファレンスの値

管理コンソールの値 MBeanの値 説明

メッセージをバッチ処理しない

0

メッセージのバッチ処理を事実上無効にします。利用可能なメッセージは即座にコンシューマへ配信されます。

これは、接続ファクトリの「セッションあたりの最大メッセージ数」フィールドを「1」に設定した場合に相当します。

待機せずメッセージをバッチ処理

25 (デフォルト)

完全に満たないバッチが、利用可能なメッセージを含んだ状態で即座に配信されます。

これは、接続ファクトリの「セッションあたりの最大メッセージ数」フィールドに設定した値に相当します。

メッセージ・バッチ処理の最小待機しきい値

50

短期間だけ待機した後で、完全に満たないバッチが利用可能なメッセージを含んだ状態で配信されます。

メッセージ・バッチ処理の中間待機しきい値

75

場合に応じてより長く待機した後で、完全に満たないバッチが利用可能なメッセージを含んだ状態で配信されます。

メッセージ・バッチ処理の最大待機しきい値

100

場合に応じてさらに長く待機した後で、完全に満たないバッチが利用可能なメッセージを含んだ状態で配信されます。

お使いのシステムに最適な値を見つけるためには、ある程度の実験が必要な場合もあります。たとえば、並列する多数のメッセージ・コンシューマが設定されたキューの場合、管理コンソールで「メッセージをバッチ処理しない」という値を選択(またはDestinationBean MBeanに「0」を指定)すると、そのキューではコンシューマが利用可能になるとすぐに、できるだけ早くそのコンシューマにメッセージをスローしようとします。反対に、迅速なレスポンスが求められないメッセージ・コンシューマが1つだけ設定されているキューの場合、管理コンソールで「メッセージ・バッチ処理の最大待機しきい値」という値を選択(またはDestinationBean MBeanに「100」を指定)すると、そのキューではメッセージをバッチの形でのみコンシューマにスローしようとし、結果として待機時間は増加しますが、スロー回数が少なくなるのでサーバー全体のスループットが向上する場合があります。

スタンドアロンの宛先、共通分散宛先、またはJMSテンプレートに対して、管理コンソールで「メッセージング・パフォーマンス・プリファレンスのオプション」パラメータを構成する手順については、管理コンソール・オンライン・ヘルプの次の項を参照してください。

これらのパラメータの詳細は、Oracle WebLogic Server MBeanリファレンスのDestinationBeanおよびTemplateBeanを参照してください。

非同期メッセージ・パイプラインとの互換性

「メッセージング・パフォーマンス・プリファレンスのオプション」は、非同期メッセージ・パイプラインを使用する非同期コンシューマに対応しています。また、同期コンシューマのプリフェッチ・モード機能(非同期メッセージ・パイプラインをシミュレートする機能)を使用する同期コンシューマにも対応します。ただし、「最大メッセージ数」に設定されている値が小さすぎると、宛先のより高いレベルのパフォーマンス・アルゴリズム(たとえば、「メッセージ・バッチ処理の最小待機しきい値」、「メッセージ・バッチ処理の中間待機しきい値」、「メッセージ・バッチ処理の最大待機しきい値」)の影響が無効になる場合があります。非同期メッセージ・パイプラインの詳細は、『Oracle WebLogic Server JMSのプログラミング』の受信メッセージに関する項を参照してください。

クライアント側スレッド・プール

多くのjavaクライアント側のアプリケーションでは、クライアント・スレッド・プールのデフォルト・サイズとして、5個のスレッドで十分です。アプリケーションに大量の非同期コンシューマがある場合、非同期コンシューマに設定されている数よりも少し多いスレッド数を割り当てると役に立ちます。これにより、さらに多くの非同期コンシューマを同時に実行できます。

WebLogicクライアント・プールの構成方法は、WebLogic serverスレッド・プールの構成方法とは異なり、自動チューニングされていません。WebLogicクライアントでは、サーバーから受信されるリクエストのためにJMS MessageListenerの起動など、特定のスレッド・プールが使用されています。このプールは、次のコマンド・ライン・プロパティを使用して構成できます。

-Dweblogic.ThreadPoolSize=n

ここでは、nは、スレッド数を示します。

クライアント側のスレッド・ダンプを使用して、この設定が有効になっていることを確認できます。

JMS .NETクライアント・アプリケーションのベスト・プラクティス

次に、JMS .NETクライアント・アプリケーションの作成時に使用するパフォーマンス関連のベスト・プラクティスを簡単に示します。

JMS .NETクライアント・アプリケーションのベスト・プラクティスおよびその他のプログラミングに関する考慮事項については、『Microsoft .NET対応のWebLogic JMSクライアントの使用』のプログラミングの考慮事項に関する項を参照してください。

  前
前 		 次
次
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストヘ移動
製品		 目次へ移動
目次