WebSphere Message Broker バージョン 8.0.0.5 オペレーティング・システム: AIX、HP-Itanium、Linux、Solaris、Windows、z/OS

製品の最新バージョンについては、IBM Integration Bus バージョン 9.0 をご覧ください。

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

メッセージ・フロー応答時間を改善するために、さまざまな解決策を使用できます。

始める前に:

メッセージ・フローを設計する際、組み込みノードは柔軟性と数多くの機能を備えているために、処理を実行して必要な最終結果を得る方法が通常いくつもあります。 さまざまな解決策はそれぞれ異なるレベルのパフォーマンスを提供します。パフォーマンスが重要な考慮事項である場合、メッセージ・フローを設計する際にそのことを考慮に入れてください。

アプリケーションは、以下の方法のいずれかで、パフォーマンスを知ることができます。

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

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

メッセージ・フローに組み込むノード数
各ノードによって、ブローカーにおいて必要な処理量が増大します。したがって、サブフローの使用も含め、メッセージ・フローの内容を注意深く検討してください。

メッセージ・フローで使用するノードは、できるだけ少なくしてください。メッセージ・フローにノードを組み込むたびに、ブローカー内で必要な処理量は増加します。 単一フロー内のノードの数には上限があり、この限度はシステム・リソース (特にスタック・サイズ) によって決まります。 スタック・サイズの詳細については、メッセージ・フローの作成に関するシステム・リソースを参照してください。

メッセージ・フローがメッセージの経路を定め、処理する方法

ある状況では、組み込みノード、そしておそらくご使用のシステム内で使用可能な他のノードが、同じ機能を提供する複数の方法を提供することがあります。 最も単純な構成を選択します。 メッセージ・フローは複数タイプのレコードを処理する必要があるため、メッセージ・フロー構造を開発するとき、その構造の中に、タイプを判別するためのメッセージの解析と、それに続いて各タイプの RouteToLabel ノードおよび Label ノードを組み込むことにより、拡張が容易なフレームワークを作成できます。 多数のラベル・ノードが予期される場合には、メッセージ解析とラベルの選択を 1 つのメッセージ・フローに実装して、各ラベル・タイプの処理をそれぞれ別個のメッセージ・フローに実装することを検討してください。 これら 2 つのフロー間のインターフェースは、キューを経由して行います。

以下の例は、XML_PassengerQuery メッセージ・フローで複数の Filter ノードを使用するのではなく、RouteToLabel および Label ノードを使用する方法を示しています。 以下の例は、メッセージ・フローのメモリー内キャッシュのデータベース表にルーティング情報を保管する方法を示しています。
  • Message Routing

    サンプルに関する情報は、WebSphere® Message Broker Toolkit に統合されているインフォメーション・センター、またはオンライン・インフォメーション・センターを使用する場合にのみ表示できます。 サンプルは、WebSphere Message Broker Toolkit に統合されているインフォメーション・センターを使用する場合にのみ実行できます。

メッセージ・フローにループが組み込まれるかどうか
反復ノードのループは避けてください。この方法は非常に効率が悪いことがあり、パフォーマンスおよびスタック上の問題を引き起こす可能性があります。 Compute ノードを複数の PROPAGATE ステートメントと共に使用すれば、一連のノードをループする必要をなくすことができるかもしれません。
ESQL の効率
使用するメッセージ・フロー・ノード用に作成した、すべての ESQL コードをチェックしてください。 ノードを開発してテストする際に、メッセージ処理をファイナライズした時点で不要なステートメントを持っている可能性があります。 また、2 つのステートメントとしてコード化したものを、1 つのステートメントにできることに気付くかもしれません。 作成した ESQL コードを見直して、さらに単純化してパフォーマンスを改善できないかを調べてください。
持続およびトランザクション・メッセージの使用
持続メッセージはメッセージ・フローの処理中、ディスクに保管されます。 入力、出力、またはその両方においてメッセージを非持続に指定することによって、この状況を避けることができます。 ご使用のメッセージ・フローが非持続メッセージだけを処理する場合には、ノードの構成およびメッセージ・フロー自体を調べてください。 メッセージが非持続である場合には、トランザクション・サポートは不必要であるかもしれません。 いくつかのノードのデフォルト構成は、トランザクション処理を強制します。 これらのプロパティーを更新して、メッセージ・フローを再デプロイすれば、応答時間が改善されることがあります。
メッセージ・サイズ
メッセージが大きいほど、処理時間が長くなります。 大きなメッセージをより小さい情報の単位に分割できる場合には、メッセージ・フローの処理速度を改善できるかもしれません。 以下の例は、メッセージ・フローの仮想ストレージ要件を最小限にして、大きいメッセージを処理する場合に、メッセージ・フローのパフォーマンスを改善する方法を示しています。

サンプルに関する情報は、WebSphere Message Broker Toolkit に統合されているインフォメーション・センター、またはオンライン・インフォメーション・センターを使用する場合にのみ表示できます。 サンプルは、WebSphere Message Broker Toolkit に統合されているインフォメーション・センターを使用する場合にのみ実行できます。

メッセージ形式
WebSphere Message Broker は、複数のメッセージ形式をサポートし、1 つの形式から別の形式への変換で使用できる機能を提供しますが、その変換によって、ブローカーで必要な処理量が増大します。 不必要な変換や変形を行っていないか確かめてください。

メッセージ・フローのパフォーマンスを改善する方法の詳細については、developerWorks® の記事 (メッセージ・フローのパフォーマンスに関する developerWorks 記事) を参照してください。

特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        最終更新:
        
        最終更新: 2015-02-28 17:45:17


タスク・トピックタスク・トピック | バージョン 8.0.0.5 | ac00355_