WebLogic メッセージング ブリッジのコンフィグレーションと管理
|
 |
 |
|
メッセージング ブリッジのチューニングの主な目的は、メッセージングの全体的なパフォーマンスの向上です。処理速度を高速に保つことも重要ですが、これは数あるパフォーマンス関連の要素の 1 つにすぎません。パフォーマンスには他にも、信頼性、スケーラビリティ、管理容易性、モニタ、ユーザ トランザクション、メッセージ駆動型 Bean のサポート、アプリケーション サーバとの統合などの要素が影響します。
以下の節では、メッセージング ブリッジのパフォーマンスを向上させるためのさまざまな方法について説明します。
[非同期モードを有効化] 属性が false に設定されていて、サービス品質が [必ず 1 回] の場合、[バッチ サイズ] 属性を使用してトランザクション (バッチ) ごとのメッセージ数を増やすことで、トランザクションのコミット数を減らせます。ブリッジ インスタンスにとって最適なバッチ サイズは、使用している JMS プロバイダ、ハードウェア、オペレーティング システム、およびそのアプリケーション環境における他の要素の組み合わせで決まります。Administration Console オンライン ヘルプの「トランザクション プロパティのコンフィグレーション」を参照してください。
[非同期モードを有効化] 属性が false に設定されていて、サービス品質が [必ず 1 回] の場合、BatchInterval 属性を使用して、バッチされたメッセージを転送する前にブリッジで各バッチがいっぱいになるまで待機する時間を調整できます。ブリッジ インスタンスにとって最適なバッチ間隔は、使用している JMS プロバイダ、ハードウェア、オペレーティング システム、およびそのアプリケーション環境における他の要素の組み合わせで決まります。たとえば、キューがそれほどビジーな状態でない場合、ブリッジで頻繁に転送を停止してバッチがいっぱいになるまで待機するには BatchInterval 属性の値を減らす必要があります。Administration Console オンライン ヘルプの「トランザクション プロパティのコンフィグレーション」を参照してください。
[必ず 1 回] というサービス品質を指定していると、[最大 1 回] や [重複可] の場合に比べてパフォーマンスがかなり向上したり、またはかなり低下したりすることがあります。
[必ず 1 回] のサービス品質を使用している場合、確実にトランザクション セマンティクスを実現するため、ブリッジでは必ず両方の JMS サーバで 2 フェーズ コミットを行います。この操作には、非常にコストがかかることがあります。ただし、[必ず 1 回] を使用していると、他のサービス品質と違ってブリッジで複数の操作をバッチとしてまとめられます。
最大限のパフォーマンスを実現するためには、このパラメータについて検討が必要な場合があります。たとえば、キューがそれほどビジーな状態ではない、または非永続メッセージを使用している場合には、[必ず 1 回] によるバッチ処理からほとんどメリットが得られないこともあります。Administration Console オンライン ヘルプの「メッセージング ブリッジ インスタンスのコンフィグレーション」を参照してください。
メッセージの順序を指定する必要がない場合、複数のブリッジをデプロイすることを検討できます。
同じ送り先を使用するブリッジ インスタンスを複数デプロイできます。このように設定すると、ブリッジの各インスタンスが並行して実行されて、メッセージのスループットが向上する場合があります。複数のブリッジ インスタンスを使用する場合、メッセージはソース送り先にあったときの順番どおりには転送されません。Administration Console オンライン ヘルプの「メッセージング ブリッジ インスタンスの作成」を参照してください。
複数のブリッジを使用するかどうかを判断する際には、以下の要素を検討します。
ブリッジをコンフィグレーションする際の一般的なルールとしては、サーバ インスタンスに割り当てられた各ブリッジ インスタンスに 1 つのスレッドを用意します。お使いの環境で適切な数のスレッドを利用できるようにするには、以下の方法のいずれかを行います。
weblogic.jms.MessagingBridge クラスのワーク マネージャをコンフィグレーションする。『WebLogic Server 環境のコンフィグレーション』の「Understanding Work Managers」を参照してください。スレッド プール サイズ] プロパティを設定する。サーバ内のデフォルトの実行スレッド プールとの競合を避けるため、メッセージング ブリッジ群で別個のスレッド プールが共有されます。このスレッド プールでは同期モードのみが使用されます (非同期
ブリッジのリスン対象がトピックで、メッセージの転送が行われていないときにメッセージが失われても構わない場合、[恒久性を有効化] フラグを無効にして、送信できなかったメッセージがソース サーバのストアに蓄積されないようにできます。このフラグを無効にすると、メッセージは非永続になります。Administration Console オンライン ヘルプの「メッセージング ブリッジ インスタンスのコンフィグレーション」を参照してください。
メッセージング ブリッジのソース送り先または対象送り先が WebLogic 送り先の場合、ブリッジをその送り先と同じ WebLogic Server にデプロイします。メッセージング ブリッジをその送り先の 1 つに割り当てると、関連するネットワークおよびシリアライゼーションのオーバーへッドが削減されます。このようなオーバーヘッドは高スループットのアプリケーションで、特にメッセージが非永続の場合に増大することがあります。
[非同期モードを有効化] 属性では、メッセージング ブリッジで JMS MessageListener インタフェースを使用して非同期にメッセージを受信するか、同期 JMS API を使用してメッセージを受信するかを指定します。ほとんどの場合、表 5-1 に示すように、[非同期モードを有効化] 属性の値はアプリケーション環境に必要な QOS によって決まります。
|
|
|
|
|
Administration Console オンライン ヘルプの「メッセージング ブリッジ インスタンスのコンフィグレーション」を参照してください。
[必ず 1 回] のサービス品質が指定されていると、ブリッジのパフォーマンスに大きく影響します。ブリッジによりメッセージごとに新しいトランザクションが開始され、そのトランザクションに関与する両方の JMS サーバに渡って 2 フェーズ コミットが実施されます。2 フェーズ コミットは通常、ブリッジのトランザクションでもっともコストのかかる部分です。処理されるメッセージ数が増加するとブリッジのパフォーマンスは低下する傾向があります。
[必ず 1 回] のサービス品質が必要とされない場合、ソース送り先により各トランザクションで複数のメッセージをパイプライン処理または処理できます。アプリケーションで非同期コンシューマ (MDB など) を使用している場合、WebLogic JMS 接続ファクトリにコンフィグレーションされた MessagesMaximum の値を増やすことを検討します。
注意 : WebLogic JMS 以外の実装の一部では、メッセージのパイプライン処理や非同期リスナの最適化が行われず、その場合 [非同期モードを有効化] パラメータを指定してもほとんど効果がないことがあります。
非同期パイプラインのサイズがすでに 1 に設定されている場合、アプリケーションで順序つき配信が有効化されている、つまりパイプラインを大きくできないことがあります。『WebLogic JMS プログラマーズ ガイド』の「Ordered Redelivery of Messages」を参照してください。
WebLogic JMS では、非同期コンシューマ (メッセージ リスナ) に配信されるメッセージがパイプライン処理されます。これにより、サーバからクライアントに内部的にメッセージが送信されるときにメッセージが集約されるため、パフォーマンスが向上します。JMS サーバとクライアント間のメッセージのバックログ (パイプラインのサイズ) は、接続ファクトリで MessagesMaximum の設定をコンフィグレーションすることでチューニングできます。『WebLogic JMS プログラマーズ ガイド』の「Asynchronous Message Pipeline」を参照してください。
一部の環境では、MessagesMaximum パラメータをチューニングすることでパフォーマンスが大幅に向上することがあります。たとえば、JMS アプリケーションで確認応答やコミットが保留されている場合などです。この場合、MessagesMaximum に次の値を設定することをお勧めします。
|
|
|