|
|
以下の節では、WebLogic JMS の管理パフォーマンス チューニング機能を実装することによってアプリケーションを最大限に活用する方法について説明します。
以前のリリースでは、複数のレベルの割り当てがありました。送り先には独自の割り当てがあり、同時に JMS サーバ内の割り当てをめぐって競合する必要もありました。このリリースでは、割り当てのレベルは 1 つだけです。送り先では、独自のプライベートの割り当てを使用することも、共有割り当てを使用して他の送り先と競合することもできます。
独自の割り当てを定義する送り先は、JMS サーバの割り当てのスペースを共有しません。JMS サーバでは、引き続きメッセージとバイトの割り当てを直接コンフィグレーションできますが、これらのオプションは割り当てリソースを参照しない送り先の割り当てを定義するためにのみ使用できます。
割り当てとは、コンフィグレーション可能な名前付きの JMS モジュール リソースです。割り当てでは、メッセージおよびバイトの最大数を定義します。これを 1 つまたは複数の送り先に関連付けることで、定義した最大数を強制することができます。同じ割り当てを参照する複数の送り先は、割り当てリソースの共有ポリシーに従ってその割り当てを共有します。
割り当てリソースでは、以下のパラメータをコンフィグレーションできます。
割り当てのコンフィグレーション パラメータの詳細については、『WebLogic Server MBean Reference』の「QuotaBean」を参照してください。Administration Console を使用して割り当てリソースをコンフィグレーションする手順については、Administration Console オンライン ヘルプの「システム モジュール内の送り先の割り当ての作成」を参照してください。
送り先では、割り当てのバイトおよびメッセージの最大数は定義しないことになりました。代わりに、これらの値を定義した割り当てリソースと、共有および競合に関する割り当てポリシーを使用できます。
送り先の [割り当て] パラメータでは、その送り先に割り当てを強制するためにどの割り当てリソースを使用するかを定義します。この値は動的で、いつでも変更できます。ただし、割り当てリソースを変更した時点でその割り当ての未処理リクエストがあると、そうしたリクエストは javax.jms.ResourceAllocationException で失敗します。
| 注意: | 割り当ての未処理リクエストは、割り当てリソースが変更されたときに失敗します。これは、送り先の割り当てを他の割り当てに切り替えたときに失敗することを意味し、割り当てリソースのメッセージ属性やバイト属性を変更したときには失敗しません。 |
送り先で割り当てをコンフィグレーションしない場合もあります。JMS サーバの割り当てを使用すると、これらの「割り当てをコンフィグレーションしていない」送り先で使用するリソースを制限できます。[割り当て] 属性が明示的に設定されていないすべての送り先は、それらがデプロイされている JMS サーバの割り当てを共有します。この場合の動作は、[共有] パラメータが有効になっている各 JMS サーバに特別な割り当てリソースが定義されている場合とまったく同じです。
JMS サーバの割り当てのインタフェースは、以前のリリースから変更されていません。JMS サーバの割り当ては、JMSServerMBean のメソッドを使用して完全に制御できます。JMS サーバの割り当ての割り当てポリシーは、JMS サーバで [ブロッキング時の送信ポリシー] パラメータを使用して設定します。詳細については、「JMS サーバでの [ブロッキング時の送信ポリシー] の指定」を参照してください。JMS サーバの割り当ての割り当てポリシーも、他の割り当てのポリシー設定と同じように機能します。
割り当て条件内で (送信タイムアウトを定義して) プロデューサをブロックすると、アプリケーションのパフォーマンス、および割り当て失敗時のメッセージ送信の継続した再試行におけるベンチマークが大幅に向上します。[送信タイムアウト] 機能を使用すると、送り先でスペースを利用できるようになるまで指定の時間にわたってメッセージの生成を待機できるため、メッセージ送信処理をより細かく制御できます。たとえば、プロデューサがリクエストを行い、十分なスペースが存在しない場合、プロデューサはスペースが利用可能になるまでブロックされるか、または処理がタイムアウトになります。別のフロー制御方法については、「JMS サーバおよび送り先のメッセージのフロー制御」を参照してください。
Administration Console を使用して、送り先がメッセージの最大割り当てを超過したときに JMS 接続ファクトリがメッセージのリクエストをブロックする時間を定義するには、次の手順に従います。
値を 0 に設定してブロッキング時の送信ポリシーを有効にしない場合、送り先で十分なスペースが利用できないときに「リソース割り当て」例外が発生します。
[送信タイムアウト] フィールドの詳細については、Administration Console オンライン ヘルプの「JMS 接続ファクトリ : コンフィグレーション : フロー制御」を参照してください。
ブロッキング時の送信ポリシーを使用すると、メッセージ割り当てを超過した送り先で複数のプロデューサによるスペースの競合が存在するときに、小さいメッセージを大きいメッセージより先に送信するかどうかに関する JMS サーバのブロック動作を定義できます。
Administration Console を使用して、送り先がメッセージ割り当てを超過したときに JMS サーバがメッセージ要求をブロックする方法を定義するには、次の手順に従います。
[ブロッキング時の送信ポリシー] フィールドの詳細については、Administration Console オンライン ヘルプの「JMS サーバ : コンフィグレーション : しきい値と割り当て」を参照してください。
以下の節では、サイズの大きなメッセージを処理する際に JMS のパフォーマンスを向上させる方法について説明します。
WebLogic JMS では、非同期コンシューマ (メッセージ リスナ)、またはプリフェッチが有効化された同期コンシューマに配信されるメッセージがパイプライン処理されます。これにより、サーバからクライアントに内部的にメッセージが送信されるときにメッセージが集約されるため、パフォーマンスが向上します。JMS サーバとクライアント間のメッセージのバックログ (パイプラインのサイズ) は、接続ファクトリで MessagesMaximum の設定をコンフィグレーションすることでチューニングできます。『WebLogic JMS プログラマーズ ガイド』の「非同期メッセージ パイプライン」を参照してください。
一部の環境では、MessagesMaximum パラメータをチューニングすることでパフォーマンスが大幅に向上することがあります。たとえば、JMS アプリケーションで確認応答やコミットが保留されている場合などです。この場合、MessagesMaximum に次の値を設定することをお勧めします。
2 * (確認応答またはコミットの間隔) + 1
JMS アプリケーションで一度に 50 メッセージを確認応答する場合、MessagesMaximum の値を 101 に設定します。
MessagesMaximum の値が大きすぎると、以下のような状況になることがあります。
MessagesMaximum に 10,000,000 を設定した場合、最初に接続するコンシューマ クライアントで、すでに送り先に届いているすべてのメッセージが取得されます。この場合、他のコンシューマは 1 つもメッセージのない状態のままで、最初のコンシューマで不要なメッセージのメッセージのバックログが作成され、システムのメモリが不足することがあります。-Dweblogic.MaxMessageSize コマンドライン プロパティを使用してクライアントごとにコンフィグレーションされているもの) より大きいと、メッセージの配信が失敗します。
大きなメッセージを送受信する場合、WebLogic Server インスタンスに加えて WebLogic クライアントをコンフィグレーションする必要があることもあります。クライアントに最大メッセージ サイズを設定するには、以下のコマンドライン プロパティを使用します。
-Dweblogic.MaxMessageSize
| 注意: | この設定は、JMS 関連パケットのみでなく、クライアントに配信されるすべての WebLogic Server ネットワーク パケットに対して適用されます。 |
ディスク スペースを節約しながら JVM 境界にまたがってやりとりされる大きなメッセージの送信パフォーマンスを向上させるため、ユーザ指定のしきい値サイズを超過したメッセージの自動圧縮を指定できます。メッセージの圧縮を使用すると、ネットワークを介して送信されるメッセージのサイズを自動的に小さくすることで、ネットワークのボトルネックを緩和できます。また、ファイル ストアやデータベースに永続メッセージを格納する際のディスク スペースも節約できます。
| 注意: | メッセージの種類によっては、圧縮によって実際にはサイズが大きくなることがあるため、圧縮されたメッセージが送り先の割り当てに影響するおそれがあります。 |
メッセージ圧縮のしきい値は、WLMessageProducer インタフェースの JMS API 拡張機能を使用することによってプログラム的に設定するか、接続ファクトリまたは JMS SAF リモート コンテキストで [デフォルト圧縮しきい値] を指定することによって管理的に設定できます。
Administration Console を使用してデフォルト圧縮しきい値をコンフィグレーションする手順については、以下を参照してください。
コンフィグレーションされたメッセージ圧縮は、クライアント送信の場合はプロデューサ、メッセージ受信またはメッセージ ブラウズの場合は接続ファクトリに対して、または SAF 転送を通じて実行されます。メッセージは GZIP で圧縮されます。圧縮は、メッセージのプロデューサとコンシューマが別々のサーバ インスタンスに配置されていてメッセージが JVM 境界をまたぐ場合 (通常は、WebLogic ドメインが別のマシンにあってネットワーク接続をまたぐ場合) にのみ発生します。解凍は、メッセージのコンテンツがアクセスされたときに、クライアント サイドで自動的に発生します。ただし、以下の状況でも解凍が発生します。
サーバ サイドでは、ディスクに書き込まれるときでも、メッセージは常に圧縮されたままです。
メッセージ ページング機能を使用すると、メッセージ負荷のピーク時に JMS サーバによって自動的に仮想メモリの開放が試行されます。この機能は、大容量のメッセージ領域を使用するアプリケーションでは大きなメリットがあります。JMS サーバでは常にメッセージ ページングが有効になっており、メッセージ ページング ディレクトリは自動的に作成されるためコンフィグレーションする必要はありません。ただし、[ページング ディレクトリ] オプションを使用してディレクトリを指定することもでき、その場合はページングされたメッセージがこのディレクトリ内のファイルに書き込まれます。
JMS メッセージ ページングでは永続メッセージのデータがメモリにキャッシュされるため、永続メッセージ用のメモリを節約できます。JMS サーバがファイル ストア (ユーザ定義のストアまたはサーバのデフォルト ストア) に関連付けられている場合、ページングされた永続メッセージは通常はそのファイル ストアに書き込まれます。一方、非永続メッセージは、常に JMS サーバのページング ディレクトリに書き込まれます。JMS サーバが JDBC ストアに関連付けられている場合は、ページングされた永続メッセージと非永続メッセージの両方が常に JMS サーバのページング ディレクトリに書き込まれます。「永続ストア使用時のベスト プラクティス」を参照してください。
しかし、メッセージのヘッダは検索、ソート、フィルタ処理のためメモリに残されるため、メッセージをページングすることでそのメッセージが消費していたメモリをすべて開放できるわけではありません。ただし、ユーザ プロパティは例外で、メッセージの本文と一緒にページングされます。ページングされるメッセージの選択にセレクタを使用するキュー アプリケーションでは、ページングされたメッセージをページ インし直す必要があるため、パフォーマンスが大幅に低下する場合があります。これはメッセージ ヘッダ フィールド (たとえば CorrelationID) のみに基づいて選択するアプリケーションまたはトピックには当てはまりません。
ページング ディレクトリが指定されていない場合、ページングされたメッセージの本文はドメインのルート ディレクトリの servername サブディレクトリ内にある、デフォルトの \tmp ディレクトリに書き込まれます。たとえば、デフォルトのページング ディレクトリが指定されていない場合、次のディレクトリがデフォルトになります。
bea_home\user_projects\domains\domainname\servers\servername\tmp
domainname はドメインのルート ディレクトリ (通常は c:\bea\user_projects\domains\domainname) です。これは、WebLogic Server プログラム ファイルが格納されるディレクトリ (通常は c:\bea\weblogic92) に対応するディレクトリです。
[メッセージ バッファ サイズ] オプションでは、ディスクにページングされる前のメモリ内のメッセージ本文を保存するために使用するメモリの量を指定します。[メッセージ バッファ サイズ] のデフォルト値は、JVM の最大ヒープサイズのおよそ 3 分の 1、または最大値の 512 MB になります。このパラメータの設定値を大きくするほど、多くのメッセージがキューまたはトピックに待機している際に JMS でより多くのメモリが消費されます。このしきい値を超えると、JMS はメモリ使用量をしきい値未満に抑えようとして、[ページング ディレクトリ] オプションで指定したディレクトリに、メッセージ本文を書き込むことがあります。
このパラメータは割り当てではない点に注意してください。サーバ上のメッセージ数がしきい値を超えると、サーバはメッセージをディスクに書き込み、できるだけ速やかにメモリから削除してメモリ使用量を減らします。ただし、新しいメッセージの受信を休止することはありません。それでも、メッセージ受信速度がページング速度を上回る場合は、メモリ不足になる可能性があります。メッセージ負荷の大きいユーザができるかぎり高い可用性をサポートするには、割り当てを設定するか、しきい値を設定してフロー制御を有効にすることで、サーバ上でのメモリ使用量を減らすことを検討してください。
フロー制御機能を使うと、過負荷状態になっていると判断した JMS サーバや送り先は、メッセージ プロデューサの処理速度を遅くすることができます。「メッセージの圧縮」を参照してください。
以下の節では、フロー制御の仕組みと、接続ファクトリでフロー制御をコンフィグレーションする方法について説明します。
JMS サーバやその送り先が指定のバイト数またはメッセージ数のしきい値を超えた場合、対処機能が作動し、メッセージ フロー (1 秒当たりのメッセージ数) を制限するようプロデューサに指示が出されます。
プロデューサは、JMS 接続ファクトリを通じてプロデューサ用にコンフィグレーションされた一連のフロー制御属性に基づき、プロダクション率を制限します。プロデューサは、指定した最大フローのメッセージ数から開始して、所定の間隔ごとに (たとえば、60 秒間、10 秒ごとに)、サーバや送り先がまだ対処機能を作動させたままであるかどうかを評価します。その時点において、サーバや送り先で対処機能が作動したままであれば、プロデューサは所定のフロー最小値までプロダクション率を低下させます。
プロデューサの処理速度が低下するにつれ、しきい値条件は徐々に補正されます。これはサーバや送り先の対処機能が解除されるまで行われます。この時点で、プロデューサはプロダクション率を上げることができるようになりますが、必ずしも最大限まで上げる必要はありません。実際には、メッセージ フローは、所定の最大フローに達してフロー制御の対象でなくなる時点までは (サーバや送り先が対処機能を解除していても) 引き続き制御されます。
プロデューサは、セッションから一連のフロー制御属性を受信します。セッションは接続から、接続は接続ファクトリから、この属性を受信します。これらの属性により、プロデューサはメッセージ フローを調整できます。
具体的には、プロデューサはフローを最小値から最大値までの範囲内に制限する属性を受信します。プロデューサは、条件が悪くなると最小値側に移動し、改善されると最大値側に移動します。最小値側および最大値側への移行は、移行率を指定する 2 つの追加属性によって定義されます。また、最小値側および最大値側への移行の必要性は、コンフィグレーションされた間隔ごとに評価されます。
フロー制御フィールドの詳細、およびその有効値とデフォルト値については、Administration Console オンライン ヘルプの「JMS 接続ファクトリ : コンフィグレーション : フロー制御」を参照してください。
バイト数またはメッセージ数のしきい値のコンフィグレーションに使用する属性は、JMS サーバまたはその送り先の一部として定義されます。表 13-3 に、上限しきい値と下限しきい値が JMS サーバまたは JMS 送り先のフロー制御を開始および停止する仕組みを示します。
JMS サーバおよび送り先のその他のしきい値フィールドと割り当てフィールドの詳細、およびそれらの有効値とデフォルト値については、Administration Console オンライン ヘルプの以下のページを参照してください。
以下の節では、メッセージの有効期限ポリシーとアクティブな有効期限処理という 2 つのメッセージ有効期限機能について説明します。これらの機能を使用すると、期限切れメッセージを検索する方法とそれらを検出したときの処理方法をより細かく制御できます。
アクティブなメッセージ有効期限を使用すると、期限切れメッセージが即座に消去されます。さらに期限切れメッセージの監査を使用すると、メッセージがいつ期限切れになったかをログに書き込むか、または期限切れメッセージを定義済みのエラー送り先にリダイレクトすることによって、期限切れメッセージを追跡できます。
有効期限ポリシーを使用して、メッセージが期限切れになったときに実行するアクションを定義します。[送り先] ノードの [有効期限ポリシー] では、送り先ごとに有効期限ポリシーを設定できます。[有効期限ポリシー] 属性を使用すると、期限切れメッセージの検出時に送り先で実行されるアクション (メッセージの破棄、メッセージの破棄とログへの書き込み、またはエラー送り先へのリダイレクト) を定義できます。
また、JMS テンプレートを使用して複数の送り先をコンフィグレーションする場合、[有効期限ポリシー] フィールドを使用して、すべての送り先の有効期限ポリシーをすばやくコンフィグレーションできます。特定の送り先に関するテンプレートの有効期限ポリシーをオーバーライドするには、その送り先の有効期限ポリシーを変更します。
有効期限ポリシーのコンフィグレーション手順については、以下のリンクをクリックしてください。
JMS テンプレートを使用せずにトピックの有効期限ポリシーをコンフィグレーションする場合は、次の手順に従います。特定のトピックに有効期限ポリシーを設定すると、JMS テンプレートに定義されている設定はオーバーライドされます。
トピックの有効期限ポリシー オプションの詳細については、Administration Console オンライン ヘルプの「JMS トピック : コンフィグレーション : 配信の失敗」を参照してください。
[有効期限ログ ポリシー] の有効値の詳細については、「有効期限ログ ポリシーを定義する」を参照してください。
JMS テンプレートを使用せずにキューの有効期限ポリシーをコンフィグレーションする場合は、次の手順に従います。特定のキューに有効期限ポリシーを設定すると、JMS テンプレートに定義されている設定はオーバーライドされます。
キューの有効期限ポリシー オプションの詳細については、Administration Console オンライン ヘルプの「JMS キュー : コンフィグレーション : 配信の失敗」を参照してください。
[有効期限ログ ポリシー] の有効値の詳細については、「有効期限ログ ポリシーを定義する」を参照してください。
JMS テンプレートを使用すると、似た属性設定を持つ複数の送り先 (トピックまたはキュー) を効率的に定義できます。このため、送り先用の既存のテンプレート上でメッセージ有効期限ポリシーをコンフィグレーションできます。
テンプレートの有効期限ポリシー オプションの詳細については、Administration Console オンライン ヘルプの「JMS テンプレート : コンフィグレーション : 配信の失敗」を参照してください。
[有効期限ログ ポリシー] の有効値の詳細については、「有効期限ログ ポリシーを定義する」を参照してください。
| 注意: | [有効期限ログ ポリシー] パラメータはこのリリースの WebLogic Server では非推奨となっています。代わりに、メッセージ ライフ サイクルのロギング機能を使用することをお勧めします。この機能を使用すると、JMS サーバに届いた JMS メッセージに発生する基本的なイベントを、詳細な有効期限データも含め包括的に把握できます。メッセージ ライフ サイクルのロギング オプションの詳細については、『WebLogic JMS のコンフィグレーションと管理』の「メッセージ ライフ サイクルのロギング」を参照してください。 |
[有効期限ポリシー] が [ログ] に設定されている場合、[有効期限ログ ポリシー] で、メッセージに関するどの情報がログに書き込まれるかを定義します。[有効期限ログ ポリシー] の有効値は、%header%、%properties%、JMS 仕様で定義されている JMS ヘッダ プロパティ、WebLogic JMS 固有の拡張ヘッダ フィールドの JMSDeliveryTime と JMSRedeliveryLimit、およびユーザ定義のプロパティです。各プロパティは、カンマで区切る必要があります。
%header% 値は、ヘッダ フィールドがログに書き込まれることを示します。%properties% 値は、ユーザ プロパティがログに書き込まれることを示します。どちらの値も、大文字と小文字は区別されません。ただし、個別の JMS ヘッダ フィールドおよびユーザ プロパティの列挙値は、大文字と小文字が区別されます。
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 秒待機します。
アクティブなスキャンを無効にするには、0 を入力します。期限切れメッセージは、検出時にシステムからパッシブに削除されます。
[有効期限スキャン間隔] 属性の詳細については、Administration Console オンライン ヘルプの「JMS サーバ : コンフィグレーション : 全般」を参照してください。
設計上の選択には、JMS アプリケーションのパフォーマンスに影響を与えるものが多数あります。信頼性、スケーラビリティ、管理容易性、モニタ、ユーザ トランザクション、メッセージ駆動型 Bean のサポート、アプリケーション サーバとの統合などの要素がパフォーマンスに影響します。また、WebLogic JMS の拡張と機能もパフォーマンスに直接的な影響を与えます。
お使いのアプリケーションを JMS に対応するように設計する方法については、『WebLogic JMS プログラマーズ ガイド』の「アプリケーション設計のベスト プラクティス」を参照してください。
メッセージ順序単位は WebLogic Server の付加価値機能です。スタンドアロンのメッセージ プロデューサや、単体として動作するプロデューサのグループは、この機能を使用して複数のメッセージを処理順序 (下位順序) に応じた 1 つの単位にグループ化できます。この単位を順序単位 (UOO) と呼び、この単位にまとめられたすべてのメッセージは作成順に従って処理されます。以下の複雑な設計パターンについて UOO を使用するように置き換えます。
『WebLogic JMS プログラマーズ ガイド』の「メッセージ順序単位の使用」を参照してください。
以下の節では、UOO 使用時のベスト プラクティスについて説明します。
「メッセージ駆動型 Bean のチューニング」を参照してください。
分散送り先を使用している場合、厳格なメッセージ順序を確実に適用するために、各 UOO は特定の物理的送り先のインスタンスに固定されます。所定の UOO に対して自動的に適切な物理的送り先を決定するため、以下の 2 つのオプションが用意されています。
WebLogic Server 9.0 より前のリリースでは、厳格なメッセージ順序要件のあるアプリケーションで以下のことを行う必要がありました。
UOO を使用すると複数のコンシューマを利用でき、非同期コンシューマのメッセージ バックログのサイズを任意で指定できるので、こうした要件が大幅に緩和されます。古いアプリケーションを移行して UOO を利用できるようにするには、単純に物理的送り先にデフォルトの UOO 名をコンフィグレーションします。Administration Console オンライン ヘルプの「接続ファクトリの順序単位パラメータのコンフィグレーション」および『WebLogic JMS プログラマーズ ガイド』の「メッセージの再配信の順序付け」を参照してください。
一方向メッセージ送信は、送信側によってボトルネックとされているアプリケーションのパフォーマンスを大幅に向上させることが可能ですが、QOS (サービス品質) が低下するリスクを伴います。JMS プロデューサからの一般的なメッセージ送信は、内部要求と内部応答の両方が含まれることから、「双方向送信」と呼ばれています。プロデューサ アプリケーションが send() を呼び出すと、この呼び出しは、アプリケーションのメッセージが含まれる要求を生成し、そのメッセージの受信を確認するまで JMS サーバからの応答を待機します。この呼び出し/応答メカニズムでは、プロデューサが制御されます。これは、プロデューサ アプリケーションは、別の送信呼び出しを行うことができるようになるまで、JMS サーバの応答を待機するように強いられるためです。応答メッセージを無くすことによって、この待機時間も無くなり、「一方向送信」となります。WebLogic Server では、非永続、非トランザクションのメッセージ処理に対してコンフィグレーション可能な一方向送信オプションがサポートされています。この機能は、アプリケーション コードを変更することなく利用できます。
一方向送信モードのオプションを有効にすると、ユーザ定義の接続ファクトリで作成したメッセージ プロデューサで、一方向メッセージ送信ができるようになります (可能な場合)。一方向メッセージ送信が可能な場合、関連付けられたプロデューサは、対象送り先のホスト JMS サーバからの応答を内部で待機することなく、メッセージを送信できます。キュー センダおよびトピック パブリッシャに一方向送信を許可したり、この機能をトピック パブリッシャのみに制限したりできます。一方向ウィンドウ サイズを指定して、追加の一方向送信を続行する前に、プロデューサを制御するために双方向メッセージが必要になる時期を決定する必要があります。
接続ファクトリの一方向メッセージ送信パラメータは、Administration Console を使用してコンフィグレーションします。詳細については、Administration Console オンライン ヘルプの「接続ファクトリのフロー制御のコンフィグレーション」を参照してください。また、FlowControlParamsBean MBean を介した JMX または WebLogic Scripting Tool (WLST) の使用も可能です。
| 注意: | 接続ファクトリが「XA 対応」としてコンフィグレーションされている場合、一方向メッセージ送信は無効になります。この設定では、送信側が実際にトランザクションを使用しているかどうかに関係なく、一方向送信が無効になります。 |
送り先が 1 つの場合のクラスタで一方向送信をサポートするには、送り先をホストしている JMS サーバと接続ファクトリが、同じ WebLogic サーバに対象指定されていることを確認します。接続ファクトリが、クラスタ内のその他の WebLogic Server インスタンスに対象指定されている場合はサポートされません。
同じ名前を共有する送り先が複数ある場合のクラスタで一方向送信をサポートするには、クライアント接続をホストしている WebLogic Server インスタンスでもその送り先を確実にホストする必要があります。1 つのソリューションを次に示します。
local-jndi-name を持つようにコンフィグレーションします。
このソリューションでは、EJB ホームおよび JMS 接続ファクトリを含む、クラスタ化された RMI オブジェクト用の RMI レベルのロード バランシングは無効にされます。クライアントは JNDI コンテキストの確立に使用されるネットワーク アドレスにのみ基づいて接続および送り先を効率的に取得します。ロード バランシングは、WebLogic Server アドレスのカンマ区切りのリストが含まれる複数の URL、または、ネットワーク管理者によってコンフィグレーションされる IP アドレスの「ラウンドロビン」セットに解決される DNS 名を指定する複数の URL に対して行われる、「ネットワーク ロード バランシング」を利用することによって達成されます。
クラスタのサーバ アフィニティの詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「EJB と RMI オブジェクトのロード バランシング」を参照してください。
この節では、一方向送信がサポートされないケースを示します。一方向送信がサポートされない場合、送信の QOS は、標準の双方向に自動的にアップグレードされます。
一方向送信は、対象送り先をホストしている JMS サーバとクライアント プロデューサの接続ホストが、同じ WebLogic Server インスタンスである場合にサポートされます。これらが同じでない場合、一方向モード設定は無視され、標準の双方向送信が代わりに使用されます。
クライアントのホスト接続ファクトリが「XA 対応」としてコンフィグレーションされている場合、一方向メッセージ送信は無効になります。この設定では、送信側が実際にトランザクションを使用しているかどうかに関係なく、一方向送信が無効になります。
次に示す、より高度な QOS 機能が検出された場合には、一方向モードの設定は無視され、代わりに標準の双方向送信が使用されます。
対象送り先で指定された割り当てを超過している場合、その割り当てがクリアになるまで標準の双方向送信が使用されます。
割り当てを超過する一方向メッセージは、例外がクライアントに即座に返されることなく、通知のないまま削除されます。クライアントは、次の双方向送信が行われる際、送り先が割り当てをまだ超過している場合に、割り当ての例外を取得することになります。(一方向モードでも、クライアントは、クライアントの接続ファクトリでコンフィグレーションされた [一方向送信ウィンドウ サイズ] のメッセージ数ごとに双方向メッセージを送信します)。
割り当て条件内で通知なしにメッセージが削除されるのを回避できる 1 つの方法は、接続ファクトリでコンフィグレーションされる [Blocking Send Timeout] の値を増やすことです (「メッセージの圧縮」を参照)。一方向メッセージは、即座に削除されることはありませんが、メッセージが消費されるか、期限切れになることによって割り当て条件がクリアになるまでの一定時間、JMS サーバで待機することになります。クライアントの送信側は、双方向メッセージを送信するまでブロックすることはありません。各クライアントに対して、一方向ウィンドウ サイズの数を超えるメッセージが割り当て条件がクリアになるのを待機してサーバ上で蓄積されることはありません。
サーバサイドのセキュリティ ポリシーで変更があると、JMS クライアントがその変更をセキュリティ ステータスで通知されることなく、一方向メッセージ送信ができなくなる場合があります。
ホスト JMS サーバや対象送り先が管理上の理由からアンデプロイされている場合、または、「生成の休止/再開」機能を使用して JMS サーバや対象送り先のいずれかにおいてメッセージ生成が休止されている場合、一方向送信は無効になる場合があります。詳細については、『WebLogic JMS のコンフィグレーションと管理』の「生成の休止と生成の再開」を参照してください。
一方向メッセージ送信が分散送り先で機能するのは、クライアントが、論理分散送り先の名前を使用するのではなく、物理分散送り先メンバーを直接ルックアップする場合です。詳細については、『WebLogic JMS プログラマーズ ガイド』の「分散送り先の使用」にある「分散送り先メンバーへのアクセス」を参照してください。
ハードウェアまたはネットワークに障害があると、一方向送信は無効になります。こうした場合、JMS プロデューサは、OnException または次の双方向メッセージ送信によって通知されます (一方向モードでも、クライアントは、クライアントの接続ファクトリでコンフィグレーションされた [一方向送信ウィンドウ サイズ] のメッセージ数ごとに双方向メッセージを送信します)。さらに、プロデューサが閉じられます。最悪の場合、障害が発生した直前の最後の双方向メッセージまでのすべてのメッセージが失われる場合があります。
一般的な非永続メッセージングで一方向送信モードを使用する場合は、次の QOS 関連のガイドラインを使用します。
JMS 送り先の [メッセージング パフォーマンスのオプション] というチューニング オプションを使用すると、コンシューマに配信可能なメッセージの完全なバッチが作成されるまで送り先が待機する時間 (必要がある場合) を制御できるようになります。最小値の場合、バッチ処理は無効になります。デフォルト値よりも大きな値にチューニングすると、使用できるメッセージをバッチ処理するまで送り先が待機する時間が延長されます。完全なバッチの最大メッセージ数は、JMS 接続ファクトリの [セッションあたりの最大メッセージ数] 設定で制御されます。
この高度なオプションは Administration Console から利用できます。スタンドアロンおよび共通分散送り先 (DestinationBean API でも可能)、または JMS テンプレート (TemplateBean API でも可能) の全般コンフィグレーションのページを使用して設定します。
具体的に言うと、JMS 送り先には、メッセージをバッチにまとめてコンシューマへ配信することにより、自動的にパフォーマンスを最適化しようとする内部アルゴリズムがあります。メッセージ レートや他の要因の変化に応じて、こうしたアルゴリズムでバッチのサイズや配信時間が変更されます。ただし、このようなアルゴリズムですべてのメッセージング環境のパフォーマンスを最適化することはできません。[メッセージング パフォーマンスのオプション] を指定することで、メッセージ レートや他の要因の変更に応じたアルゴリズムの対応方法を変更して、システムのパフォーマンスを調整できます。
[メッセージング パフォーマンスのオプション] には、以下のコンフィグレーション パラメータがあります。
|
||||
|
||||
お使いのシステムに最適な値を見つけるためには、ある程度の実験が必要な場合もあります。たとえば、並列する多数のメッセージ コンシューマが設定されたキューの場合、Administration Console で [メッセージをバッチ処理しない] という値を選択 (または DestinationBean MBean に「0」を指定) すると、そのキューではコンシューマが利用可能になるとすぐに、できるだけ早くそのコンシューマにメッセージを送出しようとします。反対に、迅速な応答が求められないメッセージ コンシューマが 1 つだけ設定されているキューの場合、Administration Console で [メッセージ バッチ処理の最大待機しきい値] という値を選択 (または DestinationBean MBean に「100」を指定) すると、そのキューではメッセージをバッチの形でのみコンシューマに送出しようとし、結果として待機時間は増加しますが、送出回数が少なくなるのでサーバ全体のスループットが向上する場合があります。
スタンドアロンの送り先、共通分散送り先、または JMS テンプレートに対して、Administration Console で [メッセージング パフォーマンスのオプション] パラメータをコンフィグレーションする手順については、Administration Console オンライン ヘルプの以下の節を参照してください。
これらのパラメータの詳細については、『WebLogic Server MBean Reference』の「DestinationBean」と「TemplateBean」を参照してください。
[メッセージング パフォーマンスのオプション] は、非同期メッセージ パイプラインを使用する非同期コンシューマに対応しています。また、同期コンシューマのプリフェッチ モード機能 (非同期メッセージ パイプラインの模擬機能) を使用する同期コンシューマにも対応します。ただし、[最大メッセージ数] に設定されている値が小さすぎると、送り先のより高いレベルのパフォーマンス アルゴリズム (たとえば、[メッセージ バッチ処理の最小待機しきい値]、[メッセージ バッチ処理の中間待機しきい値]、[メッセージ バッチ処理の最大待機しきい値]) の影響が無効になる場合があります。非同期メッセージ パイプラインの詳細については、『WebLogic JMS プログラマーズ ガイド』の「メッセージの受信」を参照してください。
  
|
