|
|
この節では、プロダクション環境でチューニングできる WLI パラメータについて説明します。ここでは、以下のトピックについて説明します。
WLI ドメイン ディレクトリにある ApacheLog4jCfg.xml は、WLI BPM のロギング コンフィグレーションおよびロギング レベルを指定します。デバッグおよびテストを目的としてそのようなメッセージが必要な場合にのみ、priority レベルを「debug」または「info」に設定してください。プロダクション環境では、すべてのログ アペンダの priority 値を「warn」または「error」に設定する必要があります。
ワークリスト アプリケーションでは Log4j だけでなく WebLogic Server のログも作成されるため、WebLogic Server コンソールでデバッグ レベルを設定する必要があります。詳細については、「JMS サーバ : ロギング」を参照してください。
WLI では、以下の JDBC データ ソースを使用します。
これらの JDBC データ ソースをモニタし、初期容量、最大容量、および増加容量の値を変更して、適切な数の接続を接続プールで使用できるようにする必要があります。接続プールの InitialCapacity を MaxCapacity に設定して、プールの拡張または縮小にかかる時間が発生しないようにすることをお勧めします。
アプリケーションがデータベースに大きく依存している場合は、以下を考慮に入れてください。
アプリケーションがデータ ソースからのデータベース接続の予約にかかる時間を最小限にし、データベース接続用のスレッド間の競合を削減するために、データ ソースの Pinned-To-Thread プロパティを有効にできます。ただし、このプロパティを設定すると、実行スレッドとの接続が保持され、接続が接続プールに返されません。プールに使用できる接続がない場合は、追加の接続が作成されます。これらの接続は、MaxCapacity で指定した値を超えて作成されます。したがって、PinnedToThread プロパティは、パフォーマンスが向上する場合にのみ使用するようにしてください。
詳細については、『WebLogic Server パフォーマンス チューニング ガイド』の「Pinned-To-Thread プロパティの使用によるパフォーマンスの向上」を参照してください。
アプリケーションまたは EJB でプリペアド ステートメントや呼び出し可能ステートメントを使用すると、アプリケーション サーバとデータベース サーバの間の通信およびデータベース サーバ自体において、相当の処理オーバーヘッドが生じます。処理コストを最小限に抑えるため、WLS ではアプリケーションで使用するプリペアド ステートメントおよび呼び出し可能ステートメントをキャッシュできます。最長時間未使用 (LRU) アルゴリズムを使用し、キャッシュ サイズをアプリケーションで実行されるステートメントの数に設定することをお勧めします。正確なキャッシュ サイズは試行錯誤を繰り返して決定します。
詳細については、『WebLogic JDBC のコンフィグレーションと管理』の「ステートメント キャッシュによるパフォーマンスの向上」および「データ ソース接続プール オプションのチューニング」を参照してください。
WebLogic Server ワーク マネージャのデフォルト コンフィグレーションでは、特定の JPD プロジェクトで処理できる AsyncDispatcher リクエストの数が最大 16 個に制限されます。つまり、そのプロジェクトの非同期リクエストを処理するスレッドの最大数は 16 です。システムの CPU バインド処理でこれだけの数のスレッドを使用するとは限りません。WebLogic Server では、スループットを最適化するため、スレッドの数が動的にチューニングされます。ただし、WLI アプリケーションでよく見られる入出力バインド処理については、プロジェクトに別個のワーク マネージャをコンフィグレーションすることでこの制限を解除できます。
別個のワークマネージャを AsyncDispatcher に追加してより多くのスレッドを割り当てることで、より多くの AsyncDispatcher MDB インスタンスが作成されます。
JPD プロジェクトのすべての JPD が、同じ AsyncDispatcher MDB を使用します。以下の場合は、プロジェクトをさらに小さなプロジェクトに分割することを検討してください。
詳細については、『WebLogic Server パフォーマンス チューニング ガイド』の「同時 MDB の数の確定」を参照してください。
デフォルトでは、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 アプリケーションはセルフ チューニングされるため、デフォルトでは 16 個の MDB インスタンスが含まれています。
プール サイズを大きくして、パフォーマンスが向上するかどうか試すことができます。16 を超える MDB インスタンスが必要な場合は、EG のディスパッチポリシーとして、最小および最大スレッド制約でワークマネージャにより多くのスレッドを割り当てることができます。
詳細については、『WebLogic Server パフォーマンス チューニング ガイド』の「同時 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) は、開発ドメインではデフォルトで有効に、プロダクション ドメインではデフォルトで無効になっています。デバッグを目的として使用する場合以外は、プロダクション システムでテスト コンソールを有効にしないようにしてください。
JPD プロセスのメタデータ キャッシュの動作は、以下のいずれかの方法で制御できます。
  
|