15 WebLogicメッセージング・ブリッジのチューニング

この章で説明する方法を使用して、メッセージング・ブリッジのパフォーマンスを改善します。

この章には次の項が含まれます:

ベスト・プラクティス

リモートの宛先の可用性があらかじめ高い場合、メッセージング・ブリッジの使用は避けます。JMSクライアントからリモートの宛先に対して直接的に配信できます。メッセージング・ブリッジは、信頼性に欠けるネットワークや様々なメンテナンス・スケジュールがあるなど、リモートの宛先の可用性が高くない状況で使用します。
リモートの宛先にメッセージを転送する場合、メッセージング・ブリッジではなく、パフォーマンスの優れたJMS SAF機能を使用します。一般に、JMS SAFエージェントはメッセージング・ブリッジに比べてかなり高速です。ただし、非永続的かつ「必ず1回」のモードでメッセージを送信する構成の場合は除きます。

注意:
外部宛先やWebLogic 9.0よりも前のリリースの宛先にメッセージを格納および転送(ストア・アンド・フォワード)するためには、現在もメッセージング・ブリッジが必要です。

バッチ・サイズの変更

「非同期モードの有効化」属性をfalseに設定し、サービス品質が、「必ず1回」の場合、「バッチ・サイズ」を使用して、トランザクション(バッチ)当たりのメッセージ数を増やして、コミットされるトランザクション数を減らすできます。ブリッジ・インスタンスの最適なバッチ・サイズは、使用するJMSプロバイダ、ハードウェア、オペレーティング・システムおよびアプリケーション環境にあるその他の要因の組合せによって異なります。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・プロパティの構成に関する項を参照してください。

バッチ間隔の変更

「非同期モードの有効化」属性をfalseに設定して、サービス品質が、「必ず1回」の場合、BatchInterval属性を使用して、ブリッジがバッチ・メッセージを転送する前にバッチの入力を待機するまでの時間を調整できます。ブリッジ・インスタンスに最適なバッチ間隔は、使用するJMSプロバイダ、ハードウェア、オペレーティング・システムおよびアプリケーション環境にあるその他の要因の組合せによって異なります。たとえば、キューがビジーでない場合、バッチがいっぱいになるまで待機するために、ブリッジが頻繁にメッセージの転送を停止します。この場合、BatchInterval属性の値を小さくする必要があります。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・プロパティの構成に関する項を参照してください。

サービス品質の変更

サービス品質を「必ず1回」に設定すると、「最大1回」や「重複可」に設定した場合に比べ、パフォーマンスが大幅に向上したり低下したりすることがあります。

「必ず1回」のサービス品質を使用している場合、確実にトランザクション・セマンティクスを実現するため、ブリッジでは必ず両方のJMSサーバーで2フェーズ・コミットを行います。この操作には、非常にコストがかかることがあります。ただし、「必ず1回」を使用していると、他のサービス品質と違ってブリッジで複数の操作をバッチとしてまとめられます。

可能なかぎり最高のパフォーマンスを得るために、このパラメータを試みる必要があります。たとえば、キューがビジーでない場合または非永続メッセージを使用した場合、「必ず1回」の一括処理は、ほとんど利点がありません。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのメッセージング・ブリッジ・インスタンスの構成に関する項を参照してください。

複数のブリッジ・インスタンスの使用

メッセージの順序を指定する必要がない場合、複数のブリッジをデプロイすることを検討できます。

同じ宛先を使用してブリッジの複数のインスタンスをデプロイできます。デプロイ後は、ブリッジの各インスタンスが並行して実行されるので、スループットが向上される可能性があります。複数のブリッジ・インスタンスを使用すると、元の宛先と同じ順番でメッセージは転送されません。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのメッセージング・ブリッジ・インスタンスの作成に関する項を参照してください。

複数のブリッジを使用するかどうかを判断する際には、次の要素を検討します。

一部のJMS製品では、複数のブリッジを使用してもあまりメリットがないと想定されます。
通常、WebLogic JMSメッセージングのパフォーマンスはかなり向上します。永続メッセージの処理では特に改善が見られます。
CPUやディスク・ストレージがフルに使用されている場合、ブリッジ・インスタンス数を増やすとスループットが低下することがあります。

スレッド・プール・サイズの変更

ブリッジを構成する際の一般的なルールでは、サーバー・インスタンスに割り当てられた各ブリッジ・インスタンスに1つのスレッドを用意します。ご使用の環境で適切な数のスレッドを利用できるようにするには、次のいずれかを行います。

共有スレッド・プールの使用: サーバーのインスタンスでは、スループットを最大化し、構成済のブリッジ・インスタンス数を補正するために、スレッド・プールのサイズが自動的に変更されます。『Oracle WebLogic Serverサーバー環境の管理』のWebLogic Serverでのスレッド・プールの使用の理解に関する項を参照してください。
weblogic.jms.MessagingBridgeクラスのワーク・マネージャを構成します。詳細は、『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャの理解に関する項を参照してください。
WebLogic Server管理コンソールを使用して、サーバー・インスタンスの「構成: サービス」ページの「メッセージング・ブリッジの構成」セクションで、Thread Pool Sizeプロパティを設定します。サーバー内のデフォルトの実行スレッド・プールとの競合を避けるため、メッセージング・ブリッジ群では別個のスレッド・プールを共有します。このスレッド・プールは同期モードでのみ使用されます(「非同期モードの有効化」は設定されていません)。非同期モードでは、ブリッジはソース宛先のJMSプロバイダで作成されたスレッドで実行されます。WebLogic Server 9.0では非推奨になっています。
ブリッジ・リソース・アダプタ・ツールが、ブリッジ数の2倍であることを確認します。『Oracle WebLogic Server WebLogicメッセージング・ブリッジの管理』のリソース・アダプタに関する項を参照してください。

恒久サブスクリプションの無効化

ブリッジのトピックでのリスニング中に、ブリッジによってメッセージの転送が行われていないときに、メッセージを失っても構わない場合、「恒久性の有効化」フラグを無効にして、転送されていないメッセージがサーバーのストアに収集されないことを確認します。フラグを無効にすると、メッセージが非永続メッセージになります。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのメッセージング・ブリッジ・インスタンスの構成に関する項を参照してください。

ソースまたはターゲット宛先とブリッジの同じ場所への配置

メッセージング・ブリッジのソースまたはターゲットがWebLogic宛先である場合、ブリッジをその宛先と同じWebLogic Serverにデプロイします。メッセージング・ブリッジをその宛先の1つに割り当てると、関連するネットワークおよびシリアライゼーションのオーバーヘッドが削減されます。このようなオーバーヘッドは高スループットのアプリケーションで、特にメッセージが非永続の場合に増大することがあります。

「非同期モードを有効化」属性の変更

「非同期モードの有効化」属性は、メッセージング・ブリッジがhttp://docs.oracle.com/javaee/5/api/javax/jms/MessageListener.htmlのJMS MessageListenerインタフェースを使用して非同期でメッセージを受信するかまたは同期のJMS APIを使用してメッセージを受信するかを決定します。ほとんどの場合、表 15-1に示すように、[非同期モードを有効化]属性の値はアプリケーション環境に必要なQOSによって決まります。

表15-1 QOSレベルと対応する「非同期モードを有効化」属性の値

QOS	「非同期モードを有効化」属性の値
必ず1回^脚注 1	false
`1回以上`	true
`最大1回`	true

^脚注 1

ソース宛先がWebLogic JMSプロバイダ以外で、QOSが「必ず1回」の場合、「非同期モードを有効化」属性は無効になり、メッセージは同期モードで処理されます。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのメッセージング・ブリッジ・インスタンスの構成に関する項を参照してください。

「必ず1回」のサービス品質が指定されていると、ブリッジのパフォーマンスに大きく影響します。ブリッジによりメッセージごとに新しいトランザクションが開始され、そのトランザクションに関与する両方のJMSサーバーに渡って2フェーズ・コミットが実施されます。2フェーズ・コミットは通常、ブリッジのトランザクションでもっともコストのかかる部分です。処理されるメッセージ数が増加するとブリッジのパフォーマンスは低下する傾向があります。

多くのブリッジを使用する環境のチューニング

この項では、多くのブリッジ・インスタンスをデプロイするシステムのシステム起動時間と全般的なパフォーマンスの改善方法について説明します。

weblogic-ra.xml記述子ファイルのmax-capacity属性を調整して、各リソース・アダプタに関連付けられた接続ファクトリの容量を変更します。max-capacity属性の値は、少なくともブリッジ・インスタンス数の2倍にする必要があります。

たとえば、割り当てられているメッセージング・ブリッジ・インスタンスが10個までの環境においては、max-capacity属性は20に設定されているのは適切な設定です。ブリッジ・インスタンスを15個に増やす場合には、max-capacity属性の値を30まで増やします。『Oracle WebLogic Server WebLogicメッセージング・ブリッジの管理』の接続ファクトリの数の設定に関する項を参照してください。
サーバーのスレッド・プール・サイズ全体を、アクティブなブリッジの数よりも少し多くなるように増やします。これは、バッチ・サイズが1よりも大きなXA(トランザクション)ブリッジ、または非WebLogic JMSプロバイダでホストされるソース宛先から消費するXAブリッジに適用されます。

たとえば、メッセージ・ブリッジの数が90の場合、コマンド行で次の内容を指定します。

-Dweblogic.threadpool.MinPoolSize=100

これにより、影響を受けるブリッジを初期化する場合にスレッドが十分に確保されます。スレッドの数が十分ではない場合、新しいスレッドが作成されるまで、何秒もの遅延が生じる可能性があります。
サーバー・インスタンスに割り当てられたブリッジ・インスタンスごとにスレッドを指定します。「スレッド・プール・サイズの変更」を参照してください。