設計するそれぞれのメッセージ・フローは、特定の送信元から受け取るメッセージに対して、処理の完全なセットを提供する必要があります。
この設計の結果として、多数のノードを組み込んだ非常に複雑なメッセージ・フローが原因でパフォーマンスのオーバーヘッドが発生したり、潜在的なボトルネックが作成されたりすることがあります。 メッセージを処理するメッセージ・フローの数を増やして、並列処理が行われるようにし、結果としてスループットを改良することができます。
ブローカーの動作モードは、使用可能なメッセージ・フローの数に影響を与えることがあります。
詳しくは、WebSphere Message Broker のフィーチャーおよび各動作モードに適用される制約事項を参照してください。
メッセージ・フローが実行するアクションをコミットする方法や、メッセージを処理する順番についても考慮することができます。
WebSphere Message
Broker Explorer は、ユーザーがメッセージ・フローの統計データとアカウンティング・データを確認できるようにします。
統計データにアクセスする方法について詳しくは、WebSphere Message Broker Explorer でのアカウンティング・データと統計データの表示を参照してください。
メッセージ・フローのスループットを最適化するため、次の選択肢を考慮してください。
- 単一メッセージ・フローのメッセージを複数のスレッドで処理する
- メッセージ・フローをデプロイすると、ブローカーは自動的に、メッセージ・フローに含まれる入力ノードごとに、メッセージ・フローのインスタンスを 1 つ開始します。
この振る舞いはデフォルトです。 非常に多数のメッセージを処理するメッセージ・フローがある場合、そのフローのインスタンスをさらに多く割り振ることによって、処理されるメッセージの量を増やすことができます。
BAR ファイル内のデプロイされたメッセージ・フローの「追加インスタンス」プロパティーを更新することができます。ブローカーはメッセージ・フローの追加コピーを別個のスレッドで開始し、並列処理が行われます。メッセージの処理順序は重要でない場合には、このオプションがこの状態を処理する最も効率的な方法です。
メッセージ・フローが WebSphere MQ キューからメッセージを受信する場合、MQInput ノードの「順序モード」プロパティーを設定すると、メッセージ処理の順序を制御することができます。
- 「順序モード」を「ユーザー ID による」または「ユーザー定義」に設定し、メッセージ・フローが変換ノードを使用する場合は、「構文解析のタイミング」を「即時」に設定することをお勧めします。
- 1 つのブローカーにメッセージ・フローの複数のコピーを作成する
- また、同じメッセージ・フローのいくつかのコピーを、同じブローカー内の異なる実行グループにデプロイすることもできます。このオプションは、単一のメッセージ・フロー内の処理スレッドの数を増やした場合と同様の効果があります。
さらに、メッセージを処理する順序を決定する機能も失われますが、これは、ブローカー内でアクティブなメッセージ・フローの複数のコピーがある場合に、各コピーが同じキューからのメッセージを同時に処理することがあるためです。
メッセージの処理に要する時間は変わる場合があり、そのために同じキューにアクセスする複数のメッセージ・フローが、入力ソースからメッセージをランダムな順番で読み取ることがあります。
メッセージ・フローによって作成されるメッセージの順番は、元のメッセージの順番に対応しない場合があります。
これらのメッセージ・フローからメッセージを受信するアプリケーションが、メッセージの順番を問わないことを確認してください。 さらに、これらのメッセージ・フローの入力ノードが、さまざまなプロセスでのデプロイメントに適していることを確認してください。
- 複数のブローカーにメッセージ・フローの複数のコピーを作成する
- 同じメッセージ・フローのいくつかのコピーを、異なるブローカーにデプロイすることができます。 このオプションは、ユーザーの構成を変更することを必要とします。
なぜなら、メッセージをメッセージ・フローに提供するアプリケーションが確実に、それらのメッセージを正しい入力キューまたはポートに書き込むことができなければならないからです。 メッセージ・フローをデプロイするときに、メッセージ・フローの構成可能なプロパティーを設定することで、こうした変更を加えることができる場合があります。
- メッセージ・フローの範囲
- ある環境では、単一のメッセージ・フローをいくつかの異なるフローに分割して、それぞれのメッセージ・フローが実行する作業範囲を狭めることができるかもしれません。 メッセージ・フローを分割する場合には、次のことを覚えておいてください。
すなわち、別個のメッセージ・フローを同じ作業単位内で実行することはできず、使用するメッセージ・フローにトランザクションの性質がある場合 (例えば、複数のデータベースの更新など) には、このオプションは適切なソリューションではありません。
次の 2 つの例は、メッセージ・フローを分割すると効果的である場合を示しています。
- RouteToLabel ノードを使用するメッセージ・フローにおいて、入力キューのサイズが増大する場合があります (作業の到着速度が処理速度を上回っていることを示します)。この場合、処理能力を高める必要があるかもしれません。
2 つ目の実行グループでは、メッセージ・フローの別のコピーを使用することができますが、すべてのメッセージを、キュー上の順番どおりに処理したい場合には、このオプションは適切ではありません。 メッセージ・フローの、Label ノードで開始される各分岐を分割することを考慮できます。
それぞれの分岐ごとに、入力キューと入力ノードを提供することによって、そのようにできます。 メッセージが RouteToLabel ノードによって、関係のある Label ノードに経路指定されるとき、そのメッセージは他のすべてのメッセージとはいくらか独立しているので、このオプションは適切でしょう。
また、固有の処理が行われてきた場合には、Label ノード分岐の接続先である共通処理を完了させるために、別の入力キューおよび入力ノードを加える必要があるかもしれません。
- 処理に非常に長い時間がかかるような非常に大きなメッセージを処理するメッセージ・フローがある場合には、以下のようにすることもできます。
- メッセージ・フローの別のコピーを作成して、それが異なる入力キューを使用するようにします (このオプションは、メッセージ・フロー自体の中で設定することもできますし、メッセージ・フローをデプロイする際、このプロパティーを更新することもできます)。
- いくつかのアプリケーションからのメッセージを、代替キューおよびメッセージ・フローにリダイレクトするように、WebSphere MQ キュー別名をセットアップすることもできます。
さらに、入力メッセージのサイズを検査して大きなメッセージをリダイレクトするように変更を加え、元のメッセージ・フローの機能を複製する新しいメッセージ・フローを作成することもできます (新しいメッセージ・フローでは、元のメッセージ・フローから直接渡された大きなメッセージだけを処理させます)。
- コミットの頻度
- メッセージ・フローが WebSphere MQ キューの入力メッセージを受信する場合、メッセージ・フローのシナリオによっては、メッセージ・フローを BAR ファイルに追加した後で、そのデフォルトのプロパティーを変更することによって、スループットを改善できることがあります。 (他の入力ノードで入力メッセージを受信する場合、こうした選択肢は選択不可です。
このようなメッセージ・フローのコミットは、各メッセージごとに実行されます。)
以下のプロパティーは、メッセージ・フローがトランザクションをコミットする頻度を制御します。
- 「コミット・カウント」。 このプロパティーは、入力キューからのメッセージをいくつ処理したら、MQCMIT を発行するかを表します。
- 「コミット・インターバル」。 このプロパティーは、どれだけの時間間隔が経過したら、MQCMIT を開始するかを表します。