組み込みノードは柔軟性と機能性が高いので、通常は、メッセージ・フローを設計するときに、処理を実行して必要な結果を得る方法がいくつか存在します。ソリューションごとにパフォーマンスのレベルが変わってくる可能性もあるので、パフォーマンスを重視する場合は、パフォーマンスも考慮に入れてメッセージ・フローを設計する必要があります。
アプリケーションは、以下の方法のいずれかで、パフォーマンスを知ることができます。
- 応答時間は、各メッセージがメッセージ・フローによって処理される速度を示します。
応答時間は特に、メッセージ・フローをどのように設計したかによって影響を受けます。
応答時間については、このトピックで解説されます。
- スループットは、指定された時間内に特定サイズのメッセージをいくつ、メッセージ・フローが処理できるかを示します。
スループットは主に、構成およびシステム・リソースの要因によって影響され、他のドメイン構成情報と共に『メッセージ・フロー・スループットの最適化』のトピックで解説されています。
メッセージ・フロー・スループットの最適化を参照してください。
以下のいくつかの面が、メッセージ・フローの応答時間に影響を与えます。
ただし、ユーザーの特定のビジネス要件に合い、かつ最良の結果を得られるように、メッセージ・フロー設計を作成および変更する際には、メッセージ・フローの最終的な複雑さをも考慮する必要があります。
最も効率的なメッセージ・フローが必ずしも、最も分かりやすく最も保守しやすいとは限りません。使用可能なもののうち、自分の要件に最適なソリューションを試してください。
以下のいくつかの要因が、メッセージ・フローの応答時間に影響を与えます。
- メッセージ・フローに組み込むノード数
- 各ノードによって、ブローカーにおいて必要な処理量が増大します。したがって、サブフローの使用も含め、メッセージ・フローの内容を注意深く検討してください。
メッセージ・フローで使用するノードは、できるだけ少なくしてください。メッセージ・フローにノードを組み込むたびに、ブローカー内で必要な処理量は増加します。
単一フロー内のノードの数には上限があります。この限度はシステム・リソース (特にスタック・サイズ) によって制御されます。
スタック・サイズの詳細については、メッセージ・フローの作成に関するシステム考慮事項を参照してください。
- 持続およびトランザクション・メッセージの使用
- 持続メッセージはメッセージ・フローの処理中、ディスクに保管されます。
その動作を回避するには、入力と出力のいずれかまたは両方のメッセージを非持続として指定します。ご使用のメッセージ・フローが非持続メッセージだけを処理する場合には、ノードの構成およびメッセージ・フロー自体を調べてください。
メッセージが非持続である場合には、トランザクション・サポートは不必要であるかもしれません。
いくつかのノードのデフォルト構成は、トランザクション処理を強制します。
これらのプロパティーを更新して、メッセージ・フローを再デプロイすれば、応答時間が改善されることがあります。
- メッセージ・サイズ
- メッセージが大きいほど、処理時間が長くなります。
大きなメッセージをより小さい情報単位に分割できれば、メッセージ・フローの処理速度を改善できる場合があります。以下の例は、メッセージ・フローの仮想ストレージ要件を最小限にして、大きいメッセージを処理する場合に、メッセージ・フローのパフォーマンスを改善する方法を示しています。
サンプルは、Message Brokers Toolkit と統合されているインフォメーション・センターを使用する場合にのみ表示できます。
メッセージ・フローのパフォーマンスを改善する方法の詳細については、メッセージ・フローのパフォーマンスに関する developerWorks® 記事を参照してください。