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