Oracle Business Process Execution Language(BPEL)Process Managerには、コンポジット、ファブリック、アプリケーション、サーバーの各レベルでパフォーマンスを最適化するために構成可能なプロパティ設定がいくつか用意されています。この章では、各プロパティ設定について説明し、プロパティ設定の使用方法に関する推奨事項を示します。
この章の内容は次のとおりです。
BPELとは、一連の独立したサービスを集めてエンドツーエンドのプロセス・フローを組み立てるための標準です。BPELを使用すれば、プロセス統合の取組みのコストおよび複雑さを大幅に軽減できます。Oracle BPEL Process Managerは、BPELビジネス・プロセスの作成、デプロイおよび管理を目的とした、包括的で使いやすいインフラストラクチャを提供します。
詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』の「BPELプロセスのサービス・コンポーネントとエンジンの構成」と『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の「BPELプロセス・サービス・コンポーネントの使用」を参照してください。
この項では、BPELエンジン・レベルでのパフォーマンス・チューニング・プロパティについて説明します。これらのプロパティは、Oracle Enterprise Managerを使用して構成できます。詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のBPELプロセス・サービス・エンジン・プロパティの構成に関する項を参照してください。
注意: この章で説明する構成例および推奨設定は解説用のものです。各自のユースケース・シナリオを検討し、パフォーマンスの向上が可能な構成オプションを判断してください。 |
ディスパッチャは、実行するディスパッチャ・メッセージをスケジュールする際に、そのメッセージをスレッド・プールにエンキューすることができます。各ディスパッチャ・セットには、スレッド・プール(java.util.concurrent.ThreadPoolExecutor)が1つ含まれます。実装されたBPELスレッド・プールでは、メッセージがエンキューされるとスレッドに通知し、適切な数のスレッドがプール内でインスタンス化されるようにしています。
注意:
|
dspSystemThreads
プロパティには、システム・ディスパッチャ・メッセージの処理に割り当てるスレッドの総数を指定します。システム・ディスパッチャ・メッセージとは、通常はサーバーで迅速に処理される一般的なクリーン・アップ・タスク(ステートフル・メッセージBeanを元のプールへ解放するなど)です。一般に、実行時に生成される数のシステム・ディスパッチャ・メッセージは、ごく少数のスレッドで処理できます。
このスレッド・プールの最小スレッド数は1です。0や負の数に設定することはできません。
デフォルト値は2
です。1スレッド未満の値は、デフォルト値に変更されます。
dspInvokeThreads
プロパティには、呼出しディスパッチャ・メッセージの処理に割り当てるスレッドの総数を指定します。呼出しディスパッチ・メッセージは、受信したペイロードごとに生成されるもので、新規インスタンスのインスタンス化を目的としています。エンジンによって処理されるリクエストの大部分が(インスタンス・コールバックではなく)インスタンス呼出しである場合は、呼出しスレッド数を増やすことでパフォーマンスを改善できる可能性があります。スレッド数が多くなると、コンテキスト切替えのコストが高くなるため、CPU使用率が増加する場合もあります。
このスレッド・プールの最小スレッド数は1です。0や負の数に設定することはできません。
デフォルト値は20スレッドです。1スレッド未満の値は、デフォルト値に変更されます。
dspEngineThreads
プロパティには、エンジン・ディスパッチャ・メッセージの処理に割り当てるスレッドの総数を指定します。エンジン・ディスパッチャ・メッセージは、アクティビティを非同期に処理する必要がある場合に必ず生成されます。デプロイされたプロセスの大部分が永続的で、多数のデハイドレーション・ポイント(プロセス途中のreceive、onMessage、onAlarmおよびwaitアクティビティ)がある場合は、エンジン・スレッド数を増やすことでパフォーマンスを改善できる可能性があります。スレッド数が多くなると、コンテキスト切替えのコストが高くなるため、CPU使用率が増加する場合もありますので注意してください。
このスレッド・プールの最小スレッド数は1です。0や負の数に設定することはできません。
デフォルト値は30スレッドです。1スレッド未満の値は、デフォルト値に変更されます。
dspMaxRequestDepth
プロパティには、同じリクエストの中で処理するメモリー内アクティビティの最大数を設定します。Oracle BPEL Process Managerは、アクティビティ・リクエストを処理した後、リクエストの有効性を損わずに後続のアクティビティをできるだけ多く処理しようとします。連続したアクティビティ処理がこの深さに達すると、インスタンスはデハイドレーションされ、次のアクティビティが別のトランザクションで実行されます。
リクエストの深さが大きすぎると、合計リクエスト時間がアプリケーション・サーバーのトランザクション・タイムアウト制限を超えることがあります。このプロセスは、永続プロセスに適用されます。
デフォルト値は600アクティビティです。
注意: 各スレッド・プールの最小スレッド数は1です。dsp*Threadsを0や負の数に設定することはできません。 |
次のプロパティには、監査レベルを設定できます。
auditLevel
プロパティには、監査証跡のロギング・レベルを設定します。この構成プロパティは、永続プロセスと一時プロセスの両方に適用されます。このプロパティが制御するのは、プロセスによってログに記録される監査イベントの量です。監査イベントを記録すると、audit_trail
表へのデータベース挿入が増えるため、パフォーマンスに影響が出ることがあります。監査情報は、Oracle Enterprise Managerコンソールからプロセスの状態を確認する目的でのみ使用されます。
監査情報を保存しない場合は、Off値を使用します。監査レベルは、常にビジネス要件およびユースケースに従って選択してください。監査レベルの設定の詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』の監査レベル設定の優先順位の概要に関する項を参照してください。
値 | 説明 |
---|---|
継承 |
インフラストラクチャ・レベルから監査レベルを継承します。 |
オフ |
監査イベント(アクティビティ実行情報)は保持されず、ロギングは実行されません。この場合、インスタンス処理のパフォーマンスがわずかに向上する可能性があります。 |
最小 |
すべてのイベントがログに記録されます。ただし、監査詳細(変数の内容)は記録されません。 |
エラー |
管理者がただちに対処する必要があり、製品のバグ以外が原因の重大な問題のみログに記録します。このレベルを使用すると、パフォーマンスを向上できます。 |
本番 |
すべてのイベントがログに記録されます。assignアクティビティの監査詳細は記録されませんが、それ以外のすべてのアクティビティの詳細が記録されます。 |
開発 |
すべてのイベント、およびすべてのアクティビティのすべての監査詳細がログに記録されます。 |
auditdetailthreshold
プロパティには、監査証跡詳細文字列の最大サイズ(KB)を設定します。これを超えると、監査証跡詳細文字列が監査証跡とは別に格納されるようになります。監査証跡詳細文字列がしきい値設定より大きい場合、監査証跡詳細文字列は、監査証跡が最初に取得されたときに即座にロードされません。詳細文字列のサイズとともにリンクが表示されます。しきい値設定より大きな文字列は、audit_trail
表ではなくaudit_details
表に格納されます。
通常、詳細文字列にはBPEL変数の内容が含まれています。変数が非常に大きい場合は、変数を監査証跡に記録すると、パフォーマンスに重大な影響を与える可能性があります。
デフォルト値は50000(50KB)です。
このプロパティは、BPEL監査データを保持するための方針を指定します。
値 | 説明 |
---|---|
syncSingleWrite (デフォルト) |
監査証跡およびデハイドレーションは、1つのトランザクションでDBに対して保持されます。 |
syncMultipleWrite |
監査証跡およびデハイドレーションは、同じスレッドの別個のトランザクションで保持されます。 |
async |
監査証跡およびデハイドレーションは、別個のスレッドおよび別個のトランザクションによって保持されます。 |
デフォルトでは、監査メッセージはBPELメイン・トランザクションの一部として格納されます。BPELインスタンスは、フローがデハイドレーションに達するまで監査メッセージを保持し続けます。ユースケースによっては、たとえば、大規模なループがあり、デハイドレーション・ポイントがループ内にない場合、大量の監査ログがたまってしまいます。このため、メモリー不足問題が発生して、BPELメイン・トランザクションでタイムアウト・エラーが発生する可能性があります。syncMultipleWrite
またはasync
を使用して、監査メッセージをメイン・トランザクションとは別個に格納することを検討してください。
syncMultipleWrite
およびasync
auditStorePolicy
を使用する場合に、検討する必要がある他のプロパティがいくつかあります。次の各項を参照してください。
このプロパティは、エンジンが監査イベントをフラッシュする頻度を制御します。基本的に現行バッチにイベントを追加した後に、エンジンは現行バッチのバイト・サイズがこの値より大きいかどうかを確認します。
async
またはsyncMultipleWrite
の監査方式を使用している場合は、このプロパティのチューニングを検討してください。このサイズは、アプリケーションに基づいてチューニングする必要があります。
oneWayDeliveryPolicy
プロパティは、Oracle BPEL Serverに入るメッセージのデータベース永続性を制御します。デフォルトでは、受信リクエストは配信サービス・データベース表dlv_message
に保存されます。保存されたリクエストは、後でOracle BPEL Serverのワーカー・スレッドによって取得され、ターゲットのBPELプロセスへ配信されます。このプロパティは、配信メッセージを永続化するものであり、永続プロセスに適用されます。
oneWayDeliveryPolicy
プロパティをasync.cacheに設定すると、一方向メッセージの到着頻度がOracle BPEL Serverによる配信の頻度よりかなり高い場合や、サーバー障害が発生した場合には、メッセージが失われる可能性があります。また、システムが過負荷の状態になり(メッセージがスケジュール済キューにたまり)、メモリー不足エラーが発生することもあります。各自のユースケース・シナリオを検討し、この設定が適切かどうかを判断してください。
一方向呼出しメッセージは、配信されるまで、配信キャッシュに格納されます。一方向メッセージの到着頻度がOracle BPEL Serverによる配信の頻度よりかなり高い場合や、サーバー障害が発生した場合には、メッセージが失われる可能性があります。
oneWayDeliveryPolicy
は、Oracle 10gの構成プロパティdeliveryPersistencePolicy
が基になっています。11gの構成プロパティ名は、bpel.config.oneWayDeliveryPolicy
です。
値 | 説明 |
---|---|
async.persist(デフォルト) |
配信メッセージはデータベースに保存されます。この設定の場合、信頼性は確保されますが、データベースのパフォーマンスに多少の影響が出ます。システムの全体的なパフォーマンスに影響が出ることもあります。 |
async.cache |
受信した配信メッセージはメモリー内キャッシュにのみ保存されます。信頼性よりパフォーマンスを優先する場合は、この設定を検討してください。 注意: |
sync |
Oracle BPEL Serverに、呼出しキューのメッセージのスケジューリングをバイパスするよう指示し、BPELインスタンスを同期的に呼び出します。この設定は、データベースのパフォーマンスに影響を与えることがあります。 |
MaximumNumberOfInvokeMessagesInCache
プロパティは、メモリー内キャッシュに保持できる呼出しメッセージの数を指定します。エンジンがこの制限値に達すると、メッセージがディスパッチャのメモリー内キャッシュにプッシュされます。保存されたメッセージは、リカバリ・ジョブを使用してリカバリできます。無効にするには、値-1を使用します。
デフォルト値は100000です。
StatsLastN
プロパティには、最近処理されたリクエスト・リストのサイズを設定します。リクエストが終了するたびに、リクエストの統計がリクエスト・リストに保存されます。0以下の値を指定すると、統計収集が無効になります。パフォーマンスを最適化するには、統計収集が不要であれば無効にすることを検討してください。
このプロパティは、永続プロセスと一時プロセスの両方に適用されます。
デフォルト値は-1です。
largedocumentthreshold
プロパティには、大きなXMLドキュメントの永続性しきい値を設定します。これは、BPEL変数の最大サイズ(KB)です。これを超えると、BPEL変数が他のインスタンス・スコープ・データとは異なる表に格納されるようになります。
このプロパティは、永続プロセスと一時プロセスの両方に適用されます。
インスタンス処理を行う必要が生じるたびに、大きなXMLドキュメントの読込みおよび書出しが絶えず行われる場合は、Oracle BPEL Server全体のパフォーマンスに影響が出ます。
デフォルト値は10000(100KB)です。
validateXML
プロパティには、送受信するXMLドキュメントを検証するかどうかを指定します。Trueに設定すると、Oracle BPEL Process Managerは送受信するXMLドキュメントにスキーマ検証を適用します。スキーマに準拠しないペイロード・データが捕捉され、フォルトとして表示されます。
この設定は、SOAコンポジット・アプリケーションおよびSOAインフラストラクチャのペイロード検証レベルの設定に依存しません。ペイロード検証がサービス・エンジンとSOAインフラストラクチャの両レベルで有効な場合、データは2回チェックされます。1回目は、データがSOAインフラストラクチャに入るとき、2回目は、データがサービス・エンジンに入るときです。
注意: XMLペイロード検証を有効にすると、パフォーマンスに影響が出る可能性があります。
このプロパティは、永続プロセスと一時プロセスの両方に適用されます。
デフォルト値はFalseです。
SyncMaxWaitTime
プロパティには、プロセス結果レシーバが戻るまでに結果を待つ最大時間を設定します。非同期BPELプロセスからの結果は、Oracle BPEL Serverからの結果を待つレシーバによって同期的に取得されます。
デフォルト値は45秒です。
InstanceKeyBlockSize
プロパティは、インスタンスIDの範囲サイズを制御します。Oracle BPEL Serverは、指定された値を使用して、インスタンス・キー(プロセス・インスタンスIDの範囲)をバッチ形式で作成します。このメモリー内IDの範囲が作成されると、次の範囲が更新されて、ci_id_range
表に保存されます。
たとえば、instanceKeyBlockSize
が100
に設定されている場合、Oracle BPEL Serverはメモリー内にインスタンス・キーの範囲(100個のキー。これは後でcube_instance
表にcikey
として挿入される)を作成します。最適なパフォーマンスを確保するには、ブロック・サイズがci_id_range
表に対する更新の数より大きくなるようにします。
デフォルト値は10000です。
MaxRecoverAttempt
パラメータを使用すると、リカバリ可能な同じインスタンス内で実行する自動リカバリ試行の数を構成できます。入力した値によって、起動メッセージおよびコールバック・メッセージがリカバリされる最大回数が指定されます。1つのメッセージに対するリカバリ試行の数が、指定された値を超過すると、そのメッセージにはリカバリ不能のマークが付けられます。
BPELインスタンスがinvokeMessageを使用して別のサーバーへのコールを作成し、サーバー停止、検証エラーまたはセキュリティ例外のためにそのコールが失敗すると、invokeMessageはリカバリ・キューに入れられ、BPELはそれらのメッセージを再試行しようとします。大量のメッセージがあり、大部分が同じターゲットに送信されている場合、そのターゲットはオーバーロードになる可能性があります。MaxRecoveryAttempt
の適切な値を設定して、BPEL Webサービス・コールからターゲットのサーバーに対する過剰な負荷を防ぎます。
BPELのチューニングに関する次の考慮事項は、すべてのBPELデプロイメントには適用できない場合があります。必ず各自のユースケース・シナリオを検討して、これらの構成をデプロイメントで使用できるかどうかを判断してください。
この項では、デプロイメント・ディスクリプタの一部のセクションの構成プロパティを示します。各構成プロパティ・パラメータ、および各パラメータを変更した場合に予想されるエンジンの動作について説明します。
この項で設定するプロパティはすべて、BPELプロセスを含むコンポーネントの動作にのみ影響を与えます。各BPELプロセスは、コンポジットのコンポーネントとして作成できます。これらのプロパティは、composite.xmlまたはOracle Enterprise Manager Fusion Middleware ControlのシステムMBeanブラウザで変更できます。詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』を参照してください。
次のコンポーネント・プロパティをチューニングすることでパフォーマンスを改善できます。
このプロパティは、処理対象のプロセスが一時プロセスであり、インスタンスのデハイドレーションが必要ないことをOracle BPEL Serverに示します。Trueに設定すると、completionPersistPolicyを使用して永続性動作が判断されます。このプロパティをTrueに設定できるのは、一時プロセス、またはreceive、wait、onMessage、onAlarmなどのアクティビティのようにデハイドレーション・ポイントを含まないプロセスに対してのみです。inMemoryOptimizationプロパティは、BPELコンポーネント・レベルで設定します。Falseに設定すると、デハイドレーションが無効になり、一部のユースケースのパフォーマンスを向上できます。
値:
このプロパティは次の値を取ります。
False(デフォルト): インスタンスは完全に永続化され、デハイドレーション・ストア・データベースに記録されます。
True: completionPersistPolicyを使用して永続性動作が判断されます。第13.3.1.1.2項を参照してください。
このプロパティでは、インスタンス・データの保存方法を構成します。BPELコンポーネント・レベルでのみ設定できます。completionPersistPolicyプロパティを使用できるのは、inMemoryOptimizationがTrue(一時プロセス)に設定されている場合のみです。このパラメータは、データベースの増大およびスループットに影響を与える可能性があります(I/Oが減少するため)。
値 | 説明 |
---|---|
On(デフォルト) |
完了したインスタンスは通常どおり保存されます。 |
遅延 |
完了したインスタンスは、異なるスレッドで、別のトランザクション内に保存されます。 |
フォルト |
失敗したインスタンスのみが保存されます。 注意: 未処理フォルトが発生すると、これらのフラグにかかわらず、インスタンスの監査情報は |
オフ |
このプロセスのインスタンスは保存されません。 |
BPELプロセス・サービス・コンポーネントに監査レベルを設定できます。この設定は、SOAインフラストラクチャ、サービス・エンジンおよびSOAコンポジット・アプリケーション・レベルでの監査レベルより優先されます。
次の例に示すように、bpel.config.auditLevel
プロパティに、SOAプロジェクトのcomposite.xmlファイルでの該当する値を設定します。
<component name="BPELProcess">
<implementation.bpel src="BPELProcess.bpel" />
<property name="bpel.config.auditLevel">Off</property>
</component>
値 | 説明 |
---|---|
継承 |
インフラストラクチャ・レベルから監査レベルを継承します。 |
オフ |
監査イベント(アクティビティ実行情報)は保持されず、ロギングは実行されません。この場合、インスタンス処理のパフォーマンスがわずかに向上する可能性があります。 |
最小 |
すべてのイベントがログに記録されます。ただし、監査詳細(変数の内容)は記録されません。 |
エラー |
管理者がただちに対処する必要があり、製品のバグ以外が原因の重大な問題のみログに記録します。このレベルを使用すると、パフォーマンスを向上できます。 |
本番 |
すべてのイベントがログに記録されます。assignアクティビティの監査詳細は記録されませんが、それ以外のすべてのアクティビティの詳細が記録されます。 |
開発 |
すべてのイベント、およびすべてのアクティビティのすべての監査詳細がログに記録されます。 |
パートナ・リンクは、実行時にBPELで動的に構成できます。これは、BPELによって呼び出されるターゲット・サービスが実行時まで不明な場合に便利です。次のパートナ・リンク・プロパティをチューニングすることでパフォーマンスを改善できます。
idempotentアクティビティとは、再試行可能なアクティビティ(assignアクティビティやinvokeアクティビティなど)です。Oracle BPEL Serverは、非idempotentアクティビティの後にインスタンスを保存します。このプロパティは、永続プロセスと一時プロセスの両方に適用されます。
値:
このプロパティは次の値を取ります。
False: アクティビティは実行直後にデハイドレーションされ、デハイドレーション・ストアに記録されます。idempotent
をFalseに設定すると、フェイルオーバーによる保護は強化されますが、BPELプロセスがデハイドレーション・ストアに頻繁にアクセスする場合はパフォーマンスに影響が出ることがあります。
True(デフォルト): Oracle BPEL Serverに障害が発生した場合、再起動後にアクティビティが再度実行されます。これは、アクティビティの呼出し直後にサーバーがデハイドレーションされず、アクティビティの実行が記録されていないためです。このプロパティをTrueに設定できる例としては、読取り専用サービス(CreditRatingServiceなど)や、インスタンスのトランザクションを共有するローカルのEJB/WSIF呼出しなどがあります。
デフォルトでは、Oracle BPEL Process Managerはブランチをパラレルではなく順番に実行することによって、単一のスレッドで処理を実行します。このプロパティをTrueに設定すると、各ブランチのinvokeアクティビティをパラレルに実行するための新しいスレッドが作成されます。このプロパティは、永続プロセスと一時プロセスの両方に適用されます。
複数のflowブランチやflow nブランチにinvokeアクティビティが存在する場合は、このパラメータをTrueに設定することを検討してください。これは、パラレルのinvokeアクティビティが双方向の際には特に有効ですが、パラレルの一方向呼出しに対しても効果的な場合があります。
注意: 同じパートナ・リンクへの呼出しは、パラレルではなく順番に発生します。 |
値:
True: Oracle BPEL Serverは、呼出しを実行するための新しいスレッドを生成します。
False(デフォルト): Oracle BPEL Serverは、単一のプロセス・スレッドでinvokeアクティビティを実行します。
メッセージ境界の検証を有効にします。検証を追加すると、CPUおよびメモリーのリソースが余分に消費されて、パフォーマンスに影響を与えることがありますので注意してください。
値:
True: Trueに設定すると、このパートナ・リンクの<receive>および<invoke>中に、XMLメッセージがXMLスキーマに対して検証されます。XMLメッセージが無効な場合は、bpelx:invalidVariables
ランタイムBPELフォルトがスローされます。これは、ドメイン・レベルのvalidateXML
プロパティに優先します。
False(デフォルト): XML検証が無効になります。
インスタンス・データは、Oracle BPEL Process Managerのスキーマ表の領域を占有します。監査やデハイドレーションによってデータが増大すると、データベースのパフォーマンスおよびスループットに大きな影響を与える可能性があります。監査構成については第13.2.2項「監査レベルのチューニング」を、デハイドレーション構成については第13.3.1.1.1項「inMemoryOptimization」を参照してください。次の表は、インスタンス・データ増大の影響を受ける表をまとめたものです。各表について簡単に説明しています。
表13-1 インスタンス・データ増大の影響を受けるOracle BPEL Process Managerの表
表の名前 | 表の説明 |
---|---|
|
インスタンスの監査証跡を格納します。Oracle BPEL Controlに表示される監査証跡は、XMLドキュメントから作成されます。インスタンスが処理されると、各アクティビティがイベントをXMLとして監査証跡に書き込みます。 |
|
APIを通じてログに記録される監査詳細を格納します。assignアクティビティなどは、デフォルトで、変数を監査詳細としてログに記録します。 監査詳細はサイズが大きいため、 |
|
プロセス・インスタンス・メタデータ(インスタンスの作成日、現在の状態、タイトル、プロセス識別子など)を格納します。 |
|
インスタンスのスコープ・データ(BPELフローで宣言されているすべての変数や、フロー全体のルーティング・ロジックを支援する内部オブジェクトなど)を格納します。 |
|
受信(呼出し)メッセージおよびコールバック・メッセージを受信時に格納します。この表には、メッセージのメタデータ(現在の状態、プロセス識別子、受信日など)のみが格納されます。 |
|
インスタンスの配信サブスクリプションを格納します。receiveアクティビティやonMessageアクティビティのように、インスタンスがパートナからのメッセージを待っているときは必ず、そのreceiveアクティビティに対するサブスクリプションが書き込まれます。 |
|
|
|
|
|
インスタンスに対して作成されたタスクを格納します。TaskManagerプロセスは、この表に現在の状態を保存します。 |
|
インスタンスによって作成されたアクティビティを格納します。BPELフローのすべてのアクティビティに |
|
システム内のすべてのラージ・オブジェクト( |
|
ヘッダーおよびプロパティの情報を格納します。 |