| Oracle® Fusion Middlewareパフォーマンスおよびチューニング・ガイド 11g リリース1 (11.1.1) B61006-10 |
|
 前 |
 次 |
この章では、Oracleアダプタをチューニングして最適なパフォーマンスを得る方法について説明します。Oracle SOA SuiteアプリケーションのコンポーネントであるOracleアダプタは、データへの統一的な視点を提供し、複数のアプリケーションの統合を可能にします。
この章の内容は次のとおりです。
Oracleテクノロジ・アダプタは、Oracle Application ServerおよびOracle Fusion Middlewareのコンポーネント(Oracle BPEL Process Manager (Oracle BPEL PM)やOracle Mediatorのコンポーネントなど)をファイルシステム、FTPサーバー、データベース・キュー(アドバンスト・キュー(AQ))、Java Message Services (JMS)、データベース表およびメッセージ・キュー(MQ Series)に統合します。
Oracleアダプタの詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』を参照してください。
この項では、Oracleファイル/FTPアダプタのスケーラビリティおよびパフォーマンスをチューニングする際に使用できる様々な機能について説明します。Oracleファイル/FTPアダプタには、インバウンド操作およびアウトバウンド操作を調整するためのパラメータが用意されています。また、アウトバウンド操作のパフォーマンス・チューニングに使用できるパラメータもあります。Oracleファイル/FTPアダプタのパラメータについては、次の項で説明します。
|
注意: Oracleファイル/FTPアダプタを使用するコンポジットが大量の同時メッセージを消費するよう設計されている場合は、オペレーティング・システムのオープン・ファイル数パラメータを大きな値に設定する必要があります。たとえば、Linuxのオープン・ファイル数パラメータを8192に設定するには、 |
Oracleファイル/FTPアダプタには、インバウンド操作の調整に使用できるパラメータが用意されています。次の表で、インバウンド調整の方法について説明します。
| パラメータ | タイプ | 値 | 説明 |
|---|---|---|---|
|
|
JCA |
デフォルト: 10000 |
このパラメータでは、インバウンド・アダプタが各ポーリング・サイクルで処理のために発行するファイルの最大数を定義します。たとえば、インバウンド・ディレクトリに1000個のファイルがあり、 インバウンドJCAファイルで定義します。 |
|
|
JCA |
デフォルト: False(この場合、グローバル・メモリー内キューが使用されます)。 |
値が インバウンドJCAファイルで定義します。 |
|
|
JCA |
デフォルト: -1(この場合、グローバル・スレッド・プールおよびグローバル・メモリー内キューが使用されます)。 |
このパラメータを指定した場合、Oracleファイル/FTPアダプタは、エンキューされたファイルを処理する際に、プロセッサ・ワーカー・スレッドのグローバル・プールを使用せず、専用のプロセッサ・スレッドを作成します。また、メモリー内キューが分割され、各コンポジット・アプリケーションが専用のメモリー内キューを取得します。
インバウンドJCAファイルで定義します。 |
|
|
このパラメータにより、ファイル・コンテンツを指定された数のバッチに分割できます。デバッチング・プロセスにより、メッセージの受信側にとってメッセージ・サイズが大きい場合に、パフォーマンスを向上させることができます。デバッチングにより、より少ないデータでより多くのインスタンスを作成できます。 |
Oracleファイル/FTPアダプタには、アウトバウンド操作の調整に使用できるパラメータが用意されています。次の表で、アウトバウンド調整の方法について説明します。
| パラメータ | タイプ | 値 | 説明 |
|---|---|---|---|
|
|
JCA |
デフォルト: 20(この場合、特定のアウトバウンド・シナリオで発生するトランスレーションは20回までです。) |
このパラメータには、特定のアウトバウンド・シナリオで並行して開始できるトランスレーション・アクティビティの最大数を指定します。アウトバウンド操作中のトランスレーション・ステップはCPUへの負荷が高く、他のアプリケーションやスレッドが停止する原因となるため、監視する必要があります。最大値は100です。 アウトバウンドJCAファイルで定義します。 |
Oracleファイル/FTPアダプタには、アウトバウンド操作のパフォーマンス・チューニングに使用できるパラメータが用意されています。次の表で、アウトバウンド・パフォーマンス・パラメータについて説明します。
| パラメータ | タイプ | 値 | 説明 |
|---|---|---|---|
|
|
JCA |
デフォルト: True |
このパラメータがtrueに設定されている場合、アウトバウンドのOracleファイル/FTPアダプタは、トランスレーションを行ったデータをステージング・ファイルに書き込み、そのステージング・ファイルを後からターゲット・ファイルにストリーミングします。このパラメータがfalseに設定されている場合、アウトバウンドのOracleファイル/FTPアダプタは、中間ステージング・ファイルを使用しません。 アウトバウンドJCAファイルで定義します。 |
|
|
エンドポイント・プロパティ |
デフォルト:
|
Trueの場合、トランスレーション・ステップはセマフォを使用してシリアライズされます。セマフォ(トランスレーション・ステップを監視)の許可数は、 Falseの場合、トランスレーション・ステップはセマフォ外で行われます。 composite.xmlで参照できるように |
|
|
バインディング・プロパティ |
デフォルト: False |
このパラメータは、 Trueの場合、トランスレーション・ステップはメモリー内で行われます(つまり、メモリー内バイト配列が作成されます)。 Falseの場合、アダプタはターゲット・ファイル(FTP、FTPSおよびSFTPを含む)への出力ストリームを作成し、トランスレータにストリームのトランスレーションおよびストリームへの直接書込みを許可します。 composite.xmlで参照できるように |
Oracleデータベース・アダプタは事前構成済であり、様々な点でパフォーマンスが最適化されています。ただし、次の項で説明する変更を加えれば、データベースへのラウンドトリップの回数を減らすことができます。
|
注意: この章であげているチューニングの考慮事項は、単なる例です。チューニング・パラメータはデプロイメントごとに異なります。現在の使用状況およびパフォーマンスの問題を確認し、パフォーマンスの向上につながるチューニングの考慮事項はどれかを判断してください。 |
アダプタのパフォーマンスは、データベースへのラウンドトリップの回数、および各トリップのネットワーク・コストに直接関係しています。パフォーマンスが問題になっており、デプロイメントに変更を加えてもよい場合は、次のパラメータをチューニングすることを検討してください。
索引の使用
索引を使用すると、選択、更新および削除のパフォーマンスが向上します。ポーリングの際には、主キーやLogicalDeletePollingStrategyのMarkReadFieldなど、問合せの対象となるすべてのフィールドに索引を付けます。MarkReadFieldには、NULL以外のMarkUnreadValueを指定します。注意: NULL値を多数含む列に索引を作成すると、全表スキャンに戻ってしまう可能性があります。
OptimizeMergeの無効化
OptimizeMergeパラメータを使用すると、値が指定されていないXML要素を検出できます。関連する列は、挿入および更新から除外されます。このパラメータを無効にすると、通常はパフォーマンスが向上しますが、悪影響が生じるケースもあります。複数の行が単一のXMLとして渡され、各行が異なる列セット(ユーザーが多数のオプション・フィールドを指定して入力)を持つ場合は、挿入や更新がそれぞれ異なるため、バッチ書込みの利点は得られません。
MaxRaiseSizeの増加
MaxRaiseSizeパラメータは、BPELエンジンへ一度に発行できるXMLレコードの最大数を示します。たとえば、MaxRaiseSize = 10と設定すると、10個のデータベース・レコードが同時に発行されます。インバウンド読取りでは、たとえばMaxRaiseSize = 0(バインドなし)と設定すると、1000行を読み取った場合に1000個の要素を持つXMLを1つ作成できます。これらの要素は、単一のOracle BPEL Process Managerインスタンスを通じて渡されます。その後、アウトバウンド側のマージで1000個すべてが1つのグループにまとめられ、バッチ書込みによってすべて一度で書き込まれます。大きなペイロードをパブリッシュする際には、MaxRaiseSizeパラメータを使用します。
MaxTransactionSizeの増加
このプロパティは、各スレッドによって1回のトランザクションで処理されるレコードの数を制御します。1000などの大きな値に設定した場合に、UseBatchDestroyオプションをオンにすると、パフォーマンスに悪影響を与えることがあります。大きなMaxTransactionSizeや小さなMaxRaiseSizeを設定した場合も、パフォーマンスに悪影響を与える可能性があります。同期シナリオでは、最大10:1の比率を保つことを検討してください。理想的なのは、1:1の比率になるまでMaxRaiseSizeを大きくすることです。
UseBatchDestroyの有効化
このプロパティは、処理されたレコードの更新方法を制御します(たとえば、DeletePollingStrategyの場合はDeleted、LogicalDeleteStrategyの場合はMarkedProcessed)。設定すると、そのトランザクションの一部となるすべての行に対して更新/削除が1回だけ実行されます。トランザクションの行数は、MaxTransactionSizeオプションで制御します。このパラメータを設定しても、改善が見られるとはかぎりませんので注意してください。これは、デフォルトでバッチ書込みが使用されており、バッチ書込みの場合もデータベースへのラウンドトリップは1回で済むためです。
バッチ読取りの有効化
1対他関係および1対1関係のバッチ読取りがデフォルトでオンになっています。1対1関係の結合読取りをかわりに使用することもできます。その場合、わずかな改善が見られる可能性があります。
削除ポーリング戦略の無効化
削除ポーリング戦略は、各行を個別に削除することが必要になるため、避けてください。順序付けポーリング戦略では、ヘルパー表の1回の更新で1000行を破棄できます。論理削除も削除より優れています。これは通常、削除より更新のほうが高速であるためです。ただし、パフォーマンスを確保するため、必ず表に索引を作成しておいてください。索引を作成していない場合は、削除を使用すると行の総数を少なく保つことができます。全表スキャンのコストがごくわずかであるために、削除のほうが高速になる場合もあります。
分散ポーリングの使用
分散ポーリングを使用すると、スケーラビリティの高いポーリングを構成できます。詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のスケーラビリティに関する項を参照してください。
同期プロセスの使用
BPELでデータベース・アダプタ・プロセスを非同期に構成できます。Mediatorで順次ルーティング・ルールを作成することもできます。こうすると、インスタンス処理への影響が軽減されるため、データベース対データベースのシナリオにおけるスループットが向上します。
挿入の使用
挿入操作は、存在チェックを使用せず、パフォーマンスへの影響を増大させることもないため、パフォーマンス面で最も優れています。読取りは発生せず、書込みのみが行われます。ほとんど挿入しか行わないことがわかっているのであれば、挿入を使用し、BPELプロセス内部で一意キー制約のSQL例外を捕捉します。例外が発生した場合は、挿入のかわりにマージまたは更新を実行します。パフォーマンスを監視するには、デバッグ・ロギングを有効にして、SQLにおける各種入力を監視します。
マージの無効化
マージでは、関連する表1つにつきSELECT文が1回余分に実行されます。SELECTが使用されるのは、各行を挿入するのか、更新するのかを判断するためです。行が更新される場合、実行される更新は最小限になります。行に変更がない場合は、何も更新されません。
接続プーリングの使用
アダプタがチューニングされたデータ・ソース接続プールを指すようにすることも必要です。データベース接続の作成や解放はパフォーマンスに影響を与える可能性があるため、接続プールのチューニングは重要です。
属性のフィルタ処理の使用
アダプタ構成ウィザードの「属性のフィルタ処理」ページで、XMLにマップするフィールド、およびフィールドにマップするXMLを選択できます。対象となるビジネス・ケースに不要な列(特に、LOBなどの大きな列)の選択を解除すると、パフォーマンスが向上します。
ネイティブ順序付けの使用
XSL関数を使用して主キーをレコードに割り当てる場合は、アダプタの組込みネイティブ順序付けサポートを使用することを検討してください。順序付けサポートを使用すると、デフォルトで一度に50個のキーが取得され、キャッシュされます。キャッシュを行うことで、ラウンドトリップ数が減少するため、パフォーマンスが向上します。チャンク・サイズを段階的に制御するには、sequencePreallocationSizeコネクタ・プロパティを変更します。
データベースでの主キーおよび外部キーの不使用
主キーおよび外部キーを使用すると、パフォーマンスに影響が出る可能性があります。可能であれば、これらの使用は避けてください。外部キーが表で定義されている場合は、索引が外部キー上で作成されていることを確認してください。
JDBCドライバ・クラス
接続プールで物理データベース接続の作成に使用されるデフォルトのJDBCドライバ・クラスはoracle.jdbc.xa.client.OracleXADataSourceです。このドライバをoracle.jdbc.OracleDriverに変更すると、パフォーマンスが向上することがあります。
JDBCドライバのチューニングの詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のサード・パーティJDBCドライバとデータベース接続の構成に関する項を参照してください。
マージのパフォーマンスを最適化する方法の1つは、データベース・チェックの存在チェックを省略することです。行が新しければ、存在チェックはわずかに改善されます。これは、行全体ではなく主キーのみが返されるためです。ただし、マージの性質により、存在チェックに合格したら、行全体を読み取って変更内容を計算する必要があります。したがって、マージ中には、更新対象の行ごとにデータベースへのラウンドトリップが1回余分に発生します。AがマスターでBがプライベートな子である場合は、ルート・ディスクリプタ/表および子表に対してキャッシュのチェックを使用してください。Aが存在しない場合、Bも存在しません。Aが存在する場合、そのすべての子表がAの読取りの一環としてロードされます。
|
注意: 挿入が必要であることがわかっている場合に、各レコードの存在チェックがマージ中に実行されないようにするには、主キーをNULLに設定するという方法があります。 |
DbAdapterのパフォーマンスに対する速度制限を構成して、下流コンポーネントをメッセージの急増から保護することができます。SOAで効率的に処理できるまでは、ソース・データベースのバースト・レコードを未処理のままにすることを検討してください。Oracle Adaptersリリース11.1.1.6.0から、DbAdapterのインバウンド・プロパティRowsPerPollingIntervalを設定できます。これは、1ポーリング間隔で処理できるレコード数に対する制限として機能します。デフォルトは無制限です。
次の各項では、RowsPerPollingIntervalの構成オプションについて説明します。
1秒当たりの最大行数の計算式は、次のとおりです。
SOAクラスタ内のアクティブ・ノード数 x NumberOfThreads x RowsPerPollingInterval / PollingInterval
MaxTransactionSizeは、RowsPerDatabaseTransactionまたはDatabaseFetchSizeであると考えられます。1ポーリング間隔で処理できる行数に作用しません。
1つの例外は、次の構成です。
-distributed polling checked, usesSkipLocking="false"
この場合、RowsPerPollingIntervalは、無制限ではなくMaxTransactionSizeにデフォルト設定されます。
RowsPerPollingIntervalがMaxTransactionSizeまたはMaxRaiseSizeより小さい値に設定されている場合、事実上RowsPerPollingIntervalにまで小さくなります。
この項では、Oracleソケット・アダプタのパフォーマンス・チューニングについて説明します。接続先のソケット・サーバーが対話のたびにソケットをクローズしない場合は、接続プールを使用して、Oracleソケット・アダプタのパフォーマンスを最適化できます。接続プールを使用すると、ソケット接続を繰り返し使用できるので、対話のたびに新しいソケットを作成することによる過負荷が発生しません。
|
注意: 接続プール機能は、アウトバウンドの対話にのみ適用できます。ソケット・アダプタの詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のOracle JCA Adapter for Socketsに関する項を参照してください。 |
Oracleソケット・アダプタの接続プール機能を有効にするには、KeepAlive接続ファクトリ・プロパティをTrueに設定する必要があります。この接続プロパティは、Oracle WebLogic Server管理コンソールの「接続プール」タブで変更できます。
Oracleソケット・アダプタの接続プーリングを変更する手順については、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のOracleソケット・アダプタの接続プーリングの構成に関する項を参照してください。
この項では、Oracle SOA JMSアダプタのパフォーマンス最適化のために設定するプロパティについて説明します。詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のOracle JMSアダプタの概要に関する項を参照してください。
パフォーマンスを改善するには、アダプタ・サービスのadapter.jms.receive.threadsプロパティをチューニングします。デフォルト値は1ですが、複数のインバウンド・スレッドを使用することでパフォーマンスを改善できます。adapter.jms.receive.threadsに指定した値は、複数のインバウンド・ポーラー・スレッドを生成するために使用されます。
例:
<service name="dequeue" ui:wsdlLocation="dequeue.wsdl"> <interface.wsdl interface="http://xmlns.oracle.com/pcbpel/adapter/jms/textmessageusingqueues/textmessageusingqueues/dequeue%2F#wsdl.interface(Consume_Message_ptt)"/> <binding.jca config="dequeue_jms.jca"> <property name="adapter.jms.receive.threads" type="xs:string" many="false">10</property> </binding.jca"> </service>
この項では、Oracle AQアダプタのチューニング構成について説明します。
デキューのパフォーマンスを改善するには、アダプタ・サービスのadapter.aq.dequeue.threadsプロパティを設定します。デフォルト値は1ですが、複数のインバウンド・スレッドを使用することでパフォーマンスを改善できます。プロパティadapter.aq.dequeue.threadsの値は、複数のインバウンド・ポーラー・スレッドを生成するために使用されます。
例:
<service name="dequeue" ui:wsdlLocation="dequeue.wsdl"> <interface.wsdl interface="http://xmlns.oracle.com/pcbpel/adapter/aq/raw/raw/dequeue/#wsdl.interface(Dequeue_ptt)"/> <binding.jca config="dequeue_aq.jca"> <property name="adapter.aq.dequeue.threads" type="xs:string" many="false">10</property> </binding.jca> </service>
Oracle MQ Seriesアダプタは、インバウンド操作のスケーラビリティ機能のみをサポートしています。Oracle MQ Seriesアダプタには、インバウンド・キューからメッセージをデキューするスレッドの数を制御するパラメータが用意されています。.jcaファイルに次のプロパティを指定する必要があります。
InboundThreadCount='N'
上の例では、Nはインバウンド・キューからメッセージをデキューするために生成するスレッドの数です。
