18 Web サービスのチューニング

以下の節では、WebLogic Web サービス アプリケーションとアプリケーション リソースの設計、開発、およびデプロイにおけるベストプラクティスを紹介します。

• Web サービスのベスト プラクティス

• Web サービスの信頼性のあるメッセージング エージェントのチューニング

• Web サービスのパフォーマンス改善のための負荷の大きいシステムのチューニング

Web サービスのベスト プラクティス

設計およびアーキテクチャにおける決定は、実行時のパフォーマンスや Web サービス アプリケーションのスケーラビリティに大きく影響します。ここでは、最高のパフォーマンスを得るために重要な推奨事項を紹介します。

• Web サービス アプリケーションは、推移的な性質を持ち適度なサイズのペイロードを伴うサービスについて設計する。

• 適切なサービス (RPC または Document) およびエンコーディング形式 (Encoded または Literal) を選択する。

• パフォーマンス向上のために、シリアライザのオーバーヘッドとネームスペース宣言を制御する。

• SOAP メッセージのフォーマットを最適化するため、MTOM/XOP または Fast Infoset を使用する。

• パフォーマンスの低下を最小限に抑えるため、SOAP アタッチメントおよびセキュリティ実装を慎重に設計する。

• 以下のようなアプリケーションでは、非同期のメッセージング モデルの使用を検討する。

• 転送が低速で信頼性に欠ける。

• 複雑で実行時間の長い処理を扱う。

• トランザクション対応のサービス指向アーキテクチャ (SOA) の場合、パフォーマンスを向上させるにはロギング ラスト リソース (LLR) のトランザクションの最適化を使用することを検討する。「ロギング ラスト リソースのチューニング」を参照してください。

• ネットワークのオーバーヘッドを最小限に抑えることでパフォーマンスを向上させるには、レプリケーション、データのキャッシュ、およびスキーマ定義を使用する。

• XML 圧縮のオーバーヘッドがネットワーク レイテンシよりも小さい場合、XML 圧縮を使用する。

• パーサなど、XML 機能を頻繁に使用するアプリケーションでは、パフォーマンスの問題が発生するか、記述子が足りなくなる場合がある。これは、jaxp.properties ファイル (JAXP API) でルックアップを行うことによって、XML パーサ インスタンスがブートストラップされるために発生する場合があります。実行時に不要なファイル操作が行われないように、およびパフォーマンスやリソースの使用率が向上するように、このプロパティをコマンドラインで設定することをお勧めします。

• 『Oracle Fusion Middleware Oracle WebLogic Server JAX-WS を使用した Web サービス入門』の「JWS プログラミングのベスト プラクティス」に従う。

• 基底のすべてのコンポーネントに関するベスト プラクティスやチューニングにおける推奨事項に従う。「WebLogic Server EJB のチューニング」、「Web アプリケーションのチューニング」、「JDBC アプリケーションのチューニング」、「WebLogic JMS のチューニング」などを参照してください。

Web サービスの信頼性のあるメッセージング エージェントのチューニング

Web サービスの信頼性のあるメッセージングには、ストア アンド フォワードという高度な機能があります。ストア アンド フォワード機能を使用すると、ローカル サーバ インスタンスからリモートの送り先に対して高パフォーマンスのメッセージ転送を行えます。『Oracle Fusion Middleware Oracle WebLogic Server ストア アンド フォワードのコンフィグレーションと管理』の「ストア アンド フォワード サービスについて」を参照してください。この節では、ストア アンド フォワード (SAF) アプリケーションから最高のパフォーマンスを引き出す方法について紹介します。

• 管理とチューニングを簡略化するため、JMS SAF と Web Services Reliable Messaging エージェントには別個の SAF エージェントをコンフィグレーションする。

• 永続性が必要なサブシステムでは、サブシステム間で同じ WebLogic ストアを共有するとパフォーマンスが向上する。たとえば、SAF および JMS 操作を含むトランザクション、複数の SAF 送り先を含むトランザクション、SAF および EJB を含むトランザクションなどがこれに当たります。「WebLogic 永続ストアのチューニング」を参照してください。

• リモートの SAF エージェントでは [ウィンドウ サイズ] パラメータ値の増加を検討する。1K より小さいメッセージでは、[ウィンドウ サイズ] を 300 程度にチューニングするとスループットが向上します。

  
  

  注意 : [ウィンドウ サイズ] では JMS SAF の動作もチューニングされるので、[両方] タイプの SAF エージェントでこのパラメータをチューニングするのは適切ではありません。

  
  

• [再試行の遅延] の設定を小さくしすぎないようにする。小さすぎると、不要な配信試行が生じる場合があります。

Web サービスのパフォーマンス改善のための負荷の大きいシステムのチューニング

非同期の要求と応答、信頼性のあるメッセージング、バッファリングなどの機能はすべて、最小のシステム リソースを使用して少ないクライアント数 (10 未満) に対応するように、あらかじめチューニングされています。多数のクライアントや大量のメッセージを処理する予定である場合は、追加の負荷に対応するためにチューニング パラメータを調整してください。

バッファリング セッションの設定

信頼性のあるメッセージングやバッファリングの機能では JMS キュー セッションを使用してメッセージを信頼性/バッファ キューに送信します。デフォルトでは、WebLogic Server はバッファリングに 10 個のセッションを割り当てるので、10 個のクライアントが同時に信頼性/バッファ キューにメッセージを入れることができます。

非同期の要求と応答の場合、通信のやり取りの要求部分と応答部分は別々に 2 つのクライアントとしてカウントされます。この場合、セッションのデフォルト プールは非同期の要求と応答のクライアントに同時に 5 つまで対応できます。アプリケーションで予期される同時クライアント数に対応するには、以下のパラメータを予期されるクライアント スレッド数の 2 倍に設定します。

-Dweblogic.wsee.buffer.QueueSessionPoolSize=size

非同期リソースの解放

非同期の要求と応答の機能を使用する場合、WebLogic Server は非同期応答がクライアントに返されるまで、その要求に関する情報を永続的に格納します。これらのリソースは、「ストア クリーナ」と呼ばれるバックグラウンドのスレッドによって解放されるまで、永続ストアに保持されます。

これらのリソースはより早く解放できる場合もあります。ストア クリーナを頻繁に実行すれば、永続ストアのサイズを削減して、クリーニングに要する時間を最小限に抑えることができます。

デフォルトでは、ストア クリーナは 2 分 (120000 ms) ごとに実行されます。以下の Java システム プロパティを使用して、ストア クリーナの間隔を 1 分 (60000 ms) に設定することをお勧めします。

-Dweblogic.wsee.StateCleanInterval=60000