設計するそれぞれのメッセージ・フローは、特定の送信元から受け取るメッセージに対して、処理の完全なセットを提供する必要があります。 この設計の結果として、多数のノードを組み込んだ非常に複雑なメッセージ・フローが原因でパフォーマンスのオーバーヘッドが発生したり、潜在的なボトルネックが作成されたりすることがあります。 メッセージを処理するメッセージ・フローの数を増やして、並列処理が行われるようにし、結果としてスループットを改良することができます。
メッセージ・フローが実行するアクションをコミットする方法や、メッセージを処理する順番についても考慮することができます。
メッセージ・フローのスループットを最適化するため、次の選択肢を考慮してください。
BAR ファイル内のデプロイされたメッセージ・フローの「追加インスタンス」プロパティーを更新することができます。 ブローカーはメッセージ・フローの追加コピーを別個のスレッドで開始し、並列処理が行われます。メッセージの処理順序は重要でない場合には、このオプションがこの状態を処理する最も効率的な方法です。
メッセージ・フローが WebSphere MQ キューからメッセージを受信する場合、MQInput ノードの「順序モード」プロパティーを設定すると、メッセージ処理の順序を制御することができます。
サポートされている任意のプロトコルを使ってブローカーと通信する パブリッシュ/サブスクライブ・アプリケーションの場合、指定されたトピックに関するメッセージは、パブリッシャーから受け取ったのと同じ順序でブローカーによってパブリッシュされます (該当する場合には、メッセージ優先順位に基づく並べ替えが行われます)。 したがって、それぞれのサブスクライバーが、特定のブローカーから、また特定のトピックに関しては特定のパブリッシャーから、そのパブリッシャーによってパブリッシュされた順序で、メッセージを受け取ります。
ただし、時には、メッセージが順序どおりにではなく配信されることもあります。 この状態が生じるのは、例えば、ネットワーク内のリンクが失敗し、後続のメッセージが別のリンクによって経路指定される場合です。
メッセージを受信する順序を確実にする必要がある場合には、それぞれのパブリッシュされたメッセージに対して、Publish コマンドで、SeqNum (シーケンス番号) または PubTime (パブリッシュ・タイム・スタンプ) のいずれかのパラメーターを使用して、パブリッシングの順序を計算することができます。
MQI および AMI ユーザーすべてに推奨される技法については、WebSphere MQ バージョン 6 インフォメーション・センター・オンライン の「アプリケーション・プログラミング・リファレンス」および「アプリケーション・プログラミング・ガイド」セクションを参照するか、あるいは (WebSphere MQバージョン 5.3 の場合) WebSphere MQ ライブラリー Web ページの「アプリケーション・プログラミング・ガイド」および「アプリケーション・プログラミング・リファレンス」ブック (MQI で書かれたプログラムの場合)、および「WebSphere MQApplication Messaging Interface」ブック (AMI で書かれたプログラムの場合) を参照してください。
「WebSphere MQ Application Messaging Interface」ブックは、WebSphere MQ ライブラリー Web ページ (バージョン 5.3 の下にリストされている)、または WebSphere MQ SupportPacs Web ページ の SupportPac™ MA0F から入手可能です。
WebSphere MQ バージョン 6 インフォメーション・センター・オンラインの「パブリッシュ/サブスクライブ・ユーザーズ・ガイド」セクションか、あるいは (WebSphere MQ バージョン 5.3 の場合) WebSphere MQ ライブラリー Web ページの「パブリッシュ/サブスクライブ・ユーザーズ・ガイド」も参照してください。
WebSphere MQ Everyplace® および SCADA アプリケーションは、異なるメソッドのメッセージ順序付けを使用します。WebSphere MQ Mobile Transport および WebSphere MQ Telemetry Transport を参照してください。 ブローカーは、WebSphere MQ Web Services Transport、WebSphere MQ Real-time Transport、またはWebSphere MQ Multicast Transport を通して受信したメッセージには、メッセージの順序付けを行いません。
さらに、メッセージを処理する順序を決定する機能も失われますが、これは、ブローカー内でアクティブなメッセージ・フローの複数のコピーがある場合に、各コピーが同じキューからのメッセージを同時に処理することがあるためです。 メッセージの処理に要する時間は変わる場合があり、そのために同じキューにアクセスする複数のメッセージ・フローが、入力ソースからメッセージをランダムな順番で読み取ることがあります。 メッセージ・フローによって作成されるメッセージの順番は、元のメッセージの順番に対応しない場合があります。
これらのメッセージ・フローからメッセージを受信するアプリケーションが、メッセージの順番を問わないことを確認してください。
次の 2 つの例は、メッセージ・フローを分割できる場合を示しています。
また、固有の処理が行われてきた場合には、Label ノード分岐の接続先である共通処理を完了させるために、別の入力キューおよび入力ノードを加える必要があるかもしれません。
さらに、入力メッセージのサイズを検査して大きなメッセージをリダイレクトするように変更を加え、元のメッセージ・フローの機能を複製する新しいメッセージ・フローを作成することもできます (新しいメッセージ・フローでは、元のメッセージ・フローから直接渡された大きなメッセージだけを処理させます)。
以下のプロパティーは、メッセージ・フローがトランザクションをコミットする頻度を制御します。