| Oracle® Fusion Middlewareパフォーマンスおよびチューニング・ガイド 11g リリース1 (11.1.1) B61006-10 |
|
 前 |
 次 |
この章では、Oracle Service Busのパフォーマンスをチューニングする方法について説明します。内容は次のとおりです。
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 Fusion Middleware Oracle Service Bus管理者ガイド』のプロキシ・サービスの操作設定の構成に関する項またはビジネス・サービスの操作設定の構成に関する項を参照してください。
個々に監視を有効化または無効化しているすべてのサービスの監視を有効または無効にするには、「操作のグローバル設定」ページの「モニターの有効化」オプションを使用します。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のグローバル設定の有効化に関する項を参照してください。
OSBの使用状況およびパフォーマンスの問題に応じて、次の点をチューニングすることを検討してください。
その他すべてのOracle Fusion Middlewareコンポーネントと同様に、OSBのパフォーマンスはJVMパラメータの影響を受けます。OSBのパフォーマンスを最適化する場合に検討する2つの主なJVMチューニング・パラメータは、ヒープ・サイズとガベージ・コレクションです。JVMのパフォーマンス・チューニングの詳細は、第2.4項「Java仮想マシン(JVM)のチューニング」を参照してください。
OSBを最適化するには、次のWebLogic Serverパラメータのチューニングを検討してください。
本番環境では、「本番」モードのドメインを作成して、パフォーマンスを最大化します。パラメータは次のとおりです。
-Dweblogic.ProductionModeEnabled=true
WebLogic管理コンソールを使用してWebLogic Server本番モードを有効にするには、『Oracle Fusion Middleware Oracle WebLogic Serverドメイン構成の理解』を参照してください。
OSBパフォーマンスのテストおよび本番環境では、できるだけ「エラー」や「警告」などの許容されている最も低いロギング・レベルを使用することを検討してください。詳細は、第2.10項「ロギング・レベルの設定」を参照してください。
OSBパフォーマンスを最適化するには、HTTPアクセス・ロギングをオフにすることを検討してください。詳細は、第6.3.3.1項「アクセス・ロギング」を参照してください。
適切な永続性レベルがJava Message Service (JMS)の宛先に設定されていることを確認します。次のシナリオを検討してください。
非永続JMSシナリオの場合
WebLogic ServerコンソールのJMSサーバーの「一般」タブの「詳細」セクションから「ストアの有効化」フラグの選択を解除して、JMSサーバー・レベルの永続性を明示的にオフにします。また、JMS宛先レベルの永続モードをオーバーライドできます。
永続JMSシナリオの場合
ファイル・ストアとJDBCストアの2つの選択肢があります。通常、ファイル・ストアの操作は、JDBCストアよりもパフォーマンスが高くなります。複数のJMSサーバーが含まれる場合、個別のディスクに各ストアを作成して、I/Oの競合を少なくします。
JMSサーバー・チューニングの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング』のWebLogic JMSのチューニングに関する項を参照してください。
追加のリクエストを拒否する前にWebLogic Serverインスタンスが受け入れる接続リクエストの数をチューニングできます。「バックログの受入れ」パラメータには、待機キューにバッファリングできるTransmission Control Protocol (TCP)接続の数を指定します。この固定サイズのキューにTCPスタックが受け取った接続のリクエストが移入されますが、アプリケーションでまだ承認されていません。多くの同時クライアントを処理する場合には、このパラメータをチューニングする必要があります。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング』の接続バックログのバッファリングのチューニングに関する項を参照してください。
この項では、次のOracle Service Bus操作設定について説明します。
Oracle Service Busには、サーバーを停止しないでメッセージをトレースするオプションがあります。これは、1つ以上のプロキシ・サービスのメッセージ・フローを含む問題のデバッグ、診断およびトラブルシューティングを行う開発および本番環境に非常に便利な機能です。
デフォルトのトレースは無効ですが、サービスごとに有効にできます。トレースを有効にすると、ヘッダーおよびメッセージ本文を含む全体のメッセージ・コンテキストも出力されます。大きいメッセージ・サイズおよび高いスループットのシナリオの影響を把握することが重要です。
詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のトレースを有効または無効にする方法に関する項を参照してください。
OSBは、静的および動的セクションの2つのレベルのキャッシュを使用して、プロキシ・サービスの実行時メタデータをキャッシュします。このキャッシュにより、メモリー使用量およびコンパイル・コストのパフォーマンスのトレードオフが導入されます。プロキシ・サービスのキャッシュによってスループットが高くなる場合がありますが、メモリーの使用に影響を与える可能性があります。
静的セクションは、ガベージ・コレクションが実行されない上限のLeast Recently Used (LRU)キャッシュです。プロキシ・サービスが静的セクションから除外される場合、メモリーの不足時にキャッシュのガベージ・コレクションを実行できる動的セクションに降格されます。
システム・プロパティcom.bea.wli.sb.pipeline.RouterRuntimeCache.sizeでサイズを設定して、キャッシュの静的部分のプロキシ・サービスの数をチューニングできます。デフォルト値は100です。多くのプロキシ・サービスの実行時データ処理に十分なメモリーがある場合は、任意の値に増やすことができます。
次に示すように、追加のJava引数としてこのプロパティ値をsetDomainEnv.shファイルに設定できます。
-Dcom.bea.wli.sb.pipeline.RouterRuntimeCache.size={size}
例:
EXTRA_JAVA_PROPERTIES="-Dcom.bea.wli.sb.pipeline.RouterRuntimeCache.size=3000 ${EXTRA_JAVA_PROPERTIES}"
プロキシ・サービスのコンパイル済ランタイムとともにルーター実行時キャッシュを事前にロードするには、システム・プロパティcom.bea.wli.sb.pipeline.RouterRuntimeCache.preloadをtrueに設定します。
EXTRA_JAVA_PROPERTIES="-Dcom.bea.wli.sb.pipeline.RouterRuntimeCache.preload=true
このプロパティを有効化すると、プロキシ・サーバーへの初期コールにかかる時間が短縮され、パフォーマンスが向上する場合があります。また、構成セッションがコミットされる際に、キャッシュを事前ロードすることもできます。
プロキシ・サービスの数が100を超えた場合は、キャッシュ・サイズは限られているため、com.bea.wli.sb.pipeline.RouterRuntimeCache.sizepropertyを使用して適切なキャッシュ・サイズに設定する必要があります。
前の項で推奨されている変更を行った後、デプロイメントに固有の変更をさらに行うことができます。この項の推奨事項は、ご使用の環境に適しているかどうか慎重に検討してください。
ポーラーベースのトランスポートの待機時間およびスループットは、ソースがポーリングされる頻度およびポーリング・スイープごとに読み込まれるファイルとメッセージの数によって異なります。
次に、チューニングする主なトランスポート構成を示します。
メッセージ・サイズが大きすぎず、CPUが飽和していない高いスループットのシナリオに短いポーリング間隔を使用することを検討してください。追加情報のリンクとともに主なポーリング間隔のデフォルトを次に示します。
| ポーリング間隔 | デフォルトの間隔 | 追加情報 |
|---|---|---|
|
ファイル・トランスポート |
60秒 |
『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のファイル・トランスポート構成ページに関する項 |
|
FTPトランスポート |
60秒 |
『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のFTPトランスポート構成ページに関する項 |
|
MQトランスポート |
1000ミリ秒 |
『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のMQトランスポート構成ページに関する項 |
|
SFTPトランスポート |
60秒 |
『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のSFTPトランスポート構成ページに関する項 |
|
JCAトランスポート |
60秒 |
『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のJCAトランスポート構成ページに関する項 第18.3.1項「JCAアダプタのチューニングに関する基本的な考慮事項」も参照してください。 |
読取り制限は、ポーリング・スイープごとに読み込まれるファイルまたはメッセージの数を決定します。ファイルおよびFTPトランスポートに使用されるこのデフォルトは10です。0を設定して無制限を指定できます。この値を任意の同時実行性に設定してください。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のファイル・トランスポート構成ページに関する項を参照してください。
|
注意: 読取り制限を高い値、ポーリング間隔を小さい値に設定すると、多くのメッセージがメモリーに同時に読み込まれる場合があります。メッセージ・サイズが大きい場合、OOM(メモリー不足エラー)が発生する可能性があります。 |
OSBの使用およびユースケース・シナリオに基づいて、プロキシ・アプリケーションの次の設計の構成を検討してください。
別のXQueryで一度だけ使用される多くのOSBコンテキスト変数の作成を回避します。
割当てアクションを使用して作成されるコンテキスト変数は、XmlBeansに変換され、次のXQueryの固有のXQuery形式に戻されます。FLWOR式を使用すると、複数の「割当て」アクションを1つの割当てアクションに縮小できます。「let」文を使用して中間値を作成できます。冗長なコンテキスト変数の作成を回避すると、内部データ形式変換に関連するオーバーヘッドがなくなります。この利点とコードの可視性および変数の再利用でバランスをとる必要があります。
$bodyなどのコンテキスト変数の内容を変換します。
1つの手順で変換を完了するには、置換アクションを使用します。$bodyの全体の内容を置換する場合、XPathフィールドを空のままにして、「ノードのコンテンツを置換」を選択します。これは、$body($body/Orderなど)の子ノードを参照して「ノード全体を置換」を選択するよりも高速です。XPathフィールドを空のままにすると、余分なXQuery評価が排除されます。
変換(XQuery/XSLT)リソースへの入力として、$body/*[1]を使用して$bodyの内容を表します。
OSBは、XQueryエンジンを起動しないで評価できる特別なXPathとして$body/*[1]を処理します。これは、$bodyの子を参照する絶対パスを指定するよりも高速になります。主な変換リソースを実行する前に、$body/Orderなどの一般的なXPathをXQueryエンジンで評価する必要があります。
純粋なコンテンツベースのルーティング・シナリオのストリーミングを有効にします。
コンテンツベースのルーティングなどの読取り専用シナリオでは、ストリーミングの有効化でパフォーマンスを向上できます。OSBは、索引付けされたXPathと組み合せてストリーミングを使用する場合にXQueryエンジンの部分解析機能を利用します。そのため、XPathで参照されるフィールドのみ、ペイロードが解析および処理されます。部分解析以外の読取り専用シナリオの利点は、ストリーミングによってXmlBeansの解析およびシリアライズに関連するオーバーヘッドがなくなることです。
複数のフィールドを読み込むために何度もペイロードにアクセスする場合、ストリーミングの増加を無効にできます。すべてのフィールドの読込みがXMLドキュメントの1つのサブセクションの場合、ハイブリッド方法で最適なパフォーマンスを実現します。詳細は、第21.4.3項「XQueryチューニングの設計の考慮事項」を参照してください。
変換の出力は、メモリーまたはディスクに圧縮されたバッファ形式で格納されます。そのため、メモリー不足の問題がない場合はストリーミングを回避する必要があります。
適切なQOSレベル設定およびトランザクション設定を実行します。
必要な信頼性レベルが1回および1回のみで、その設定を使用できる場合(クライアントがHTTPクライアントの場合は使用できません)を除いて、XAまたは「必ず1回」を設定しないでください。OSBがトランザクションを開始すれば、XAをLLRに置換して同じレベルの信頼性を実現できます。
OSBは、QOSが「ベスト・エフォート」の場合にバックエンドHTTPサービスを非同期に起動できます。非同期呼出しにより、OSBは長時間実行するバックエンド・サービスのスケーラビリティを向上できます。また、HTTPでの公開を忠実に一方向に実行できます。
すべてのログ・アクションを無効化または削除します。
ログ・アクションにより、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>
XPathの先頭の2つのスラッシュ(「//」)の使用を回避します。
$body//CustNameは$body/Order/CtrlArea/CustNameと同じ値を戻しますが、後者の式よりもパフォーマンスが大幅に低下します。「//」は、XMLツリーの場所に関係なくノードのすべての発生を示します。そのため、「//」の後に指定したパターンでXMLツリーの全体の深さおよび範囲を検索する必要があります。設計時にノードの正確な場所がわからない場合のみ、「//」を使用してください。
該当する場合、XPathを索引付けします。
パスの各ノードの後に[1]を追加して、XPathを索引付けできます。XQueryは宣言型言語で、XPathは複数のノードを戻すことができます。つまり、ノードの配列を戻すことができます。$body/Order/CtrlArea/CustNameは、$bodyの下のOrderのすべてのインスタンスとOrderの下のCtrlAreaのすべてのインスタンスを戻すことを示します。そのため、前述のXPathを適切に処理するには、ドキュメント全体を読み込む必要があります。$bodyの下にOrderの1つのインスタンス、Orderの下にCtrlAreaの1つのインスタンスが存在する場合、前述のXPathを$body/Order[1]/CtrlArea[1]/CustName[1]と書き換えることができます。
2番目のXPathは、子ノードの最初のインスタンスを戻すことを意味します。そのため、ドキュメントの上部だけをXQueryエンジンで処理してパフォーマンスを改善する必要があります。索引付けは、必要な内容のみの処理に重要です。
|
注意: 予想される戻り値がノードの配列の場合、索引付けを使用しないでください。たとえば、 |
FLWOR式内の中間変数として、大きいXMLドキュメントの頻繁に使用する部分を抽出します。
中間変数を使用して、複数の値の共通のコンテキストを格納できます。共通のコンテキストを使用したサンプルのXPathは、次のとおりです。
$body/Order[1]/Summary[1]/Total, $body/Order[1]/Summary[1]/Status,$body/Order[1]/Summary[1]/Shipping
前述のXPathを変更して、中間変数を使用できます。
let $summary := $body/Order[1]/Summary[1] $summary/Total, $ summary/Status, $summary/Shipping
中間変数の使用はメモリーを多く消費しますが、冗長なXPath処理を削減します。
ストリーミングを使用した読取り専用シナリオにハイブリッド方法を使用します。
複数のフィールドを読み込むために何度もペイロードにアクセスする場合、ストリーミングの増加を無効にできます。すべてのフィールドの読込みがXMLドキュメントの1つのサブセクションの場合、ハイブリッド方法で最適なパフォーマンスを実現します。ハイブリッド方法には、プロキシ・レベルのストリーミングの有効化およびコンテキスト変数への関連するサブセクションの割当てが含まれます。このコンテキスト変数から個々のフィールドにアクセスできます。
3つの割当てアクションを使用して、「合計」および「ステータス」フィールドを取得できます。
Assign "$body/Order[1]/Summary[1]" to "foo" Assign "$foo/Total" to "total" Assign "$foo/Status" to "total"
