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