|
|
以降の各節では、高度なパフォーマンスを誇る Oracle WebLogic Integration アプリケーションの設計およびチューニングに関するヒントを紹介します。内容は以下のとおりです。
この節では、設計時のパフォーマンスに関する次のようなヒントを紹介します。
デフォルトでは、パラレル ノードの各ブランチはトランザクションでは独立して扱われます。パフォーマンスを向上させるには、各パラレル要素のソースで continueTransaction プロパティを次のように設定して、この動作をオーバーライドできます。
<parallel continueTransaction="true">
Oracle WebLogic Server Administration Console では、「タイマー メッセージ」(送信時刻が現在の時刻より後の時刻に設定されているメッセージ) は「保留中メッセージ」として表示されます。
ステートフル プロセスの場合、会話の最大存続期間を使用しないのであれば、次のように無効にします。
会話の存続期間の詳細については、『WebLogic Web サービス リファレンス ガイド』にある「JWS アノテーション リファレンス」で「@jws:conversation-lifetime アノテーション」を参照してください。
トランザクションのデフォルトのタイムアウト期間は 300 秒 (5 分) です。以下のいずれかの方法で、トランザクションがタイムアウトするまでの経過時間を増やすことができます。
wlw-config.xml の transaction-timeout 要素の値を増やす。これにより、アプリケーションのすべてのトランザクションのタイムアウト期間が変更されます。weblogic-ejb-jar.xml の AsyncDispatcher MDB についての trans-timeout-seconds の値を増やす。これにより、AsyncDispatcher MDB で処理されるトランザクションのタイムアウト期間のみが変更されます。詳細については、『Oracle WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「weblogic-ejb-jar.xml デプロイメント記述子のリファレンス」にある「2.1 の weblogic-ejb-jar.xml の要素」の「trans-timeout-seconds」を参照してください。
トランザクションのタイムアウト期間の回復に関する考慮事項については、「回復に対応した Oracle WebLogic Integration アプリケーションのコンフィグレーション」を参照してください。
この節では、実行時のチューニングに関するヒントを紹介します。
パフォーマンスを最適化するには、Oracle WebLogic Server を起動するときに次のフラグを使用します。
production noiterativedev nodebug notestconsole
| 注意 : | 生成済みのプロダクション ドメインを使用する場合、これらのフラグはデフォルトで設定されますが、開発ドメインを使用する場合には、デフォルトでは設定されません。 |
Oracle WebLogic Integration のプロジェクトは、J2EE リソースにマップします。Oracle WebLogic Integration プロジェクト内でチューニングできる主な EJB プールは、SyncDispatcher ステートレス セッション Bean (SLSB) プールと AsyncDispatcher メッセージ駆動型 Bean (MDB) プールです。これらのプールはアプリケーション内のすべての Oracle WebLogic Integration プロジェクトに存在します。
すべての同期要求は SyncDispatcher によってルーティングされ、すべての非同期 (バッファ) 通信は AsyncDispatcher によってルーティングされます。
これらの Bean のプール サイズをコンフィグレーションするには、次の 2 つの方法があります。
dispatch-policy 要素を入力して weblogic-ejb-jar.xml ファイルを更新します。
詳細については、『Oracle WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「weblogic-ejb-jar.xml デプロイメント記述子のリファレンス」にある「2.1 の weblogic-ejb-jar.xml の要素」の「dispatch-policy」を参照してください。
max-beans-in-free-pool を設定しても MDB プール サイズをコンフィグレーションできる。
MDB プール サイズのコンフィグレーション方法の詳細については、『Oracle WebLogic Server パフォーマンス チューニング ガイド』の「Oracle WebLogic Server EJB のチューニング」にある「パフォーマンス関連の weblogic-ejb-jar.xml パラメータの設定」を参照してください。
チューニング全般に関する基本情報については、『Oracle WebLogic Server パフォーマンス チューニング ガイド』を参照してください。
可。JMS イベント ジェネレータの max-beans-in-free-pool は、デフォルトでは 5 に設定されています。この値を大きくすると、多くの場合はパフォーマンスを向上させることができます。
詳細については、『Oracle WebLogic Server パフォーマンス チューニング ガイド』の「Oracle WebLogic Server EJB のチューニング」にある「パフォーマンス関連の weblogic-ejb-jar.xml パラメータの設定」を参照してください。
長時間実行されるビジネス プロセスに対してバージョニングを行う場合は、プロダクション モードでアプリケーションをデプロイする前の初期段階からプロセスをバージョニングするようにします。それ以外の場合は、バージョニングされていないインスタンスを完了するまで実行してから、バージョニングされた新しいプロセスをデプロイする必要があります。
詳細については、『WebLogic Integration Administration Console の使用』の「プロセス コンフィグレーション」にある「プロセス バージョンの管理」を参照してください。
パフォーマンスを最適化するには、プロセス トラッキング レベルを可能な限り低くします。デフォルトの none に設定し、必要に応じて選択した JPD をトラッキングします。
トラッキング レベルのコンフィグレーション方法の詳細については、『WebLogic Integration Administration Console の使用』の「プロセス コンフィグレーション」にある「プロセス コンフィグレーションについて」の「プロセス トラッキング データの管理」を参照してください。
可。ピーク時以外の時間にアーカイバ プロセスを実行して、ステートフル プロセスのプロセス モニタ テーブルをクリーン アップする必要があります。
アーカイブ プロセスのコンフィグレーション方法の詳細については、『WebLogic Integration Administration Console の使用』の「プロセス コンフィグレーション」にある「プロセス トラッキング データの管理」を参照してください。
<domain-home>/apacheLog4jCfg.xml を編集して、info をすべて warn に変更します。
インラインではなく (ドキュメント ストアを使用する) 参照渡しが効率的なドキュメント サイズのしきい値は、アプリケーションごとに異なります。通常は、ドキュメントの通信の回数が多いほど、ドキュメント ストアを使用すると効率的です。参照渡しのファイルのサイズをコンフィグレーションするには、Oracle WebLogic Integration アプリケーション ドメインの wli-config.properties ファイルにある weblogic.wli.DocumentMaxInlineSize パラメータの値を設定します。
| 注意 : | ドキュメント ストアを使用する場合、2 フェーズ コミット関連の競合状態が原因で、メッセージ SQLException in retrievData() がログに表示されることがあります。その場合、すべてのドキュメントがインラインで渡されるように weblogic.wli.DocumentMaxInlineSize の値を大きくします。 |
高速のディスク サブシステムまたはバッテリでバックアップされたキャッシング コントローラがある場合は、ファイルベースの永続性の方が、JDBC よりも大幅に高速である可能性があります。
次の表に、Oracle WebLogic Integration アプリケーションが使用する主なリソースのパラメータで、Oracle WebLogic Server Administration Console でモニタすべきパラメータと、問題と考えられる状況が発生した場合の処置を示します。
|
|
|||
|
|
|||
|
|
|||
|
|
アプリケーションを展開 EAR としてデプロイした場合、Oracle WebLogic Server Administration Console で trans-timeout-seconds の値を増やすことで、トランザクションがタイムアウトするまでの経過時間を増やすことができます。その際、Oracle WebLogic Integration アプリケーションのソース内にある同じ値を同様に変更して、アプリケーションの再デプロイ時に trans-timeout-seconds の値がデフォルト値にリセットされないようにする必要があります。
アプリケーションを展開 EAR としてデプロイしない場合は、Oracle WebLogic Server Administration Console から trans-timeout-seconds にアクセスできません。アプリケーション内で trans-timeout-seconds の値を増やしてからアプリケーションを再デプロイし、増加したタイムアウト値を反映させる必要があります。
trans-timeout-seconds の値の変更方法の詳細については、『Oracle WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「エンタープライズ JavaBean の実装」にある「デプロイメント記述子を編集する」を参照してください。
詳細については、「フラグを使用した Oracle WebLogic Server の起動とパフォーマンスの最大化」を参照してください。
JMS タイマー メッセージを減らす方法は、「トランザクションのタイムアウト期間の増加」を参照してください。
この節では、Oracle WebLogic Integration アプリケーションの回復処理のコンフィグレーションに関する質問の回答を示します。内容は以下のとおりです。
Oracle WebLogic Integration アプリケーションが次のようにコンフィグレーションされていることを確認してください。
cgPool にコンフィグレーションされている。| 注意 : | アクティブ クラスタ内の 1 つまたは複数の JMS サーバのターゲットを変更する必要がある場合は、ターゲットのコンフィグレーションを変更した後にクラスタを再起動する必要があります。 |
WLI System EJBs の WLI Admin コンポーネントのターゲットがクラスタである。WLI Admin のターゲットを確認するには、WLI System EJBs アプリケーション用の config.xml ファイルに保存されているコンフィグレーションを調べます。| 注意 : | WLI Admin のターゲットをクラスタに設定できるのは、JMS サーバのターゲットが移行可能ターゲットである場合だけです。 |
再試行回数と再試行間隔を調整する必要がある場合は、次の方法があります。
retry-count と retry-interval を JPD に設定する。retry-count と retry-interval を設定する。 | 注意 : | この方法では JPD の明示的な再試行設定を無視することになりますが、最も簡単な方法なので、この方法をお勧めします。 |
詳細については、『Oracle WebLogic Server コンフィグレーション リファレンス』の「JMSQueue」を参照してください。
config.xml ファイルの JTA 属性 TimeoutSeconds の値が、XA 接続プールの JDBCConnectionPool.XA TransactionTimeout 属性の値よりも小さく設定されている。
TimeoutSeconds の詳細については、『Oracle WebLogic Server コンフィグレーション リファレンス』の「JTA」を参照してください。
config.xml ファイルの JTA 属性である MaxTransactions の値が、回復処理の間にサーバ上で同時に発生するトランザクションの数より十分大きく設定されている。トランザクションが大量に発生するアプリケーションでは、この属性の値をデフォルト設定より大きくする必要があります。
MaxTransactions の詳細については、Oracle WebLogic Server Administration Console オンライン ヘルプの「ドメイン : コンフィグレーション : JTA」を参照してください。
config.xml ファイルの JDBCConnectionPool 属性である MaxCapacity の値が、実行キューの ThreadCount 属性の値よりも大きく設定されている。
MaxCapacity の詳細については、『Oracle WebLogic Server コンフィグレーション リファレンス』の「JDBCConnectionPool」を参照してください。
Server ThreadCount の詳細については、『Oracle WebLogic Server パフォーマンス チューニング ガイド』の「WebLogic Server のチューニング」にある「デフォルトの実行キュー スレッドのチューニング」を参照してください。
dba_2pc_pending、dba_2pc_neighbors、および dba_pending_transactions を呼び出して回復処理を実行するための適切なパーミッションがある。パーミッションがない場合は、データベース エラーが発生し、回復処理は失敗します。
不明なトランザクションが Oracle 内に出現するまでには、数分間かかる場合があります。Oracle が TM の消失を検出する前に回復処理を開始した場合、競合が発生する可能性があります。回復処理を開始する (サーバを再起動するか JTA の移行を実行する) 前に、数分間待ってください。
回復処理を開始した後で Oracle dba_2pc_pending テーブルを調べたときに、障害が発生したサーバに関連するレコードがあり、そのタイムスタンプが回復処理の開始時刻よりも前である場合、回復処理は失敗します。サーバを再起動してください。
|