| Oracle® Fusion Middleware Oracle WebLogic Serverのパフォーマンスのチューニング 12c (12.2.1.1.0) E77269-02 |
|
 前 |
 次 |
この章には次の項が含まれます:
設計およびアーキテクチャにおける決定は、実行時のパフォーマンスやWebサービス・アプリケーションのスケーラビリティに大きく影響します。ここでは、最高のパフォーマンスを得るために重要な推奨事項を紹介します。
Webサービス・アプリケーションは、推移的な性質を持ち適度なサイズのペイロードを伴うサービスについて設計します。
Webサービス・アプリケーションに対して正しいサービス形式とエンコーディングを選択します。
パフォーマンス向上のために、シリアライザのオーバーヘッドとネームスペース宣言を制御します。
SOAPメッセージのフォーマットを最適化するため、MTOM/XOPまたはFast Infosetを使用します。
パフォーマンスのオーバーヘッドを最小化するために、SOAP添付およびセキュリティを注意して設計します。
以下のようなアプリケーションでは、非同期のメッセージング・モデルの使用を検討します。
トランスポートが低速で信頼性に欠けます。
複雑で実行時間の長い処理を扱います。
トランザクション対応のサービス指向アーキテクチャ(SOA)の場合、パフォーマンスを向上させるにはロギング・ラスト・リソース(LLR)のトランザクションの最適化を使用することを検討します。「トランザクションのチューニング」を参照してください。
ネットワークのオーバーヘッドを最小限に抑えることでパフォーマンスを向上させるには、レプリケーション、データのキャッシング、およびスキーマ定義を使用します。
XML圧縮/圧縮解除のオーバーヘッドがネットワーク・オーバーヘッドより小さい場合のみ、XML圧縮手法を考慮します。
パーサーなど、XML機能を頻繁に使用するアプリケーションでは、パフォーマンスの問題が発生するか、記述子が足りなくなる場合があります。これは、jaxp.propertiesファイル(JAXP API)でルックアップを行うことによって、XMLパーサー・インスタンスがブート・ストラップされるために発生する場合があります。実行時に不要なファイル操作が行われないように、およびパフォーマンスやリソースの使用率が向上するように、このプロパティをコマンド行で設定することをお薦めします。
『Oracle WebLogic Server JAX-WS Webサービスの開発』のJWSプログラミング・ベスト・プラクティスに関する項に従います。
基底のすべてのコンポーネントに関するベスト・プラクティスやチューニングにおける推奨事項に従います。「WebLogic Server EJBのチューニング」、「Webアプリケーションのチューニング」、「データ・ソースのチューニング」、「WebLogic JMSのチューニング」などを参照してください。
Webサービスの信頼性のあるメッセージングでは、ローカル・サーバーのインスタンスからリモート宛先への高パフォーマンス・メッセージ転送のためにストア・アンド・フォワードの高度な機能が用意されています。『Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理』のストア・アンド・フォワード・サービスの理解に関する項を参照してください。次の項では、ストア・アンド・フォワード(SAF)アプリケーションでベストなパフォーマンスを得る方法について説明します。
管理とチューニングを簡略化するため、JMS SAFとWeb Services Reliable Messagingエージェントには別個のSAFエージェントを構成します。
永続性が必要なサブシステムでは、サブシステム間で同じWebLogicストアを共有するとパフォーマンスが向上します。たとえば、SAFおよびJMS操作を含むトランザクション、複数のSAF宛先を含むトランザクション、SAFおよびEJBを含むトランザクションなどがこれに当たります。「WebLogic永続ストアのチューニング」を参照してください。
リモートのSAFエージェントではWindowSizeパラメータ値の増加を検討します。1Kより小さいメッセージでは、「ウィンドウ・サイズ」を300程度にチューニングするとスループットが向上します。
注意:
「ウィンドウ・サイズ」ではJMS SAFの動作もチューニングされるので、「両方」タイプのSAFエージェントでこのパラメータをチューニングするのは適切ではありません。
「再試行の遅延」の設定を小さくしすぎないようにします。小さすぎると、不要な配信試行が生じる場合があります。
非同期のリクエストとレスポンス、信頼性のあるメッセージング、バッファリングなどの機能はすべて、最小のシステム・リソースを使用して少ないクライアント数(10未満)に対応するように、あらかじめチューニングされています。多数のクライアントや大量のメッセージを処理する予定である場合は、次の項に記載されているように、負荷の増大に対応できるようチューニング・パラメータを調整してください。
ワーク・マネージャを定義して、最低でもサービスへの同時リクエストまたはレスポンスの想定数と同じ値にスレッド・プール最小サイズ制約(min-threads-constraint)を設定します。
たとえば、Webサービス・クライアントが高速で連続して20個のリクエストを発行する場合、このクライアントをホストするアプリケーションの推奨されるスレッド・プール最小サイズ制約値は20です。構成されている制約値が小さすぎる場合、受信された処理で空き処理スレッドを待機するため、パフォーマンスが大幅に低下します。
スレッド・プール最小サイズ制約の詳細は、『Oracle WebLogic Serverサーバー環境の管理』の制約に関する項を参照してください。
信頼性のあるメッセージングやバッファリングの機能では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
