設計するそれぞれのメッセージ・フローは、特定の送信元から受け取るメッセージに対して、処理の完全なセットを提供する必要があります。 しかしながらその結果として、多数のノードを組み込んだ非常に複雑なメッセージ・フローができてしまい、パフォーマンスのオーバーヘッドや潜在的なボトルネックを引き起こしてしまうことがあります。 メッセージを処理するメッセージ・フローの数を増やせば、並列処理が行われることになるので、結果としてスループットが改良されます。
メッセージ・フローが実行するアクションをコミットする方法や、メッセージを処理する順番についても考慮することができます。
メッセージ・フローのスループットを最適化するため、次の選択肢を考慮してください。
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 Real-time Transport または WebSphere MQ Multicast Transport を通して受信したメッセージには、メッセージの順序付けを行いません。
この選択肢では、メッセージを処理する順序を決定することもできなくなります。 これは、ブローカー内でアクティブなメッセージ・フローの複数のコピーがある場合に、各コピーが同じキューからのメッセージを同時に処理することがあるためです。 メッセージの処理に要する時間は変わる場合があり、そのために同じキューにアクセスする複数のメッセージ・フローが、入力ソースからメッセージをランダムな順番で読み取ることがあります。 メッセージ・フローによって作成されるメッセージの順番は、元のメッセージの順番に対応しない場合があります。
これらのメッセージ・フローからメッセージを受信するアプリケーションが、メッセージの順番を問わないことを確認してください。