メッセージ・フロー・スループットの最適化

設計するそれぞれのメッセージ・フローは、特定の送信元から受け取るメッセージに対して、処理の完全なセットを提供する必要があります。 しかしながらその結果として、多数のノードを組み込んだ非常に複雑なメッセージ・フローができてしまい、パフォーマンスのオーバーヘッドや潜在的なボトルネックを引き起こしてしまうことがあります。 メッセージを処理するメッセージ・フローの数を増やせば、並列処理が行われることになるので、結果としてスループットが改良されます。

メッセージ・フローが実行するアクションをコミットする方法や、メッセージを処理する順番についても考慮することができます。

メッセージ・フローのスループットを最適化するため、次の選択肢を考慮してください。

単一メッセージ・フローのメッセージを複数のスレッドで処理する
メッセージ・フローをデプロイすると、ブローカーは自動的に、メッセージ・フローに含まれる入力ノードごとに、メッセージ・フローのインスタンスを 1 つ開始します。 これがデフォルトの動作です。 しかし、1 つのメッセージ・フローが非常に多くのメッセージを処理する場合、入力ソース (WebSphere MQ キューなど) がボトルネックとなることがあります。

bar ファイル内のデプロイされたメッセージ・フローの「追加インスタンス」プロパティーを更新することができます。 ブローカーはメッセージ・フローの追加コピーを別個のスレッドで開始し、並列処理が行われます。メッセージの処理順序は重要でない場合には、これがこの状態を処理する最も効率的な方法です。

メッセージ・フローが WebSphere MQ キューからメッセージを受信する場合、MQInput ノードの「順序モード」プロパティーを設定すると、メッセージ処理の順序をある程度制御することができます。

  • 順序モード」を「ユーザー ID 順」に設定する場合、ノードは特定のユーザー (MQMD 内の UserIdentifier フィールドによって識別される) からのメッセージが、保証された順序で処理されるようにします。あるユーザーからの以前のメッセージが、メッセージ・フローの別のインスタンスによって現在処理中の場合には、そのユーザーからの 2 番目のメッセージは、メッセージ・フローのインスタンスによって処理されません。
  • 順序モード」を「キュー順序」に設定した場合は、ノードは一度に 1 つのメッセージを処理して、メッセージがキューから読み取られる順序を保持します。したがって、このノードは、メッセージ・フローの「追加インスタンス」プロパティーがゼロに設定されているかのように動作します。

サポートされている任意のプロトコルを使ってブローカーと通信するパブリッシュ/サブスクライブ・アプリケーションの場合、指定されたトピックに関するメッセージは、パブリッシャーから受け取ったのと同じ順序でブローカーによってパブリッシュされます (該当する場合には、メッセージ優先順位に基づく並べ替えが行われます)。 これは通常、それぞれのサブスクライバーが、特定のブローカーから、また特定のトピックに関しては特定のパブリッシャーから、そのパブリッシャーによってパブリッシュされた順序で、メッセージを受け取ることを意味します。

ただし、時には、メッセージが順序どおりにではなく配信されることもあります。 このことが生じるのは、例えば、ネットワーク内のリンクが失敗し、後続のメッセージが別のリンクによって経路指定される場合です。

メッセージを受信する順序を確実にする必要がある場合には、それぞれのパブリッシュされたメッセージに対して、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 を通して受信したメッセージには、メッセージの順序付けを行いません。

1 つのブローカーにメッセージ・フローの複数のコピーを作成する
また、同じメッセージ・フローのいくつかのコピーを、同じブローカー内の異なる実行グループにデプロイすることもできます。 これは、単一のメッセージ・フロー内の処理スレッドの数を増やすのと同様の効果がありますが、通常はさほど注目できるような結果は得られません。

この選択肢では、メッセージを処理する順序を決定することもできなくなります。 これは、ブローカー内でアクティブなメッセージ・フローの複数のコピーがある場合に、各コピーが同じキューからのメッセージを同時に処理することがあるためです。 メッセージの処理に要する時間は変わる場合があり、そのために同じキューにアクセスする複数のメッセージ・フローが、入力ソースからメッセージをランダムな順番で読み取ることがあります。 メッセージ・フローによって作成されるメッセージの順番は、元のメッセージの順番に対応しない場合があります。

これらのメッセージ・フローからメッセージを受信するアプリケーションが、メッセージの順番を問わないことを確認してください。

複数のブローカーにメッセージ・フローの複数のコピーを作成する
同じメッセージ・フローのいくつかのコピーを、異なるブローカーにデプロイすることができます。 このソリューションは、ユーザーの構成を変更することを必要とします。 なぜなら、メッセージをメッセージ・フローに提供するアプリケーションが確実に、それらのメッセージを正しい入力キューまたはポートに書き込むことができなければならないからです。 メッセージ・フローをデプロイするときに、メッセージ・フローの構成可能なプロパティーを設定することで、こうした変更を加えることができる場合があります。
関連概念
メッセージ・フローの概要
デプロイメントの概要
関連タスク
メッセージ・フロー応答時間の最適化
メッセージ・フローの作成
メッセージ・フローの内容の定義
構成可能プロパティーの編集
関連資料
組み込みノード
構成可能なメッセージ・フロー・プロパティー
特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック
Copyright IBM Corporation 1999, 2006 Last updated: 5 01, 2006
ac00350_