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

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

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

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

単一メッセージ・フローのメッセージを複数のスレッドで処理する
メッセージ・フローをデプロイすると、ブローカーは自動的に、メッセージ・フローに含まれる入力ノードごとに、メッセージ・フローのインスタンスを 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 Web Services TransportWebSphere MQ Real-time TransportまたはWebSphere MQ Multicast Transport を通して受信したメッセージには、メッセージの順序付けを行いません。

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

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

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

複数のブローカーにメッセージ・フローの複数のコピーを作成する
同じメッセージ・フローのいくつかのコピーを、異なるブローカーにデプロイすることができます。 このソリューションは、ユーザーの構成を変更することを必要とします。 なぜなら、メッセージをメッセージ・フローに提供するアプリケーションが確実に、それらのメッセージを正しい入力キューまたはポートに書き込むことができなければならないからです。 メッセージ・フローをデプロイするときに、メッセージ・フローの構成可能なプロパティーを設定することで、こうした変更を加えることができる場合があります。
メッセージ・フローの範囲
ある環境では、単一のメッセージ・フローをいくつかの異なるフローに分割して、それぞれのメッセージ・フローが実行する作業範囲を狭めることができるかもしれません。 このことを行う場合には、次のことを覚えておいてください。 すなわち、別個のメッセージ・フローを同じ作業単位内で実行することはできず、使用するメッセージ・フローにトランザクションの性質がある場合 (例えば複数のデータベースの更新など) には、このオプションは適切なソリューションではありません。

次の 2 つの例は、メッセージ・フローを分割できる場合を示しています。

  1. RouteToLabel を使用するメッセージ・フローにおいて、入力キューがボトルネックとなった。 2 つ目の実行グループでは、メッセージ・フローの別のコピーを使用することができますが、すべてのメッセージを、キュー上の順番どおりに処理したい場合には、これは適切な方法ではありません。 メッセージ・フローの、Label ノードで開始される各分岐を分割することを考慮できます。 それぞれの分岐ごとに、入力キューと入力ノードを提供することによって、そのようにできます。 メッセージが RouteToLabel ノードによって、関係のある Label ノードに経路指定されるとき、そのメッセージは他のすべてのメッセージとはいくらか独立しているので、これは適切な方法でしょう。

    また、固有の処理が行われている場合には、Label 分岐の接続先である共通処理に、別の入力キューおよび入力ノードを加える必要があるかもしれません。

  2. 処理に非常に長い時間がかかるような非常に大きなメッセージを処理するメッセージ・フローがある場合には、以下のようにすることもできます。
    1. メッセージ・フローの別のコピーを作成して、それが異なる入力キューを使用するようにします (これは、メッセージ・フロー自体の中で設定することもできますし、メッセージ・フローをデプロイする際、このプロパティーを更新することもできます)。
    2. いくつかのアプリケーションからのメッセージを、代替キューおよびメッセージ・フローにリダイレクトするように、WebSphere MQ キュー別名をセットアップすることもできます。

    さらに、入力メッセージのサイズを検査して大きなメッセージをリダイレクトするように変更を加え、元のメッセージ・フローの機能を複製する新しいメッセージ・フローを作成することもできます (新しいメッセージ・フローでは、元のメッセージ・フローから直接渡された大きなメッセージだけを処理させます)。

コミットの頻度
メッセージ・フローが WebSphere MQ キューの入力メッセージを受信する場合、メッセージ・フローのシナリオによっては、メッセージ・フローを bar ファイルに追加した後で、そのデフォルトのプロパティーを変更することによって、スループットを改善できることがあります。(他の入力ノードで入力メッセージを受信する場合、こうした選択肢は選択不可です。 このようなメッセージ・フローのコミットは、各メッセージごとに実行されます。)

以下のプロパティーは、メッセージ・フローがトランザクションをコミットする頻度を制御します。

  • コミット・カウント」。入力キューからのメッセージをいくつ処理したら、MQCMIT を発行するかを表します。
  • コミット・インターバル」。どれだけの時間間隔が経過したら、MQCMIT を起動するかを表します。
関連概念
メッセージ・フローの概要
デプロイメントの概要
関連タスク
メッセージ・フロー応答時間の最適化
メッセージ・フローの作成
メッセージ・フローの内容の定義
構成可能プロパティーの編集
関連資料
組み込みノード
構成可能なメッセージ・フロー・プロパティー
特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック
Copyright IBM Corporation 1999, 2006 最終更新: 08/21/2006
ac00350_