メッセージ・フロー応答時間を改善するために、さまざまな解決策を使用できます。
メッセージ・フローを設計する際、組み込みノードは柔軟性と数多くの機能を備えているために、処理を実行して必要な最終結果を得る方法が通常いくつもあります。 さまざまな解決策はそれぞれ異なるレベルのパフォーマンスを提供します。パフォーマンスが重要な考慮事項である場合、メッセージ・フローを設計する際にそのことを考慮に入れてください。
アプリケーションは、以下の方法のいずれかで、パフォーマンスを知ることができます。
以下のいくつかの面が、メッセージ・フローの応答時間に影響を与えます。 ただし、ユーザーの特定のビジネス要件にとって最良の結果を得られるように、メッセージ・フロー設計を作成および変更する際には、メッセージ・フローの最終的な複雑さも考慮してください。 最も効率的なメッセージ・フローが必ずしも、最も分かりやすく最も保守しやすいとは限りません。使用可能なもののうち、自分の要件に最適なソリューションを試してください。
以下のいくつかの要因が、メッセージ・フローの応答時間に影響を与えます。
メッセージ・フローで使用するノードは、できるだけ少なくしてください。メッセージ・フローにノードを組み込むたびに、ブローカー内で必要な処理量は増加します。 単一フロー内のノードの数には上限があり、この限度はシステム・リソース (特にスタック・サイズ) によって決まります。 スタック・サイズの詳細については、メッセージ・フローの作成に関するシステム・リソースを参照してください。
ある状況では、組み込みノード、そしておそらくご使用のシステム内で使用可能な他のノードが、同じ機能を提供する複数の方法を提供することがあります。 最も単純な構成を選択します。 メッセージ・フローは複数タイプのレコードを処理する必要があるため、メッセージ・フロー構造を開発するとき、その構造の中に、タイプを判別するためのメッセージの解析と、それに続いて各タイプの RouteToLabel ノードおよび Label ノードを組み込むことにより、拡張が容易なフレームワークを作成できます。 多数のラベル・ノードが予期される場合には、メッセージ解析とラベルの選択を 1 つのメッセージ・フローに実装して、各ラベル・タイプの処理をそれぞれ別個のメッセージ・フローに実装することを検討してください。 これら 2 つのフロー間のインターフェースは、キューを経由して行います。
サンプルに関する情報は、WebSphere® Message Broker Toolkit に統合されているインフォメーション・センター、またはオンライン・インフォメーション・センターを使用する場合にのみ表示できます。 サンプルは、WebSphere Message Broker Toolkit に統合されているインフォメーション・センターを使用する場合にのみ実行できます。
サンプルに関する情報は、WebSphere Message Broker Toolkit に統合されているインフォメーション・センター、またはオンライン・インフォメーション・センターを使用する場合にのみ表示できます。 サンプルは、WebSphere Message Broker Toolkit に統合されているインフォメーション・センターを使用する場合にのみ実行できます。
メッセージ・フローのパフォーマンスを改善する方法の詳細については、developerWorks® の記事 (メッセージ・フローのパフォーマンスに関する developerWorks 記事) を参照してください。