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

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

Java コードのヒント

Java™ で最適化手法をいくつか使用して、メッセージ・フローのパフォーマンスを改善させることができます。

始める前に:
Java に関連したパフォーマンス上の問題のかなりの割合を占めているのは、メモリーとガーベッジ・コレクションの問題、外部リソースとの対話、および最適化の余地がある Java コードが原因で発生する問題です。 以下の手順に従ってこのようなパフォーマンスの問題を識別し、解決してください。
  • JVM リソース統計を使用すると、JVM がどれほどのメモリーを使用しているか、実行グループ内でどれほどの頻度でガーベッジ・コレクションが発生しているかを確認できます。 詳しくは、リソース統計データ: Java 仮想マシン (JVM)を参照してください。
  • 外部リソースを呼び出している場合は、呼び出しの経過時間を確認します。
  • Java コードを調べて、最適化によって改善される可能性のある点を識別します。 メッセージ・フロー内の Java コードのパフォーマンスを最適化するために使用できる手法のいくつかを、以下のセクションで説明します。

JavaCompute ノードでは、任意の有効な Java 処理を含めることができます。また、特定の機能用に既存の Java クラスを再使用することも一般的に行われます。 ただし、このコードはメッセージ・フローのパフォーマンスに影響を与えるため、この方法で使われるすべてのコードを効率的なものにしてください。

可能であれば、既に備わっている関数を再作成する代わりに、IBM® WebSphere® Message Broker に付属のノードと関数を使ってメッセージ処理を実行してください。 例えば、JavaCompute ノード内でカスタム XML パーサーを使用しないでください。 WebSphere Message Broker に付属の XMLNSC パーサーは優れたパフォーマンスのパーサーであり、スキーマの妥当性検査を行う機能もあります。さらに、このパーサーによって生成されるメッセージ・ツリーをメッセージ・フロー全体で使用できます。 独自のデータ構造を持つカスタム・パーサーにはこれが当てはまりません。

特定の処理を実行するために JavaCompute ノード内で新しいプロセスを開始することを避けてください。 これはパフォーマンスの点で高コストです。存続期間の短い多数のプロセスが開始され、作業が完了すると終了されるため、結果として追加の CPU コストが発生し、システムの負荷が増加します。 WebSphere Message Broker ランタイムの利点の 1 つは、プロセスの存続期間が長く、初期化が最小限に抑えられることです。 メッセージ・フロー呼び出しのたびに新しいプロセスが開始されることがないため、これによって全体的な処理コストが削減されます。

実行されている Java アプリケーションの現在の状況を評価する目的で使用できるツールについては、developerWorks® IBM Monitoring and Diagnostic Tools for Java - Health Center Version 2.1 の情報を参照してください。

ツリー参照

中間的な参照を保存せずにツリーを構築/ナビゲートすることを避けてください。 例えば以下のコードでは、ツリーを構築するために root から繰り返しナビゲートします。

MbMessage newEnv = new MbMessage(inAssembly.getMessage());
newEnv.getRootElement().createElementAsFirstChild(MbElement.TYPE_NAME, "Destination", null);
newEnv.getRootElement().getFirstChild().createElementAsFirstChild(MbElement.TYPE_NAME, "MQDestinationList", null);
newEnv.getRootElement().getFirstChild().getFirstChild().createElementAsFirstChild(MbElement.TYPE_NAME,"DestinationData", null);

しかし、以下の例に示すように、参照を保存したほうが効率的です。

MbMessage newEnv = new MbMessage(inAssembly.getMessage());
MbElement destination = newEnv.getRootElement().createElementAsFirstChild(MbElement.TYPE_NAME,"Destination", null);
MbElement mqDestinationList = destination.createElementAsFirstChild(MbElement.TYPE_NAME, "MQDestinationList",
    null);
mqDestinationList.createElementAsFirstChild(MbElement.TYPE_NAME,"DestinationData", null);

Java ストリング連結

演算子 + はパフォーマンスに悪影響を与えます。連結ごとに新しい String オブジェクトが作成されるためです。以下に例を示します。

keyforCache = hostSystem + CommonFunctions.separator
+ sourceQueueValue + CommonFunctions.separator
+ smiKey + CommonFunctions.separator
+ newElement;

パフォーマンスを改善するには、+ 演算子の代わりに StringBuffer クラスと append メソッドを使って java.lang.String オブジェクトを連結します。以下に例を示します。

StringBuffer keyforCacheBuf = new StringBuffer();
keyforCacheBuf.append(hostSystem);
keyforCacheBuf.append(CommonFunctions.separator);
keyforCacheBuf.append(sourceQueueValue);
keyforCacheBuf.append(CommonFunctions.separator);
keyforCacheBuf.append(smiKey);
keyforCacheBuf.append(CommonFunctions.separator);
keyforCacheBuf.append(newElement);
keyforCache = keyforCacheBuf.toString();

Java BLOB の処理

BLOB を処理する必要がある場合 (例えばチャンクへの分割、文字の挿入など)、強力な処理機能を持つ JavaCompute ノードを使用すると効率的です。 JavaCompute ノードを使用する場合には、ByteArrays および ByteArrayOutputStream を使って BLOB を処理してください。

手動での Java ガーベッジ・コレクション

手動でガーベッジ・コレクションを呼び出すことを避けてください。JVM での処理が中断されてメッセージ・スループットが著しく抑制されるためです。 1 つの例として、手動ガーベッジ・コレクションのない状態で 1 秒あたり 1300 個の速度でメッセージを処理していた Java ベースの変換メッセージ・フローの場合、処理されるメッセージごとに 1 つの手動ガーベッジ・コレクション呼び出しが追加された後には、1 秒あたり 100 個のメッセージに低下しました。

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

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

        
        最終更新:
        
        最終更新: 2015-02-28 17:49:14


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