| Oracle® Fusion Middlewareパフォーマンスのチューニング・ガイド 12c (12.2.1.1) E77229-01 |
|
 前へ |
 次へ |
SOAフレームワーク内で、Oracle Service Bus (OSB)は、接続性、ルーティング、仲介、管理および一部のプロセス編成機能を提供します。OSBの設計理念は、高いパフォーマンスと2つ以上のアプリケーション間のステートレス(非永続状態)な中間機能を実現することです。ただし、SOA実装のスケールおよび機能の多様性により、OSBアプリケーションには、様々な使用パターン、メッセージ・サイズおよびQOS要件があります。
ほとんどのSOAデプロイメントで、OSBは、2つ以上のアプリケーション(サーバー)の中間機能の役割を果たす大規模なシステムの一部です。通常のOSB構成には、中間バックエンド・サービスの1つ以上のサービス・コールアウトを実行し、クライアントにレスポンスする前に宛先バックエンド・システムにリクエストをルーティングする可能性のあるOSBプロキシ・サービスを起動するクライアントが含まれます。
OSBが大規模なシステムの一部であり、チューニングの目的が全体のシステム・パフォーマンスの最適化であることを理解する必要があります。これには、スタンドアロン・アプリケーションとしてのOSBのチューニングだけではなく、OSBを使用した調整、リクエストのバッファリング、キャッシュ、優先順位付け、並列処理などのフロー制御パターンの実装が含まれます。
Oracle Service Busの詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』を参照してください。
Oracle Service Busパフォーマンスは、他のコンポーネントのパフォーマンスに大きく依存します。次のコンポーネントがOSBパラメータに影響を与えます。
WebLogic Server
Coherence
アダプタ
これらのコンポーネントが十分にチューニングされていることが確かな場合は、Oracle Service Busのチューニングを開始できます。
12c (12.2.1)から、Oracle Service BusはいくつかのOracle WebLogic Serverワーク・マネージャでチューニングできるようになりました。
たとえば、ワーク・マネージャを使用して分割-結合のチューニングを行うことができます。デフォルトでは、アプリケーションは分割-結合にワーク・マネージャを指定しませんが、パラレル・タスクのスケジュールなど、スレッドが満たす必要がある制約が厳しい場合は、分割-結合にワーク・マネージャを割り当てることができます。
最適なパフォーマンスを得るには、次のワーク・マネージャの制約のバランスを取ります。
min-threads-constraintは、分割-結合操作にスレッドが不足しないようにします。
max-threads-constraintは、分割-結合に他のリソースが不足しないようにします
デフォルトでは、最小または最大スレッド数の制約は定義されておらず、分割-結合操作が低下するか、同じスレッド・プールを共有する他の操作が低下する可能性があります。
ワーク・マネージャは、システム全体のプロセスにスレッドを割り当てるときに分割-結合操作を考慮に入れて、このバランスが自動的に取られるようにします。
ワーク・マネージャを使用したOSBのチューニングの詳細は、『Oracle Service Busでのサービスの開発』のOracle Service Busによるワーク・マネージャの使用に関する項を参照してください。
表19-1に、パフォーマンスの改善のために一般的にチューニングが必要であるノブを示します。障害のある領域を診断するためのOracle Service Busのモニタリングの詳細は、『Oracle Service Busの管理』のOracle Service Busのモニタリングに関する項を参照してください。
表19-1 重要なOSB操作のチューニング
| パラメータ | 問題点 | チューニングに関する推奨事項 | トレードオフ |
|---|---|---|---|
モニタリングおよびアラート デフォルト: |
モニタリングおよびアラートのフレームワークは、パフォーマンスに与える影響が最小になるように設計されていますが、これらのプロセスはすべてパフォーマンスに影響を与えます。 一般的に、定義したモニタリング・ルールおよびパイプライン・アクションが多いほど、パフォーマンスへの影響が大きくなります。 |
OSBレベルでデフォルトの モニタリングおよびアラートの設定は、Enterprise Manager管理者コンソールで構成できます。 モニタリングは、SLAアラートに対しては有効にできますが、パイプライン・アラートに対しては有効にできないことに注意してください。 |
パフォーマンスを改善するためにこれらのプロセスを無効にするということは、問題のトラブルシューティングで今後役立つ可能性のあるメトリックおよびアラートのいくつかを犠牲にすることを意味します。 OSBモニタリング・フレームワークの詳細は、『Oracle Service Busの管理』のOracle Service Busモニタリング・フレームワークの概要に関する項を参照してください。 |
トレース デフォルト: 無効 |
メッセージ・サイズが大きく、高スループットのシナリオがある場合、トレースはシステムを低下させる可能性があります。 |
パフォーマンスを改善するためにトレースを無効のままにします。 詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のトレースを有効または無効にする方法に関する項を参照してください。 |
無効にすると、メトリックが失われます。 トレースは、ヘッダーおよびメッセージ本文を含めて、メッセージ・コンテキスト全体を出力します。これは、1つ以上のプロキシ・サービスのメッセージ・フローを含む問題のデバッグ、診断およびトラブルシューティングを行う開発および本番環境に非常に便利な機能です。 |
com.bea.wli.sb.pipeline. RouterRuntimeCache.size デフォルト: 100 |
次のいずれかの問題が発生する可能性があります。 プロキシ・サービスのアクセスが遅くなっています。これは、パイプライン・サービス・ランタイム・メタデータ用のOSBキャッシュの静的な部分に格納するプロキシ・サービスを増やすことを意味します。ここに格納されたプロキシ・サービスはガベージ・コレクションされることがないため、アクセスが早くなります。 または DMSダンプで多数のキャッシュ・ミスが検出されます。 |
静的キャッシュに含むプロキシ・サービス数を増やす場合、多数のプロキシ・サービスに対するランタイム・データ処理のメモリーが十分あるかぎり、この値を大きくします。 DMSダンプでキャッシュ・ミスが検出される場合、この値を小さくします。 このシステム・プロパティは、パイプライン・サービス・ランタイム・メタデータ用のOSBキャッシュの静的な部分にあるプロキシ・サービスの数を制限します。これらのサービスはガベージ・コレクションされません。 次に示すように、追加のJava引数としてこの値のサイズをsetDomainEnv.shファイルに設定します。 -Dcom.bea.wli.sb.pipeline.RouterRuntimeCache.size={size}
たとえば、この値を3000に設定する場合、次のようにします。 EXTRA_JAVA_PROPERTIES=
"-Dcom.bea.wli.sb.pipeline.
RouterRuntimeCache.size=3000
${EXTRA_JAVA_PROPERTIES}"
|
この値を大きくすると、プロキシ・サーバーへの初期コールに要する時間が短縮されます。また、構成セッションがコミットされる際に、キャッシュを事前ロードすることもできます。ただし、プロキシ・サービスをキャッシュするとコンパイル・コストが下がりますが、メモリー消費量は増加します。 この値を小さくすることはメモリーの解放を意味しますが、プロキシ・サーバーへの初期コールに要する時間が長くなる場合があります。 |
デフォルト: False |
RESTサービスへのJSON入力が、スキーマ定義で予想された順序ではありません。 JSONからXMLに変換するとき、OSBランタイムは、対応するXML要素を構成するためにJSONの名前/値が表示される順序を使用します。整形式ですが、この形式はXMLスキーマによると有効ではありません。 |
RESTウィザードを実行して最初のページのボックスを選択することによって、このパラメータを このオプションを選択すると、RESTサービスによって入力JSONの順序が変更され、外部RESTエンドポイントからのレスポンスを、有効なスキーマ定義に従った順序にすることができます。 |
このオプションを使用すると、大量のパフォーマンス・オーバーヘッドが追加されます。 |
推奨されている変更を行った後、デプロイメントに固有の変更をさらに追加できます。その他のチューニングの推奨事項は、ご使用の環境に適しているかどうか慎重に検討してください。
リシーケンサは、関連性はあるが順序が正しくないメッセージのストリームを再配置して順序どおりに戻すために使用します。ランダムな順序で届く着信メッセージを順序付けし、ターゲット・サービスに正しい順序で送信します。
表19-2に示すプロパティを、OSB EMコンソールのグローバル操作設定ページを使用して設定することによって、リシーケンサを細かくチューニングできます。
表19-2 重要なリシーケンサ・チューニング
| パラメータ | 問題点 | チューニングに関する推奨事項 | トレードオフ |
|---|---|---|---|
ResequencerMaxGroupsLocked デフォルト: 4グループ |
このパラメータは、パラレル処理に対してリシーケンサ・ロッカー・スレッドでロックできるメッセージ・グループの最大数を定義します。ロックされたグループはワーカー・スレッドを使用してそれぞれのメッセージを処理できます。 メッセージ処理が遅延する場合、次のどの状況であるか特定します。
|
多くのグループがあり、それぞれのメッセージ数が少ない場合、このパラメータの値を大きくします。リシーケンサは1回の反復でより多くのグループをロックします。 グループが少なく、メッセージ数が多い場合、この値を小さくします。リシーケンサが処理のためにロックするグループ数が少なくなります。 |
デフォルト値を小さくすると、リソースの使用率が下がります。 |
ResequencerLockerThreadSleep デフォルト: 10秒 |
リシーケンサ・ロッカー・スレッドは、パラレル処理に対してグループをロックするためにデータベースに問い合せます。使用可能なグループがない場合、ロッカー・スレッドは、このパラメータで指定された時間スリープします。 次のいずれかの状況の場合は、このパラメータのチューニングが必要です。
|
メッセージ数が多い場合、このパラメータ値を小さくして処理中のタイム・ラグを短縮します。 着信メッセージが少ないのにリシーケンサ・ロッカー・スレッドが頻繁にデータベース・ラウンドトリップを行う場合は、この値を大きくします。 |
スリープ時間が短すぎる場合、ロックされたグループの着信メッセージの処理に使用できるワーカー・スレッドが十分ではないことがあります。データベース問合せが多すぎる場合もパフォーマンスが低下します。 着信メッセージの間隔がすでに長い場合は、値を大きくすることは有益ではありません。 |
DeleteMessageAfterComplete デフォルト: |
リシーケンサ・データベースの領域が少なくなっています。このパラメータの値をfalseに変更した場合、処理されたメッセージがリシーケンサ・データベースにとどまり、データベース照会を遅くします。 |
デフォルト値の |
処理されたメッセージの詳細履歴がなくなります。 |
OSBの使用およびユースケース・シナリオに基づいて、プロキシ・アプリケーションの表19-3に示した設計の構成を検討してください。
表19-3 プロキシ・アプリケーションの設計時のチューニング
| 戦略 | 説明 | 推奨事項 |
|---|---|---|
別のXQueryで一度だけ使用される多くのOSBコンテキスト変数の作成を回避します。 |
割当てアクションを使用して作成されるコンテキスト変数は、XmlBeansに変換され、次のXQueryの固有のXQuery形式に戻されます。 |
冗長なコンテキスト変数の作成を回避すると、内部データ形式変換に関連するオーバーヘッドがなくなります。この利点とコードの可視性および変数の再利用でバランスをとる必要があります。 |
|
コンテキスト変数の内容の変換は、時間がかかる場合があります。 |
1つの手順で変換を完了するには、置換アクションを使用します。 $bodyの全体の内容を置換する場合、XPathフィールドを空のままにして、「ノードのコンテンツを置換」を選択します。これは、$body($body/Orderなど)の子ノードを参照して「ノード全体を置換」を選択するよりも高速です。 XPathフィールドを空のままにすると、余分なXQuery評価が排除されます。 |
特別なXPathを指定します。 |
主な変換リソースを実行する前に、 |
変換(XQuery/XSLT)リソースへの入力として、 これは、 |
純粋なコンテンツベースのルーティング・シナリオのストリーミングを有効にします。 |
OSBは、索引付けされたXPathと組み合せてストリーミングを使用する場合にXQueryエンジンの部分解析機能を利用します。このため、 詳細は、XQueryのチューニングを参照してください。 |
ストリーミングを有効にするということは、XPathで参照するフィールドにのみペイロードが解析されて処理されることを意味します。ストリーミングはまた、XmlBeansの解析およびシリアライズに関連するオーバーヘッドを排除します。 トレードオフ: 複数のフィールドを読み込むために何度もペイロードにアクセスする場合、ストリーミングの増加を無効にできます。すべてのフィールドの読込みがXMLドキュメントの1つのサブセクションの場合、ハイブリッド方法で最適なパフォーマンスを実現します。 変換の出力は、メモリーまたはディスクに圧縮されたバッファ形式で格納されます。そのため、メモリー不足の問題がない場合はストリーミングを回避する必要があります。 |
適切なQOSレベル設定およびトランザクション設定を実行します。 |
OSBは、QOSが「ベスト・エフォート」の場合にバックエンドHTTPサービスを非同期に起動できます。非同期呼出しにより、OSBは長時間実行するバックエンド・サービスのスケーラビリティを向上できます。また、HTTPでの公開を忠実に一方向に実行できます。 |
必要な信頼性レベルが1回および1回のみで、その設定を使用できる場合(クライアントがHTTPクライアントの場合は使用できません)を除いて、XAまたは「必ず1回」を設定しないでください。OSBがトランザクションを開始すれば、XAをLLRに置換して同じレベルの信頼性を実現できます。 |
すべてのログ・アクションを無効化または削除します。 |
ログ・アクションにより、I/Oオーバーヘッドが追加されます。ロギングには、高負荷になる可能性があるXQuery評価も含まれます。1つのデバイス(リソースまたはディレクトリ)に書き込むと、ロック競合が発生する可能性もあります。 |
すべてのログ・アクションを無効化または削除します。 |
OSBは、割当て、置換、ルーティング表などの様々なアクションに幅広くXQueryおよびXPathを使用します。次のXML構造($body)を使用して、XQueryおよびXPathチューニングの概念を説明します。
<soap-env:Body> <Order> <CtrlArea> <CustName>Mary</CustName> </CtrlArea> <ItemList> <Item name="ACE_Car" >20000 </Item> <Item name=" Ext_Warranty" >1500</Item> …. a large number of items </ItemList> <Summary> <Total>70000</Total> <Status>Shipped</Status> <Shipping>My Shipping Firm </Shipping> </Summary> </Order> </soap-env:Body>
表19-4に示すチューニング戦略を使用して、XQueryをチューニングできます。
表19-4 XQueryのチューニング戦略
| 戦略 | 説明 | 推奨事項 |
|---|---|---|
XPathの先頭の2つのスラッシュ(「//」)の使用を回避します。 |
"//"は、XMLツリー内の場所に関係なくノードのすべての発生を示します。そのため、「//」の後に指定したパターンでXMLツリーの全体の深さおよび範囲を検索する必要があります。 |
設計時にノードの正確な場所がわからない場合のみ、「//」を使用してください。 |
該当する場合、XPathを索引付けします。 |
索引付けは、システムが必要なものだけを処理する場合に役立ちます。索引付けを行うとき、XQueryエンジンによってドキュメントの最初の部分のみが処理されます。 |
パスの各ノードの後に"[1]"を追加して、XPathを索引付けします。 たとえば、XPath しかし、 注意: ノードの配列全体を戻す必要がある場合は、索引付けしないでください。索引付けは、配列の最初の項目ノードのみを戻します。 |
FLWOR式内の中間変数として、大きいXMLドキュメントの頻繁に使用する部分を抽出します。 |
中間変数を使用して、複数の値の共通のコンテキストを格納できます。 |
中間変数の使用はメモリーを多く消費しますが、冗長なXPath処理を削減します。 |
ストリーミングを使用した読取り専用シナリオにハイブリッド方法を使用します。 |
複数のフィールドを読み込むために何度もペイロードにアクセスする場合、ストリーミングの増加を無効にできます。すべてのフィールドの読込みがXMLドキュメントの1つのサブセクションの場合、ハイブリッド方法で最適なパフォーマンスを実現します。 |
プロキシ・レベルでのストリーミングおよびコンテキスト変数への関連サブセクションの割当を有効にします。このコンテキスト変数から、個々のフィールドにアクセスできるようになります。 3つの Assign "$body/Order[1]/Summary[1]" to "foo" Assign "$foo/Total" to "total" Assign "$foo/Status" to "total" |
注意:
コンテンツのストリーミングに有効なパイプラインは、"XQuery 1.0"を使用する必要があります。"XQuery 2004"の使用も機能しますが、XQuery 1.0エンジンとの間で発生するオンザフライ変換があるため、大きなパフォーマンス・オーバーヘッドが発生します。その影響に対する設計時の警告があります。
ポーラーベースのトランスポートの待機時間およびスループットは、ソースがポーリングされる頻度およびポーリング・スイープごとに読み込まれるファイルとメッセージの数によって異なります。
メッセージ・サイズが大きすぎず、CPUが飽和していない高いスループットのシナリオに短いポーリング間隔を使用することを検討してください。追加情報のリンクとともに主なポーリング間隔のデフォルトを次に示します。
| ポーリング間隔 | デフォルトの間隔 | 追加情報 |
|---|---|---|
ファイル・トランスポート |
60秒 |
『Oracle Service Busでのサービスの開発』のファイル・トランスポート構成に関するページ |
FTPトランスポート |
60秒 |
『Oracle Service Busでのサービスの開発』のFTPトランスポート構成に関するページ |
MQトランスポート |
1000ミリ秒 |
『Oracle Service Busでのサービスの開発』のMQトランスポート構成に関するページ |
SFTPトランスポート |
60秒 |
『Oracle Service Busでのサービスの開発』のSFTPトランスポート構成に関するページ |
JCAトランスポート |
60秒 |
『Oracle Service Busでのサービスの開発』のJCAトランスポート構成に関するページ |
読取り制限は、ポーリング・スイープごとに読み込まれるファイルまたはメッセージの数を決定します。表19-5の情報を使用してこれをチューニングできます。
詳細は、『Oracle Service Busでのサービスの開発』のファイル・トランスポートの使用に関する項を参照してください。
表19-5 重要な読取り制限のチューニング
| パラメータ | 適切にチューニングされていない場合の症状 | チューニングに関する推奨事項 | パフォーマンスのトレードオフ |
|---|---|---|---|
読取り制限 デフォルト: ファイル・トランスポートおよびFTPトランスポートに対して10 |
同時にメモリーに読み取られるファイル数が多い場合、メモリー使用量が過度になったり多くなります。 |
この値を任意の同時実行性に設定してください。0を設定して無制限を指定できます。 読取り制限は、ポーリング・スイープごとに読み込まれるファイルまたはメッセージの数を決定します。 |
読取り制限を高い値、ポーリング間隔を小さい値に設定すると、多くのメッセージがメモリーに同時に読み込まれる場合があります。メッセージ・サイズが大きい場合、メモリー不足エラーが発生する可能性があります。 |
