組み込みノードは柔軟性と機能性が高いので、通常は、メッセージ・フローを設計するときに、処理を実行して必要な結果を得る方法がいくつか存在します。ソリューションごとにパフォーマンスのレベルが変わってくる可能性もあるので、パフォーマンスを重視する場合は、パフォーマンスも考慮に入れてメッセージ・フローを設計する必要があります。
アプリケーションは、以下の方法のいずれかで、パフォーマンスを知ることができます。
- 応答時間は、各メッセージがメッセージ・フローによって処理される速度を示します。
応答時間は特に、メッセージ・フローをどのように設計したかによって影響を受けます。
応答時間については、このトピックで解説されます。
- スループットは、指定された時間内に特定サイズのメッセージをいくつ、メッセージ・フローが処理できるかを示します。
スループットは主に、構成およびシステム・リソースの要因によって影響され、他のドメイン構成情報と共に『メッセージ・フロー・スループットの最適化』のトピックで解説されています。
メッセージ・フロー・スループットの最適化を参照してください。
以下のいくつかの面が、メッセージ・フローの応答時間に影響を与えます。
ただし、ユーザーの特定のビジネス要件に合い、かつ最良の結果を得られるように、メッセージ・フロー設計を作成および変更する際には、メッセージ・フローの最終的な複雑さをも考慮する必要があります。
最も効率的なメッセージ・フローが必ずしも、最も分かりやすく最も保守しやすいとは限りません。使用可能なもののうち、自分の要件に最適なソリューションを試してください。
以下のいくつかの要因が、メッセージ・フローの応答時間に影響を与えます。
- メッセージ・フローに組み込むノード数
- 各ノードによって、ブローカーにおいて必要な処理量が増大します。したがって、サブフローの使用も含め、メッセージ・フローの内容を注意深く検討してください。
メッセージ・フローで使用するノードは、できるだけ少なくしてください。メッセージ・フローにノードを組み込むたびに、ブローカー内で必要な処理量は増加します。
単一フロー内のノードの数には上限があります。この限度はシステム・リソース (特にスタック・サイズ) によって制御されます。
スタック・サイズの詳細については、メッセージ・フローの作成に関するシステム考慮事項を参照してください。
- メッセージ・フローがメッセージの経路を定め、処理する方法
- ある状況では、組み込みノード、そしておそらくご使用のシステム内で使用可能な他のノードが、同じ機能を提供する複数の方法を提供することがあります。
最も単純な構成を選択します。
例えば、各メッセージ内にあるフィールドの値に基づいて、いくつかの特定の処理を定義する場合には、一連の 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 ノードの使用を意味することにも配慮する必要があります。ノードが原因で、ブローカーで必要になる処理量が増大すると、利点を上回る可能性があります。
限られた数のメッセージ・タイプを処理する場合には、少数の Filter ノードを使用するほうがより効率的です。
以下の例は、XML_PassengerQuery メッセージ・フローで複数の
Filter ノードを使用するのではなく、
RouteToLabel および
Label ノードを使用する方法を示しています。
以下の例は、メッセージ・フローのメモリー内キャッシュのデータベース表にルーティング情報を保管する方法を示しています。
サンプルは、Message Brokers Toolkit と統合されているインフォメーション・センターを使用する場合にのみ表示できます。
- メッセージ・フローにループが組み込まれるかどうか
- 反復ノードのループは避けてください。これは非常に非効率的かもしれず、パフォーマンスおよびスタック上の問題を引き起こす可能性があります。
Compute ノードを複数の PROPAGATE ステートメントと共に使用すれば、一連のノードをループする必要をなくすことができるかもしれません。
- ESQL の効率
- 使用するメッセージ・フロー・ノード用に作成した、すべての ESQL コードをチェックしてください。
ノードを開発してテストする際に、メッセージ処理をファイナライズした時点で不要なステートメントを持っている可能性があります。
また、2 つのステートメントとしてコード化したものを、1 つのステートメントにできることに気付くかもしれません。作成した ESQL コードを見直して、さらに単純化してパフォーマンスを改善できないかを調べてください。
前のリリースからメッセージ・フローをインポートした場合には、バージョン 6.1 で使用可能な ESQL を確認しながら、使用している ESQL ステートメントをチェックして、新しい関数またはステートメントを使用してその効率を高めることができるかどうかを確認します。
- 持続およびトランザクション・メッセージの使用
- 持続メッセージはメッセージ・フローの処理中、ディスクに保管されます。
その動作を回避するには、入力と出力のいずれかまたは両方のメッセージを非持続として指定します。ご使用のメッセージ・フローが非持続メッセージだけを処理する場合には、ノードの構成およびメッセージ・フロー自体を調べてください。
メッセージが非持続である場合には、トランザクション・サポートは不必要であるかもしれません。
いくつかのノードのデフォルト構成は、トランザクション処理を強制します。
これらのプロパティーを更新して、メッセージ・フローを再デプロイすれば、応答時間が改善されることがあります。
- メッセージ・サイズ
- メッセージが大きいほど、処理時間が長くなります。
大きなメッセージをより小さい情報単位に分割できれば、メッセージ・フローの処理速度を改善できる場合があります。以下の例は、メッセージ・フローの仮想ストレージ要件を最小限にして、大きいメッセージを処理する場合に、メッセージ・フローのパフォーマンスを改善する方法を示しています。
サンプルは、Message Brokers Toolkit と統合されているインフォメーション・センターを使用する場合にのみ表示できます。
- メッセージ形式
- WebSphere® Message Broker は、複数のメッセージ形式をサポートし、1 つの形式から別の形式への変換で使用できる機能を提供しますが、その変換によって、ブローカーで必要な処理量が増大します。
不必要な変換や変形を行っていないか確かめてください。
メッセージ・フローのパフォーマンスを改善する方法の詳細については、メッセージ・フローのパフォーマンスに関する developerWorks® 記事を参照してください。