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

始める前に:

メッセージ・フロー・ノードに関する概念トピックに目を通しておきます。

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

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

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

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

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

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

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

スタック・サイズの詳細については、メッセージ・フローの作成に関するシステム考慮事項を参照してください。

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

例えば、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 サンプルは、メッセージ・フローのメモリー内キャッシュのデータベース表にルーティング情報を保管する方法を示しています。

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

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

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

メッセージ・フローのパフォーマンスを改善する方法の詳細については、ログ・ファイルのパフォーマンスに関する developerWorks 項目を参照してください。

関連概念
メッセージ・フローの概要
デプロイメントの概要
メッセージ・フローの作成に関するシステム考慮事項
関連タスク
ブローカー・ドメインの構成
メッセージ・フロー・スループットの最適化
メッセージ・フローの設計
複数の入力ノードの使用
メッセージ・フローの作成
メッセージ・フローの内容の定義
構成可能プロパティーの編集
関連資料
組み込みノード
特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック
Copyright IBM Corporation 1999, 2006 最終更新: 08/21/2006
ac00355_