ここでは、次の項目について説明します。
パフォーマンスを向上させるには、要件とシステムに基づいてメモリー引数を適切に設定します。 使用可能なリソースを最大限利用するための主な方法は、コードのクリーン・アップ、マルチスレッドおよびテーブルの索引付けです。 使用方法およびニーズに基づいて様々なプロセス間でリソースを共有する際に、Javaパフォーマンス・チューニングも役立ちます。
大きなペイロードの設定を使用する場合は、内部デリバリ・チャネルがデフォルトのチャネルまたはJMSキューである必要があります。
B2B構成プロパティを変更する場合、通常はサーバーの再起動が必要になります。詳細は、次の説明を参照してください。
『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』
この項の様々な例の構文は、汎用UNIX形式を反映しています。
次の設定によって、32ビット・コンピュータで2GBのRAMを使用し、200MBのB2B構成データがあるOracle B2Bのパフォーマンスが向上します。 大きなペイロードをWindowsオペレーティング・システムで処理する場合は、64ビットのサーバーをお薦めします。
メモリー引数は、DOMAIN_HOME/bin/setSOADomainEnv.shで取得されます。 メモリーのチューニングは、例A-1および例A-2に示すように、Oracle JRocketまたはSUN JVMに適用されます。
WebLogicドメインで次のサーバーを起動する前に、setSOADomain.shスクリプト(DEFAULT_MEM_ARGSを参照)でヒープ・サイズの設定を確認します。
SOA管理対象サーバー
WebLogic管理サーバー
B2Bで大きなペイロードを処理するには、サーバー起動時に正確なヒープ・サイズの設定を使用する必要があります。
メタデータ・サービス(MDS)のインスタンス・キャッシュ・サイズを設定するには、Oracle Enterprise Manager Fusion Middleware Controlを使用して、b2b.mdsCacheを200000などの値に設定します。詳細は、付録Bの「Fusion Middleware Controlで設定するプロパティ」を参照してください。
b2b.inboundThreadCountおよびb2b.outboundThreadCountの値を変更すると、Oracle B2Bメッセージ処理が向上する可能性があります。 推奨値は、使用しているシステムによって異なります。 2GBのコンピュータの場合は、3〜5に設定することをお薦めします。 b2b.inboundThreadSleepTimeおよびb2b.inboundThreadSleepTimeプロパティを設定すると、メッセージ処理後にスレッドがスリープ状態になります。 10〜1000(ミリ秒)に設定することをお薦めします。
スレッドがスタック状態の場合は、「スタック・スレッド最大時間」の値を変更すると、Oracle B2Bメッセージ処理が向上する可能性があります。 これは、サーバーがスレッドをスタック状態であると判断するまでに、スレッドが継続的に動作している必要のある秒数をサーバーがチェックする最大時間です。
スタック・スレッド例外が発生した場合のみ、Oracle WebLogic Server管理コンソールで「スタック・スレッド最大時間」の設定を変更する必要があります。 この数値を増やすとパフォーマンスが低下する可能性があります。
「環境」 > 「サーバー」 > 「soa_server_name」 > 「構成」 > 「チューニング」の順に選択します。 図A-1に示すように、「スタック・スレッド最大時間」を最大1200(デフォルト値は600秒)に設定します。
150MGを超える構成を格納する場合は、例A-3に示すように、データ・ファイルを拡張または追加して、表領域サイズを増やします。
比較的処理の遅いWindowsコンピュータ(2〜4GB、32ビット)では、Oracle B2BのJTAタイムアウトの値を増やす必要があります。 Oracle WebLogic Server管理コンソールを使用して、環境に応じて、JTAトランザクション・タイムアウトを大きい数に増やします。 状況によっては、90秒への増加が推奨設定となります。必要に応じて、さらに大きい値に増やしてください。
多数のメッセージを処理するシステムの1秒当たりのパフォーマンスを向上させるには、次の手順を実行することをお薦めします。
B2B_DATA_STORAGEテーブル用に別の表領域を作成して、LOBデータを別々に格納できるようにします。
LOBデータの格納に使用する表領域のブロック・サイズを増やして、挿入の競合を削減します。
ペイロード・サイズが30KBを超える場合、1000を超えるドキュメントをバッチ処理するには、次の処理を実行することをお薦めします。
SOAサーバーを64ビットのコンピュータにインストールします。
バッチ・コミット・サイズを0(ゼロ)を超える値(例: 100)に設定します。
Oracle WebLogic Server管理コンソールを使用して、JTAトランザクション・タイムアウトを大きい値に増やします。
setSOADomainEnv.shで、ヒープ・サイズの設定を-Xms1024mから-Xmx2048mに変更します。
SOA WSバインディング・レイヤーからの添付をストリーミングするには、サービスおよび参照のために、composite.xmlに次のプロパティを追加します。
streamIncomingAttachments="true" streamOutgoingAttachments="true"
例A-4にサンプルを示します。
Oracle B2Bでは、SOAインフラストラクチャおよびJMS内部キューの使用によって、大きなペイロードを処理できます。
インバウンドの設定
図A-2に、インバウンドの場合に設定するプロパティを示します。 「管理」 > 「構成」の順に移動します。
大きなペイロードを処理するためにコンポジットをデプロイする場合、必要な構成はこのプロパティのみです。 B2Bでペイロードがコンポジットに配信されていない場合は、図A-3に示すように、「JMSキューをデフォルトとして使用」を「true」に設定します。 「管理」 > 「構成」の順に移動します。
「JMSキューをデフォルトとして使用」が「true」に設定されていると、ペイロードは、JMSベースのキューであるB2B_IN_QUEUEに配信されます。
アウトバウンドの設定
図A-4に、アウトバウンドの場合に設定するプロパティを示します。
また、B2Bに、サービス・エンジンで大きなペイロードが処理されていることを通知する必要があります。 この変更には次の2つの手順があります。
大きなペイロードをOracle B2Bに送信する場合は、b2b.largePayloadプロパティをBPELプロセスで設定する必要があります。 大きなペイロードを処理しないコンポジット・サンプルの場合、変更はありません。
このフラグを処理するためのOracle B2Bのコード変更
アウトバウンドBPELプロセスの<variables>セクションで、Variable_largePayload変数を宣言します。
<variable name="Variable_largePayload" type="xsd:string"/>
assignアクティビティで、'true'を変数にコピーします。
<copy> <from expression="'true'"/> <to variable="Variable_largePayload"/> </copy>
invokeアクティビティで、変数をb2b.largePayloadに割り当てます。
<bpelx:inputProperty name="b2b.largePayload" variable="Variable_largePayload"/>
|
注意: BPELによって大きなペイロードがOracle B2Bに送信されていない場合、このプロパティは設定しないでください。 コードがチェックインされた場合は、このコードに適合するように大きなペイロードのサンプルを更新する必要があります。 BPELおよびMediatorで、 Oracle B2Bでは、対応するエンドポイントにペイロードが送信された後、大きなペイロードは大きなペイロード処理ディレクトリに保持されます。 |
大きなペイロードのサポートについて
大きなペイロードをテストしている場合は、「管理」 > 「構成」タブの「ペイロードをログに記録」を「false」に設定します。
大きなペイロードをテストしている場合は、ペイロードがレポートにリストされないように、「管理」 > 「構成」タブの「ペイロードの表示」を「false」に設定します。
大きなペイロードの処理時にエンキュー・スクリプトを使用する場合は、次の指定を追加します。
eventName=LARGE_PAYLOAD=true
最大ヒープ・サイズを、-Xmx2048mを使用するように増やします。
soadatasourceが自動拡張するようにデータベースの表領域サイズを増やし、表領域ファイル・サイズの上限を増やします。
alter database datafile '/scratch/$user/auto_work/db230/oradata/db230/SH_soainfra.dbf' autoextend on next 10M maxsize 4096M
Oracle WebLogic管理サーバーでトランザクション・タイムアウトを設定します。
Weblogicコンソール・サービス -> JTAタイムアウト秒=720秒。
Weblogicコンソール・サービス -> 「JDBC」->データソース->SOADataSource。XAタイムアウトを120秒から180秒に増やします。
Oracle B2Bを(SOAインフラストラクチャを使用せずに)単独で使用する場合は、Oracle Enterprise Manager Fusion Middleware Controlを使用して、b2b.jtaTimeoutにJTAタイムアウトを設定できます。 詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』を参照してください。
アウトバウンドSOAコンポジットの場合は、図A-5に示すように、Fileアダプタ用に「ファイル・ストリーミングを使用します」オプションを常に選択します。
32ビットのWindowsコンピュータでは、ペイロード・サイズの制限が50MBです。 これは、Windows固有の制限によって、1536Mを超えるヒープ・サイズを設定できないためです。 Java VMによって、メモリー不足例外がスローされます。
次の推奨設定は、約2,500の取引パートナを含むデータセット(サイズが約253MBのエクスポートZIPファイル)があり、6GBのコンピュータを使用することを想定しています。 このような設定を使用すると、アップグレード・アシスタントを使用した場合に、データ・アップロード時間を大幅に短縮できる可能性があります。
Oracle WebLogic Server管理コンソールを使用して、次の値を増やします。
JTAトランザクション・タイムアウトを30から350に増やします。
最大メッセージ・サイズをデフォルト・サイズから200000000に増やします。
パフォーマンス向上のために索引を追加します。 Oracle Database 11g Enterprise Editionリリース11.1.0.7.0 - 製品版を、「パーティショニング」、「OLAP」、「データ・マイニング」、「Real Application Testing」の各オプションとともに使用して、次の処理を実行します。
SQL> create index idx_mds_attr on
rc1_mds.MDS_ATTRIBUTES("ATT_VALUE","ATT_LOCALNAME");
Index created.
SQL> create index idx_mds_path on
rc1_mds.MDS_PATHS("PATH_CONTENTID","PATH_PARTITION_ID");
Index created.
SQL> commit;
次の更新後のメモリー設定を使用して管理対象サーバーを起動します。
DEFAULT_MEM_ARGS="-Xms1024m -Xmx2048m"
ORACLE_HOME/bin/UAデフォルト・メモリーをデフォルトの256から2048に変更します。デフォルトは次のとおりです。
$JAVA_HOME/bin/java ${JAVAMODE} -Xmx256m -classpath ${CLASSPATH}
-Dua.home=$base_dir -Dice.pilots.html4.ignoreNonGenericFonts=true
-Dsun.lang.ClassLoader.allowArraySyntax=true
-Doracle.installer.oui_loc=$OUI_HOME oracle.ias.upgrade.UpgradeDriver
$ARGUMENTS
このデフォルトを次のように変更します。
$JAVA_HOME/bin/java ${JAVAMODE} -Xmx2048m -classpath ${CLASSPATH}
-Dua.home=$base_dir -Dice.pilots.html4.ignoreNonGenericFonts=true
-Dsun.lang.ClassLoader.allowArraySyntax=true
-Doracle.installer.oui_loc=$OUI_HOME oracle.ias.upgrade.UpgradeDriver
$ARGUMENTS
スタック・スレッド最大時間を600から2000に変更します。