JMSストア・アンド・フォワードのチューニングこの章では、ストア・アンド・フォワード(SAF)アプリケーションのパフォーマンスを最大にする方法について説明します。9.0以上のリリースのJMSでは、ローカル・サーバーのインスタンスからリモートJMS宛先への高パフォーマンス・メッセージ転送のためにストア・アンド・フォワードの高度な機能が用意されています。Serverストア・アンド・フォワードの構成と管理』のストア・アンド・フォワード・サービスに関する項を参照してください。ベスト・プラクティスチューニングのヒントベスト・プラクティスリモートの宛先の可用性があらかじめ高い場合、SAFの使用は避けます。JMSクライアントからリモートの宛先に対して直接的に配信できます。SAFは、信頼性に欠けるネットワークや様々なメンテナンス・スケジュールがあるなど、リモートの宛先の可用性が高くない状況で使用します。SAF機能を使用します。SAFエージェントはメッセージング・ブリッジに比べてかなり高速です。非永続的かつ「必ず1回」のモードでメッセージを送信する構成の場合は除きます。9.0よりも前のリリースの宛先にメッセージを格納および転送(ストア・アンド・フォワード)するためには、現在もメッセージング・ブリッジが必要です。(WS-RM)エージェントには別個のSAFエージェントを構成します。永続性が必要なサブシステムでは、サブシステム間で同じWebLogicストアを共有するとパフォーマンスが向上します。SAFおよびJMS操作を含むトランザクション、複数のSAF宛先を含むトランザクション、SAFおよびEJBを含むトランザクションなどがこれに当たります。「WebLogic永続ストアのチューニング」を参照してください。チューニングのヒント利用可能なSAFエージェント間でメッセージ送信をロード・バランシングするには、インポート済み宛先を複数のSAFエージェントにターゲット指定します。SAFの「ウィンドウ・サイズ」を増加します。SAFエージェントはメッセージを10個まで含められるバッチにまとめて転送します。3倍になることがあります。小さなメッセージでは「ウィンドウ・サイズ」の初期値を100とするとより適切です。この値は、後で環境に合わせて最適化できます。大きなサイズのメッセージを処理するアプリケーションで「ウィンドウ・サイズ」を変更しても、パフォーマンスが向上する可能性が低いので、お薦めしません。SAFの動作もチューニングされるので、「両方」タイプのSAFエージェントでこのパラメータをチューニングするのは適切ではありません。注意:分散キューの場合、WindowSizeは無視され、バッチ・サイズは内部で1つのメッセージに設定されます。SAFの「ウィンドウ間隔」を増やします。SAFエージェントの「ウィンドウ間隔」の値は0で、メッセージは到着するとすぐに転送されます。この設定では、効果的な「ウィンドウ・サイズ」が構成された値よりかなり小さくなることがあるため、パフォーマンスが低下する場合があります。「ウィンドウ間隔」の初期値としてより適切な値は500ミリ秒です。この値は、後で環境に合わせて最適化できます。ここで言う小さなメッセージとは数Kよりも小さなものを指します。大きなメッセージとはおよそ10Kのものを指しています。「ウィンドウ間隔」の変更では、フォワーダがすでにメッセージを到着と同じ速度で転送できている場合にのみパフォーマンスが向上します。この場合、フォワーダは新しく届いたメッセージをすぐに転送するのではなく、休止してより多くのメッセージを蓄積してからバッチとして転送します。結果としてバッチ・サイズが大きくなるため、転送スループットが向上して全体的なシステム・ディスクおよびCPUの使用率が低減されますが、待機時間は増大します。注意:分散キューの場合、「ウィンドウ間隔」は無視されます。アプリケーションが重複メッセージに対応できる場合、インポート済み宛先の「非永続QOS」の値を「1回以上」に設定します。reserved.法律上の注意点ライブラリ。