| Oracle® Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング 12c リリース1 (12.1.1) B65905-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング 12c リリース1 (12.1.1) B65905-02 |
|
前 |
次 |
この章では、メッセージング・ブリッジのパフォーマンスを向上させる様々な方法について説明します。
リモートの宛先の可用性があらかじめ高い場合、メッセージング・ブリッジの使用は避けます。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クラスのワーク・マネージャを構成します。『WebLogic Serverサーバー環境の設計と構成』のワーク・マネージャに関する項を参照してください。
管理コンソールを使用して、サーバー・インスタンスの構成: サービスページの「メッセージング・ブリッジの構成」の項で、スレッド・プール・サイズプロパティを設定します。サーバー内のデフォルトの実行スレッド・プールとの競合を避けるため、メッセージング・ブリッジ群では別個のスレッド・プールを共有します。このスレッド・プールは同期モードでのみ使用されます(「非同期モードの有効化」は設定されていません)。非同期モードでは、ブリッジはソース宛先のJMSプロバイダで作成されたスレッドで実行されます。WebLogic Server 9.0では非推奨になっています。
ブリッジのトピックでのリスニング中に、ブリッジによってメッセージの転送が行われていないときに、メッセージを失っても構わない場合、「恒久性の有効化」フラグを無効にして、転送されていないメッセージがサーバーのストアに収集されないことを確認します。フラグを無効にすると、メッセージが非永続メッセージになります。Oracle WebLogic Server管理コンソール・ヘルプのメッセージング・ブリッジ・インスタンスの構成に関する項を参照してください。
メッセージング・ブリッジのソースまたはターゲットがWebLogic宛先である場合、ブリッジをその宛先と同じWebLogic Serverにデプロイします。メッセージング・ブリッジをその宛先の1つに割り当てると、関連するネットワークおよびシリアライゼーションのオーバーヘッドが削減されます。このようなオーバーヘッドは高スループットのアプリケーションで、特にメッセージが非永続の場合に増大することがあります。
「非同期モードの有効化」属性は、http://download.oracle.com/javaee/5/api/javax/jms/MessageListener.htmlでJMS MessageListenerインタフェースを使用して、メッセージング・ブリッジで非同時メッセージを受信するかまたはJMS APIを使用して同時メッセージを受信するかを決定します。多くの場合は、「非同期モードの有効化」属性の値は、表16-1で示されているように、アプリケーション環境に必要なQOSによって異なります。
脚注 1 ソース宛先がWebLogic JMSプロバイダ以外で、QOSが「必ず1回」の場合、「非同期モードを有効化」属性は無効になり、メッセージは同期モードで処理されます。
Oracle WebLogic Server管理コンソール・ヘルプのメッセージング・ブリッジ・インスタンスの構成に関する項を参照してください。
「必ず1回」のサービス品質が指定されていると、ブリッジのパフォーマンスに大きく影響します。ブリッジによりメッセージごとに新しいトランザクションが開始され、そのトランザクションに関与する両方のJMSサーバーに渡って2フェーズ・コミットが実施されます。2フェーズ・コミットは通常、ブリッジのトランザクションでもっともコストのかかる部分です。処理されるメッセージ数が増加するとブリッジのパフォーマンスは低下する傾向があります。
