メッセージ・フローを設計する際、組み込みノードの柔軟性と豊富さのゆえに、処理を実行して必要な最終結果を得る方法が通常いくつもあります。 ただし、これらのさまざまなソリューションは、パフォーマンスが異なっているかもしれず、 パフォーマンスが重要な事項である場合には、 機能だけでなくパフォーマンスも考慮に入れて設計する必要があります。
次の 2 つの方法によって、ご使用のアプリケーションのパフォーマンスを識別できます。
メッセージ・フロー応答時間に影響を与えるいくつかの局面があります。 ただし、ユーザーの特定のビジネス要件に合い、かつ最良の結果を得られるように、 メッセージ・フロー設計を作成および変更する際には、 メッセージ・フローの最終的な複雑さをも考慮する必要があります。 最も効率的なメッセージ・フローが必ずしも、最も分かりやすく最も保守しやすいとは限りません。使用可能なもののうち、ご自分の要件に最も合ったソリューションを試してください。
以下のいくつかの要因が、メッセージ・フローの応答時間に影響を与えます。
メッセージ・フローに使用するノードをできるだけ少なくしてください。メッセージ・フローに組み込むノードはすべて、ブローカー内のオーバーヘッドを増加させます。 単一フロー内のノードの数には上限があります。 この限度はシステム・リソースによって制御されており、 特にスタック・サイズに限度があり、200 ノード程度であるかもしれません。
たとえば、8 つの異なるメッセージ (Invoice、Despatch Note など) を処理するメッセージ・フローがあるとします。 Filter ノードを組み込んで、それぞれのメッセージ・タイプを識別し、 それぞれのタイプに応じて経路を定めるようにすることができます。 最初の Filter ノードで最も頻繁に出現するメッセージ・タイプでテストすることによって、 この技法のパフォーマンスを最適化することができます。 ただし、8 番目のメッセージ・タイプは、必ず 8 つの Filter ノードを通る必要があります。
メッセージ・タイプをグループ化することができる場合 (たとえば、メッセージ・タイプが数値の場合、 4 より大きいすべてのタイプ、また 4 以下のすべてのタイプについて、テストを実行できる場合) には、 必要な Filter ノード数を減らすことができます。 最初の Filter ノードが 4 より大きいかをテストし、 メッセージをさらに 2 つの Filter ノード (真および偽のターミナルに接続されたノード) に渡して、 それぞれ 2 より小さいか、また 6 より小さいかのテストを行います。 その後、さらに 4 つの Filter ノードで、1 または 2、3 または 4、などのテストを行うことができます。 実際に必要な Filter ノード数は同じですが、それぞれのメッセージが通るノードの数は削減されます。
Filter ノードのシーケンスを使用する代わりに、 RouteToLabel ノードを 1 セットの Label ノードと共に使用するほうが良い場合もあります。 その場合、それぞれのメッセージは、より少ないノードを通るので、スループットが改善されます。 ただし、RouteToLabel ノードを使用する場合、Compute ノードも必要になることも考慮する必要があります。Compute ノードのオーバーヘッドは、利点を覆ってしまうかもしれません。 限られた数のメッセージ・タイプを処理する場合には、 少数の Filter ノードを使用するほうがより効率的です。
前のリリースからメッセージ・フローをインポートした場合には、 バージョン 5.0 で使用可能な ESQL を確認しながら、使用している ESQL ステートメントをチェックして、新しい関数またはステートメントを使用してその効率を高めることができるかどうかを確認します。
関連概念
メッセージ・フロー
メッセージ・フロー・アプリケーションのデプロイメント
関連タスク
ブローカー・ドメインの構成
メッセージ・フロー・スループットの最適化
メッセージ・フローの設計
複数の入力ノードの使用
メッセージ・フローの作成
メッセージ・フローの内容の定義
構成可能プロパティーの編集
関連資料
組み込みノード
注意 |
商標 |
ダウンロード |
ライブラリー |
技術サポート |
フィードバック
![]() ![]() |
ac00355_ |