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