|
|
この節では、プロダクション環境でチューニングできる WLI パラメータについて説明します。ここでは、以下のトピックについて説明します。
WLI ドメイン ディレクトリにある ApacheLog4jCfg.xml は、WLI BPM のロギング コンフィグレーションおよびロギング レベルを指定します。デバッグおよびテスト目的で、そのようなメッセージが必要な場合にのみ、priority レベルを「debug」または「info」に設定してください。プロダクション環境では、すべてのログ アペンダの priority 値を「warn」または「error」に設定する必要があります。
WLI では、以下の JDBC データ ソースを使用します。
これらの JDBC データ ソースを監視し、初期容量、最大容量、および増加容量の値を変更して、接続プールで、適切な数の接続を使用できるようにする必要があります。接続プールの InitialCapacity を MaxCapacity に設定して、プールの拡張または縮小にかかる時間が発生しないようにすることをお勧めします。
アプリケーションがデータベースに大きく依存している場合は、以下を考慮してください。
アプリケーションがデータ ソースからのデータベース接続を予約するのにかかる時間を最小限にし、データベース接続用のスレッド間の競合を削減するために、データ ソースの Pinned-To-Thread プロパティを有効にできます。ただし、このプロパティを設定すると、実行スレッドとの接続が保持され、接続が接続プールに返されません。プールに接続が含まれていない場合、追加の接続が作成されます。これらの接続は、MaxCapacity で指定した値を上回ります。そのため、PinnedToThread プロパティは、パフォーマンスが向上する場合にのみ使用してください。
詳細については、『WebLogic Server パフォーマンス チューニング ガイド』の「Pinned-To-Thread プロパティの使用によるパフォーマンスの向上」を参照してください。
アプリケーションまたは EJB でプリペアド ステートメントや呼び出し可能ステートメントを使用すると、アプリケーション サーバとデータベース サーバの間の通信およびデータベース サーバ自体において、相当の処理オーバーヘッドが生じます。処理コストを最小限に抑えるため、WLS ではアプリケーションで使用するプリペアド ステートメントおよび呼び出し可能ステートメントをキャッシュできます。最長時間未使用 (LRU) アルゴリズムを使用し、キャッシュ サイズをアプリケーションで実行されるステートメントの数に設定することをお勧めします。正確なキャッシュ サイズは試行錯誤を繰り返して決定します。
詳細については、『WebLogic JDBC のコンフィグレーションと管理』の「ステートメント キャッシュによるパフォーマンスの向上」および「データ ソース接続プール オプションのチューニング」を参照してください。
デフォルトでは、WLS のセルフチューニングにより、16 のスレッドが AsyncDispatcher に割り当てられます。別個のワークマネージャを AsyncDispatcher に追加し、追加のスレッドを割り当てることができます。これにより、追加の AsyncDispatcher MDB インスタンスが作成されます。
JPD プロジェクトのすべての JPD が、同じ AsyncDispatcher MDB を使用します。以下のシナリオでは、プロジェクトをさらに小さなプロジェクトに分割することを検討してください。
詳細については、「メッセージ駆動型 Bean のチューニング」の「同時 MDB の数の確定」を参照してください。
WLI では、プロジェクトごとに以下の EJB があります。
これらの EJB のプール サイズをチューニングして、高負荷を処理できます。同じプロジェクトの 2 つ以上の JPD が、同じ EJB を共有します。以下のシナリオでは、プロジェクトをさらに小さなプロジェクトに分割することを検討してください。
これらの EJB の EJB プールのチューニング方法については、「WebLogic Server EJB のチューニング」の「EJB プールのチューニング」を参照してください。
デフォルトでは、HTTP を使用した、プールされた接続は、ホストあたりで 2 つです。ホストあたりのプール サイズを増加させるには、以下のシステム プロパティを使用できます。
wli.httpcontrolmaxconnectionsperhost
デフォルトでは、HTTP を使用した、プールされた接続は、すべてのホストで 20 です。すべてのホストのプール サイズを増加させるには、以下のシステム プロパティを使用できます。
wli.httpcontrolmaxtotalconnections
WLI では、conversational-jms モジュールで、多数の内部キューを使用します。デフォルトでは、これらのキューのほとんどが、永続 JDBC ストアを使用します。
キューで JDBC 永続性が必要ない場合は、「Non-Persistent」に変更するか、または、ファイル永続性パラメータを使用できます。キューを Non-Persistent に変更すると、プロセス インスタンス情報用に使用される wli.internal.instance.info.buffer キューは、WLI のパフォーマンスを大幅に向上できます。
| 注意 : | キューの永続性を変更すると、サーバまたはマシンで予期しないクラッシュが発生した場合に、データの消失の原因となる可能性があります。 |
詳細については、『WebLogic Server パフォーマンス チューニング ガイド』の「WebLogic 永続ストアのチューニング」および「WebLogic JMS のチューニング」を参照してください。
デフォルトでは、WLI ドメイン ディレクトリに作成される JMS EG アプリケーションの max-beans-in-free-pool は 5 に設定されています。
プール サイズを増加して、パフォーマンスの向上を試みることができます。16 を超える MDB インスタンスが必要な場合は、EG のディスパッチポリシーとして、最小および最大スレッド制約で、ワークマネージャにより多くのスレッドを割り当てることができます。
詳細については、「メッセージ駆動型 Bean のチューニング」の「同時 MDB の数の確定」を参照してください。
WLI ドメイン ディレクトリにある wli-config.properties の weblogic.wli.DocumentMaxInlinSize パラメータは、SQL ドキュメント ストアに格納されるドキュメントの最大サイズを指定します。ドキュメント (着信メッセージ) が weblogic.wli.DocumentMaxInlinSize で指定されている値よりも大きい場合、メッセージには、ドキュメント参照のみが含まれます。そうでない場合は、ドキュメントはコピーとして渡されます。メッセージが大きく、ドキュメント ストアが頻繁にアクセスされる場合、結果として、データベース I/O が増加し、メモリの使用率が低下します。そのため、しきい値が重要になります。
メッセージ トラッキングを使用して、メッセージのサイズを決定できます。しきい値をチューニングして、パフォーマンスを向上します。多数の JPD 間でドキュメントが交換される場合は、複数の JPD に同じデータを渡すのではなく、ドキュメント ストアを使用して、JPD に関連するドキュメント参照を渡すことができます。
表 B-1 は、プロセスのトラッキングのさまざまなレベルと生成されるイベントを示しています。パフォーマンスの観点で見た場合、プロセスのトラッキングのレベルを none から full に変更するに従い、システムのパフォーマンスは低下します。
NONE を FULL に変更すると、より多くのイベントが生成されます。これらのイベントにより、プロセス インスタンス情報およびプロセス トラッキング データに関する追加のデータベース オペレーションが発生します。高いレベルのプロセス トラッキングによって影響を受ける WLI_PROCESS_EVENT テーブルをパーティション化できます。
パーティション化の詳細については、『Oracle9i データベース チューニング ガイド』の「WLI_PROCESS_EVENT テーブル」を参照してください。プロセスのトラッキングの詳細については、『WebLogic Integration Administration Console の使用』の「プロセス トラッキング データ」を参照してください。
トレーディング パートナ統合の場合、以下のレベルのメッセージ トラッキングが提供されます。
メッセージ トラッキングのレベルを None から All に変更すると、データベース オペレーションによりパフォーマンスが影響を受ける場合があります。詳細については、『WebLogic Integration Administration Console の使用』の「トレーディング パートナ管理のコンフィグレーション」を参照してください。
データベースの負荷が高いシナリオでは、ワークリスト レポート機能により、パフォーマンスが影響を受ける場合があります。この機能は、レポートのための追加のデータベース オペレーションを必要とします。別個のレポート データソースを p13ndatasource 以外のデータベース マシンに指定して、レポート ストアを異なるデータベース マシンに移動することをお勧めします。
デフォルトのレポート ストアの詳細については、『Worklist の使い方』の「デフォルトのレポート ストア」を参照してください。
すべてのワークリスト タスクのデータを一度にフェッチしようとしないでください。データベースに大量のタスクが含まれていると、システムが低速になります。WorklistTaskQuery.getTaskDataCursor を使用して、データベースから最大で 1000 のタスクをフェッチできます。WorklistTaskDataCursor は、batchSize での指定に従って、バッチでタスクをフェッチします。
WLI JMS コントロールを使用する場合、WLI JMS コントロールの send-with-xa アノテーションを true に設定して、WLI のパフォーマンスを向上することができます。
テスト コンソールは、すべてのログを JVM ヒープに格納します。システムのパフォーマンスが影響を受けないように、ログをクリアする必要があります。
デフォルトでは、テスト コンソール (setDomainEnv ファイルの testConsoleFlag) は、開発ドメインでは有効に、プロダクション ドメインでは無効になっています。デバッグ目的で必要な場合以外は、プロダクション システムでは、テスト コンソールを有効にしないでください。
|
