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