AquaLogic Service Bus のチューニング

この節では、AquaLogic Service Bus のチューニングのヒントを示します。

可能な限り、ロギングレベルを「警告」に設定する。ロギングレベルは WebLogic Server Administration Console で設定します。詳細については、WebLogic Server Administration Console オンラインヘルプの「サーバ : ロギング : 全般」を参照してください。次のコードは、ロギングレベルを警告に設定した場合の出力サーバの config.xml ファイルを示しています。ロギングの詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシサービス : アクション」にある「ログ」を参照してください。

<server>

  <name>AdminServer</name>

  <log>

    <file-min-size>5000</file-min-size>

    <log-file-severity>Warning</log-file-severity>

    <log-file-filter xsi:nil="true"></log-file-filter>

    <stdout-severity>Off</stdout-severity>

    <stdout-filter xsi:nil="true"></stdout-filter>

    <domain-log-broadcast-severity>Error</domain-log-broadcast-severity>

    <domain-log-broadcast-filter xsi:nil="true"></domain-log-broadcast-filter>

    <memory-buffer-severity>Error</memory-buffer-severity>

    <memory-buffer-filter xsi:nil="true"></memory-buffer-filter>

  </log>

</server>

メッセージの負荷に基づいて、各種 JMS サーバの JMS キューをグループ化する。JMS サーバの種類によって使用されるファイルストアは異なり、これらのファイルストアを異なるディスクボリュームに分散させることができます。詳細については、『AquaLogic Service Bus Console の使い方』の「ビジネスサービス」にある「ビジネスサービスの追加」の JMS コンフィグレーションの説明を参照してください。
Oracle データベースを JMS の永続ストアとして使用している場合は、必要な JDBC 接続を備えた 10g データベースを使用することが推奨される。JDBC ストアを別のスキーマに作成し、使用するテーブルスペースも別にします。
プロキシサービスまたはビジネスサービスのモニタが不要な場合は、モニタ機能を無効にする。詳細については、『AquaLogic Service Bus Console の使い方』の「モニタ」にある「モニタの概要」を参照してください。
可能な限り、JMS メッセージプロパティのルーティングデータを設定する。AquaLogic Service Bus では、メッセージコンテンツは、パイプラインで明示的にアクセスしないかぎりデシリアライズされません。たとえば、メッセージコンテンツが XML ドキュメントの場合、パイプラインで XQuery または XSLT の操作が行われない限り、XML は解析されません。メッセージフロー内でのメッセージコンテキストの使用方法の詳細については、『AquaLogic Service Bus Console の使い方』の「メッセージコンテキスト」を参照してください。
処理対象となる着信ヘッダ要素の一部を抽出する場合は、すべての要素ではなく、特定のヘッダ要素を取得するように AquaLogic Service Bus に指定する。
Oracle データベースを JMS の永続ストアとして使用している場合は、必要な JDBC 接続が使用可能であることを確認することが推奨される。これにより、管理者は、メッセージサイズに基づいてブロックサイズをチューニングできます。別々のデータファイルに個々のテーブルスペースを作成しそれらのデータファイルを別々のディスクに置くことも可能です。このように配置することで、データファイルが RAID で保管されていない場合に、ハードウェアレベルでより高度な並行処理が実現できます。
可能な限り、割り当てアクションではなく、挿入アクションを使用する。挿入アクションでは、「同位置」変更セマンティクスが使用されるため、割り当てアクションよりもパフォーマンスが向上します。アクションのコンフィグレーションについては、『AquaLogic Service Bus Console の使い方』の「プロキシサービス : アクション」にある「アクションの追加」を参照してください。
スケーラビリティを実現するには、AquaLogic Service Bus クラスタ化および WebSphere MQ クラスタ化を使用する。
WebLogic Server で Accept Backlog パラメータをコンフィグレーションする場合は、最初にデフォルト値を 25% 増加させることが推奨される。「connection refused, socket exception」が送出される場合、例外が送出されなくなるまで値は増加し続けます。WebLogic Server のチューニングの詳細については、「WebLogic Server のチューニング」を参照してください。
フロントエンドアプリケーションで AquaLogic Service Bus を同期的に起動する場合、同期/非同期機能を使用して WebSphere MQ と同期通信することができる。WebSphere MQ 側で、要求および応答キューが設定されます。AquaLogic Service Bus から要求キューに要求を送信し、応答キューからの応答を待機します。パフォーマンスを向上させるには、応答メッセージ駆動型 Bean 専用のワークマネージャを使用します。専用ワークマネージャのコンフィグレーションは WebLogic Server Administration Console で行います。詳細については、WebLogic Server Administration Console オンラインヘルプの「ワークマネージャ」を参照してください。次のコードは、専用ワークマネージャをコンフィグレーションした後の出力サーバの config.xml ファイルを示しています。

<self-tuning>

 <min-threads-constraint>

    <name>minThreadsConstraint</name>

    <target>AdminServer</target>

    <count>20</count>

 </min-threads-constraint>

 <work-manager>

    <name>MQWorkManager</name>

    <target>AdminServer</target>

    <min-threads-constraint> minThreadsConstraint </min-threads-constraint>

    <ignore-stuck-threads>false</ignore-stuck-threads>

 </work-manager>

</self-tuning>

ユーザーズ ガイド

AquaLogic Service Bus のチューニング

ユーザーズガイド