メッセージ・フロー応答時間の最適化

メッセージ・フローを設計する際、組み込みノードの柔軟性と豊富さのゆえに、処理を実行して必要な最終結果を得る方法が通常いくつもあります。 ただし、これらのさまざまなソリューションは、パフォーマンスが異なっているかもしれず、 パフォーマンスが重要な事項である場合には、 機能だけでなくパフォーマンスも考慮に入れて設計する必要があります。

次の 2 つの方法によって、ご使用のアプリケーションのパフォーマンスを識別できます。

  1. 応答時間。 これは、各メッセージがメッセージ・フローによって処理される速度を示します。 これは特に、メッセージ・フローをどのように設計したかによって影響を受けます。 応答時間については、このトピックでさらに解説されます。
  2. スループット。 これは、指定された時間内に特定サイズのメッセージをいくつ、 メッセージ・フローが処理できるかを示します。 これは主に、構成およびシステム・リソースの要因によって影響されるので、他のドメイン構成情報と共にメッセージ・フロー・スループットの最適化で解説されています。

メッセージ・フロー応答時間に影響を与えるいくつかの局面があります。 ただし、ユーザーの特定のビジネス要件に合い、かつ最良の結果を得られるように、 メッセージ・フロー設計を作成および変更する際には、 メッセージ・フローの最終的な複雑さをも考慮する必要があります。 最も効率的なメッセージ・フローが必ずしも、最も分かりやすく最も保守しやすいとは限りません。使用可能なもののうち、ご自分の要件に最も合ったソリューションを試してください。

以下のいくつかの要因が、メッセージ・フローの応答時間に影響を与えます。

メッセージ・フローに組み込むノード数
どのノードもいくらかの処理オーバーヘッドを引き起こします。したがって、サブフローの使用も含め、メッセージ・フローの内容を注意深く検討してください。

メッセージ・フローに使用するノードをできるだけ少なくしてください。メッセージ・フローに組み込むノードはすべて、ブローカー内のオーバーヘッドを増加させます。 単一フロー内のノードの数には上限があります。 この限度はシステム・リソースによって制御されており、 特にスタック・サイズに限度があり、200 ノード程度であるかもしれません。

メッセージ・フローがメッセージの経路を定め、処理する方法
ある状況では、組み込みノード、そしておそらくご使用のシステム内で使用可能な他のノードが、 同じ機能を提供する複数の方法を提供することがあります。 最も簡単な構成を選択するようにしてください。 たとえば、各メッセージ内にあるフィールドの値に基づいて、いくつかの特定の処理を定義する場合には、 一連の Filter ノードを持つメッセージ・フローが、各ケースを処理するように設計できます。 ふさわしければ、Filter ノードを介してメッセージをグループ化し、 各メッセージ・タイプが処理の前に通過する必要のある数を減らすことができます。

たとえば、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 ノードを使用するほうがより効率的です。

メッセージ・フローにループが組み込まれるかどうか
反復ノードのループは避けてください。これは非常に非効率的かもしれず、パフォーマンスおよびスタック上の問題を引き起こす可能性があります。 Compute ノードを複数の PROPAGATE ステートメントと共に使用すれば、一連のノードをループする必要をなくすことができるかもしれません。
ESQL の効率
使用するメッセージ・フロー・ノード用に作成した、すべての ESQL コードをチェックしてください。 ノードを開発してテストする際に、メッセージ処理をファイナライズした時点で不要なステートメントを持っている可能性があります。 また、2 つのステートメントとしてコード化したものを、 1 つのステートメントにできることに気付くかもしれません。 作成した ESQL コードを見直して、さらに単純化してパフォーマンスを改善できないかを調べてください。

前のリリースからメッセージ・フローをインポートした場合には、 バージョン 5.0 で使用可能な ESQL を確認しながら、使用している ESQL ステートメントをチェックして、新しい関数またはステートメントを使用してその効率を高めることができるかどうかを確認します。

持続およびトランザクション・メッセージの使用
持続メッセージはメッセージ・フローの処理中、ディスクに保管されます。 入力と出力の一方または両方のメッセージを非持続に指定できる場合には、このことは行われません。 ご使用のメッセージ・フローが非持続メッセージだけを処理する場合には、 ノードの構成およびメッセージ・フロー自体を調べてください。 メッセージが非持続である場合には、トランザクション・サポートは不必要であるかもしれません。 いくつかのノードのデフォルト構成は、トランザクション処理を強制します。 これらのプロパティーを更新して、メッセージ・フローを再デプロイすれば、 応答時間が改善されることがあります。
メッセージ・サイズ
メッセージが大きいほど、処理時間が長くなります。 大きなメッセージをより小さい情報のチャンクに分割できる場合には、 メッセージ・フローの処理速度を改善できるかもしれません。
メッセージ形式
WebSphere Business Integration Message Broker は、複数のメッセージ形式をサポートし、1 つの形式から別の形式へ変換するために使用できる機能を提供しますが、これはオーバーヘッドを引き起こします。 不必要な変換や変形を行っていないか確かめてください。

関連概念
メッセージ・フロー
メッセージ・フロー・アプリケーションのデプロイメント

関連タスク
ブローカー・ドメインの構成
メッセージ・フロー・スループットの最適化
メッセージ・フローの設計
複数の入力ノードの使用
メッセージ・フローの作成
メッセージ・フローの内容の定義
構成可能プロパティーの編集

関連資料
組み込みノード