2 主なパフォーマンス分野

この章では、Oracle Fusion Middlewareの主なチューニング分野について説明します。取り上げるのは、Oracle Fusion Middlewareの重要なパフォーマンス分野です。Javaアプリケーションのチューニングにおけるクイック・スタート・ガイドとなります。内容は次のとおりです。

第2.1項「主なパフォーマンス分野の特定」
第2.2項「十分なハードウェア・リソースの確保」
第2.3項「オペレーティング・システムのチューニング」
第2.4項「Java仮想マシン(JVM)のチューニング」
第2.5項「WebLogic Serverのチューニング」
第2.6項「データベース・パラメータのチューニング」
第2.7項「データベース接続の再利用」
第2.8項「データ・ソースの文キャッシュの有効化」
第2.9項「同時実行性の制御」
第2.10項「ロギング・レベルの設定」

2.1 主なパフォーマンス分野の特定

パフォーマンス・チューニングの最も難しい面の1つは、どこから始めればよいかを知ることです。この章は、Oracle Fusion Middlewareアプリケーションのパフォーマンス・チューニングにおけるクイック・スタート・ガイドの役割を果します。

表2-1は、Oracle Fusion Middlewareのパフォーマンスに関する一般的な考慮事項をリストにまとめたものです。このリストは、パフォーマンス・チューニングを始めるうえで有効なツールとなりますが、チューニングが必要な分野をすべて網羅してはいません。アプリケーションにおけるパフォーマンスの問題を個別に監視、追跡し、どこをチューニングすればパフォーマンスが向上するかを把握する必要があります。詳細は、第4章「Oracle Fusion Middlewareの監視」を参照してください。

表2-1 Oracle Fusion Middlewareの主なパフォーマンス分野

パフォーマンス分野	説明と参照先
ハードウェア・リソース	パフォーマンスを最大化するために、アプリケーションのリソース要件と同等またはそれ以上のハードウェア・リソースがあることを確認します。ハードウェア・リソースが十分かどうかを判断する方法の詳細は、第2.2項「十分なハードウェア・リソースの確保」を参照してください。
オペレーティング・システム	各オペレーティング・システムには、監視用の便利なネイティブ・ツールおよびユーティリティが用意されています。第2.3項「オペレーティング・システムのチューニング」を参照してください。
Java仮想マシン(JVM)	この項では、ベスト・プラクティスについて説明し、JVMのチューニングおよびJava EEアプリケーションのパフォーマンス向上に役立つ実用的なヒントを示します。ヒープ・サイズおよびJVMガベージ・コレクション関連のオプションについても説明します。第2.4項「Java仮想マシン(JVM)のチューニング」を参照してください。
データベース	データベースにアクセスするアプリケーションの場合は、データベースがアプリケーションの要件に合せて正しく構成されていることを確認します。ガベージ・コレクションの詳細は、第2.6項「データベース・パラメータのチューニング」を参照してください。
WebLogic Server	Oracle Fusion MiddlewareアプリケーションがWebLogic Serverを使用している場合は、第2.5項「WebLogic Serverのチューニング」を参照してください。
データベース接続	接続を再利用するための接続プーリングは、チューニングの際の重要な考慮事項です。第2.7項「データベース接続の再利用」を参照してください。
データ・ソースの文キャッシュ	データベースを使用するアプリケーションの場合は、文キャッシュを正しく構成することで、繰り返し実行される文の解析および作成がパフォーマンスに与える影響を軽減できます。第2.8項「データ・ソースの文キャッシュの有効化」を参照してください。
Oracle HTTP Server	Oracle HTTP Serverディレクティブをチューニングし、HTTP接続数を指定して同時実行性のレベルを設定します。第2.9項「同時実行性の制御」を参照してください。
同時実行性	この項では、Oracle Fusion Middlewareコンポーネントに対する同時実行性の制御方法について説明します。第2.9項「同時実行性の制御」を参照してください。
ロギング・レベル	ロギング・レベルは、ログに記録される情報の量を制御するためにシステム管理者が設定するしきい値です。アプリケーションがログに記録する情報の量はパフォーマンスに影響を与えるため、ロギング・レベルを正しく設定することが重要です。第2.10項「ロギング・レベルの設定」を参照してください。

2.2 十分なハードウェア・リソースの確保

Oracle Fusion Middlewareアプリケーションのパフォーマンス管理における重要な要素は、システムのユーザー要件とアプリケーション要件を満たす十分なCPU、メモリーおよびネットワーク・リソースがあることを確認することです。

どれほど適切にアプリケーションをチューニングしても、適切なハードウェア・リソースがなければ、アプリケーションのパフォーマンスは最適なレベルに達しません。Oracle Fusion Middlewareのアプリケーションおよびデータベース層には、最小限のハードウェア要件があります。Oracle Fusion Middlewareがサポートする構成の詳細は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のシステム要件と前提条件に関する項を参照してください。

ハードウェア・リソースが十分であるとは、飽和状態にならずに、アプリケーションで許容されるレベルと同等またはそれ以上のレスポンス時間およびスループットを達成できることです。十分なハードウェア・リソースがあることを確認するには、リソース使用率を長期間にわたって監視し、使用率が一時的にピークに達することがあるのか(あるとすればそれはいつか)、それともリソースが常に飽和状態にあるのかを調べる必要があります。監視の詳細は、第4章「Oracle Fusion Middlewareの監視」を参照してください。

ヒント:

CPU使用率が決して100%に達しないようにする必要があります。目標とするCPU使用率は、アプリケーションのニーズ(ピーク時のCPUサイクルなど)に基づいて決定してください。

通常負荷時のCPU使用率が100%になるように最適化した場合、ピーク時の負荷を処理するキャパシティは残っていません。待機時間の影響を受けやすく、高速のレスポンス時間を維持することが重要な意味を持つアプリケーションでは、CPU使用率が高い(100%に近づく)と、レスポンス時間が長くなる一方で、スループットは一定に保たれるか、低下します。このようなアプリケーションの場合、推奨されるCPU使用率は70から80%です。待機時間の影響を受けないアプリケーションの場合は、90%程度を目標とすることをお薦めします。

飽和状態になっている(使用率が常に100%か、それに近い)ハードウェア・リソースが1つでもある場合は、次の状況のうち1つ以上が発生している可能性があります。

アプリケーションを実行するのに十分なハードウェア・リソースがない。
システムが正しく構成されていない。
アプリケーションまたはデータベースのチューニングが必要である。

リソースが常に飽和状態にある場合の解決策は、負荷を減らすか、リソースを増やすことです。レスポンス時間の増大が許されないピーク・トラフィック時については、リソースを増やすことを検討するか、トラフィックをスケジュールしなおして(オフピーク時にバッチ処理やバックグラウンド処理をスケジュールするなど)ピーク時の負荷を減らせるかどうか確認してください。

Oracle Fusion Middlewareには、リソースの同時使用を制御する各種メカニズムが用意されています。これにより、トラフィックの急増による影響を抑えることができます。ただし、常に飽和状態にあるシステムでは、こうしたメカニズムも一時的な解決策にすぎません。詳細は、第2.9項「同時実行性の制御」を参照してください。

2.3 オペレーティング・システムのチューニング

各オペレーティング・システムには、監視やチューニングを目的とする便利なネイティブ・ツールおよびユーティリティが用意されています。オペレーティング・システムのネイティブ・コマンドを使用すれば、CPU使用率、ページング・アクティビティ、スワッピング、その他のシステム・アクティビティ情報を監視できます。

オペレーティング・システム・コマンドの詳細と、ネットワークまたはオペレーティング・システムのパフォーマンス・チューニングに関するガイドラインは、オペレーティング・システム・ベンダー提供のドキュメントを参照してください。

2.4 Java仮想マシン(JVM)のチューニング

Java仮想マシン(JVM)をどのようにチューニングするかによって、Oracle Fusion Middlewareおよびアプリケーションのパフォーマンスが大きく変わります。JVMのチューニングの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング』の「Java仮想マシン(JVM)のチューニング」を参照してください。

2.5 WebLogic Serverのチューニング

Oracle Fusion MiddlewareアプリケーションがWebLogic Serverを使用している場合は、『Oracle Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング』の「WebLogic Serverのチューニング」を参照してください。

2.6 データベース・パラメータのチューニング

Oracleデータベースを使用するアプリケーションのパフォーマンスを最適化するには、アクセスの対象となるデータベース表を、パフォーマンスを念頭に置いて設計する必要があります。データベースの監視およびチューニングを行えば、アプリケーションから最適なパフォーマンスを確実に得ることができます。

注意:

この項の情報はFusion Middlewareのデータベース・チューニング情報のサブセットです。詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。必ず、データベース・チューニングに関するドキュメントも確認してください。

この項の内容は次のとおりです。

データベース・パラメータのチューニング
REDOログの場所およびサイズのチューニング
「自動セグメント領域管理(ASSM)のチューニング」

注意:

必ず、ご使用のデータベースのベンダー・ドキュメントでチューニングに関するガイドラインを確認してください。Oracleデータベースのチューニングの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

2.6.1 データベース・パラメータのチューニング

次の表は、一般的なinit.oraパラメータとその説明をまとめたものです。データベース・パラメータを設定する際には、表に記載されたガイドラインを考慮してください。ただし、最終的にはDBAがデータベースの状態を監視し、必要に応じてパラメータをチューニングする必要があります。詳細は、表2-2を参照してください。

表2-2 Oracle 11gの重要なinti.oraデータベース・チューニング・パラメータ

データベース・パラメータ	説明
AUDIT_TRAIL	DBアクティビティを監査するポリシーがない場合は、このパラメータをNONEに設定することを検討してください。監査を有効にすると、パフォーマンスに影響が出る可能性があります。
MEMORY_MAX_TARGET	MEMORY_MAX_TARGETには、DBAがMEMORY_TARGET初期化パラメータに設定できる最大値を指定します。
MEMORY_TARGET	MEMORY_TARGETをNONEに設定することを検討してください。MEMORY_TARGET設定によって必要に応じてSGAおよびPGAに十分なメモリーが割り当てられないとき、SGAおよびPGAを個別に設定します。
PGA_AGGREGATE_TARGET	最初にPGAに値1Gを使用することを検討してください。その後、本番データベースを日次ベースで監視し、それに応じてSGAおよびPGAを調整します。データベース・サーバーのメモリーに余裕がある場合は、PGA_AGGREGATE_TARGETを使用ニーズに基づいて1Gより大きい値に設定することを検討してください。
SGA_MAX_SIZE	SGAとPGAを別々に設定するかわりに、MEMORY_TARGETを設定することを検討してください。
SGA_TARGET	最初にSGAに値2Gを使用することを検討してください。その後、本番データベースを日次ベースで監視し、それに応じてSGAおよびPGAを調整します。データベース・サーバーのメモリーに余裕がある場合は、SGA_TARGETを使用ニーズに基づいて2Gより大きい値に設定することを検討してください。

2.6.2 REDOログの場所およびサイズのチューニング

REDOログ・オプションをチューニングすると、Oracle Fusion Middleware環境で稼働しているアプリケーションのパフォーマンスを改善できます。また、REDOログを別のディスクに移動することで、I/Oスループットを大幅に改善できる場合もあります。

サイズが2GのREDOログ・グループを3つ以上保持することを検討してください。I/Oパフォーマンスを向上させるには、REDOログ・ファイルをデータ・ファイルとは別のディスク上に配置してください。

2.6.3 自動セグメント領域管理(ASSM)のチューニング

永続表領域については、自動セグメント領域管理の使用を検討してください。ビットマップ表領域と呼ばれることも多い永続表領域は、ビットマップ・セグメント領域管理によってローカルに管理される表領域です。

後方互換性を確保するために、ローカル表領域のデフォルトのセグメント領域管理モードはMANUALに設定されています。

表領域を構成する際は、エクステント割当てタイプをSYSTEMに設定することを検討してください。割当てタイプをUNIFORMに設定すると、パフォーマンスに影響を与える場合があります。

詳細は、『Oracle Database概要』の空き領域管理に関する項、および『Oracle Database管理者ガイド』のローカル管理表領域のセグメント領域管理の指定に関する項を参照してください。

2.7 データベース接続の再利用

データベース接続の作成は、環境を問わず、比較的リソース消費量の多いプロセスです。通常、起動時の接続プールには少数の接続が含まれています。クライアントからの接続の要求が増えるにつれて、プール内の接続が不足し、要求を満たせなくなることがあります。WebLogic Serverは、最大プール・サイズに達するまで、接続をさらに作成してプールに追加します。

接続作成の遅れを回避する1つの方法は、クライアントの要求に応じて接続を初期化するのではなく、サーバー起動時にすべての接続を初期化することです。この方法は、負荷が一定で、予測可能な場合に適しています。データ・ソース構成の「接続プール」タブで、初期接続数を最大接続数と同一に設定します。本番前のパフォーマンス・テストの一環として、「最大容量」の最適な値を決定します。

負荷が一定せず、ピーク負荷時の接続数が通常負荷時の接続数よりかなり多い場合は、初期接続数を通常負荷時と同一に設定することを検討してください。さらに、対応可能なピーク負荷に基づいて最大接続数を設定することを検討してください。このように構成すれば、WebLogic Serverは一定期間にわたって使用されていない接続を解放できます。

詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のデータ・ソース接続プール・オプションのチューニングに関する項を参照してください。

2.8 データ・ソースの文キャッシュの有効化

アプリケーションまたはEJBでプリコンパイル文やコール可能文を使用すると、アプリケーション・サーバーとデータベース・サーバーの間の通信の処理、およびデータベース・サーバー上での処理に伴って、パフォーマンスに影響が出ることがあります。処理への影響を最小限に抑えるには、アプリケーションで使用されるプリコンパイル文およびコール可能文をデータ・ソースがキャッシュできるようにします。アプリケーションまたはEJBがキャッシュに格納された文をコールした場合、サーバーはキャッシュに格納された文を再利用します。プリコンパイル文およびコール可能文を再利用することで、データベース・サーバーのCPU使用率が低下します。その結果、現在の文のパフォーマンスが向上し、CPUサイクルを他のタスクに割り当てられるようになります。

データ・ソース内の各接続には、その接続で使用されるプリコンパイル文およびコール可能文の専用キャッシュがあります。ただし、文キャッシュ・オプションはデータ・ソースごとに構成します。つまり、データ・ソースに指定した文キャッシュ・オプションはそのデータ・ソース内の各接続の文キャッシュで使用されますが、文は接続ごとにキャッシュされます。文キャッシュの構成オプションは次のとおりです。

文キャッシュ・タイプ: 文キャッシュにどの文を格納するかを決定するアルゴリズム。
文キャッシュ・サイズ: 各接続についてキャッシュに格納する文の数。デフォルト値は10です。データベースの文解析メトリックを分析したうえで、文キャッシュはアプリケーションで使用する文の数に十分対応できるサイズに設定してください。

管理コンソールを使用して、データ・ソースの文キャッシュ・オプションを設定できます。Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「JDBCデータ・ソースの文キャッシュの構成」を参照してください。

文キャッシュの使用の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』の文キャッシュによるパフォーマンスの向上に関する項を参照してください。

2.9 同時実行性の制御

システムの複数のレイヤーで個別の使用ニーズに合せて同時実行性を制限すると、パフォーマンスを大幅に改善できます。この項では、Oracle Fusion Middlewareの中で同時実行性の制御が可能ないくつかの分野について説明します。

システムのキャパシティに達した後も、Webサーバーやアプリケーション・サーバーがリクエストを受け付け続けると、アプリケーションのパフォーマンスおよび安定性が低下します。Oracle Fusion Middlewareには、リクエストを抑制して中間層またはデータベース層のシステムが過負荷の状態になることを避け、最適なパフォーマンスが得られるようチューニングすることのできる分野があります。

サーバー接続制限の設定
「接続プールの構成」
WebLogic Severのスレッド・プールのチューニング

2.9.1 サーバー接続制限の設定

Oracle HTTP Serverでは、httpd.confのディレクティブが使用されます。この構成ファイルには、同時に処理可能なHTTPリクエストの最大数、ロギング詳細、ならびに特定の制限およびタイムアウトが指定されています。

httpd.confファイルの変更の詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』のOracle HTTP Serverの構成に関する項を参照してください。

MaxClientsディレクティブおよびThreadsPerChildディレクティブを使用すると、予想されるクライアント負荷およびシステム・リソースに基づいて、Oracle HTTP ServerからWebLogicインスタンスへの受信リクエストを制限できます。次の各項では、接続制限に関連するOracle HTTP Serverチューニング・パラメータについて説明します。これらは通常、予想されるクライアント負荷に基づいてチューニングする必要があります。詳細とチューニング可能なパラメータの詳しいリストは、第6章「Oracle HTTP Serverのパフォーマンス・チューニング」を参照してください。

2.9.1.1 MaxClients/ThreadsPerChild

注意:

MaxClientsパラメータはUNIXプラットフォームにのみ適用されます。Microsoft Windows (mpm_winnt)では、ThreadsPerChildパラメータとThreadLimitパラメータで同じ機能が実現されています。

MaxClientsプロパティに、稼働しているサーバー・スレッドの総数に対する制限、つまり同時に接続可能なクライアントの数に対する制限を指定します。クライアント接続数がこの制限に達すると、その後のリクエストは、(ListenBackLogディレクティブで)指定した制限に達するまでTCP/IPシステムのキューに入れられます。

MaxClientsディレクティブはhttpd.confファイルで構成でき、最大値は8K(デフォルト値は150)です。システム・リソースが飽和状態でなく、HTTPの同時接続ユーザー数が150を超えている場合は、MaxClientsを大きくしてサーバーの同時実行性を高めると、パフォーマンスが向上します。システムの利用状況がフル(目安は85%)になるまで、MaxClientsを大きくします。

システム・リソースが飽和状態のときにMaxClientsを大きくしても、パフォーマンスは向上しません。この場合は、サーバーへの同時リクエスト数に対するスロットルとして、MaxClientsの値を小さくします。

サーバーが永続的な接続を処理する場合は、アクティブな接続とアイドルな接続の両方を処理するために十分な数の同時httpdサーバー・プロセスが必要になります。システムの同時実行性に対するスロットルとしてMaxClientsを指定する際に、アイドル状態の永続的なhttpd接続もhttpdプロセスを消費することを考慮に入れる必要があります。つまり、接続数には、現在アクティブな永続的接続および非永続的接続と、アイドルな永続的接続が含まれます。使用可能なhttpdサーバー・スレッドがない場合、接続リクエストはスレッドが使用可能になるまでTCP/IPシステムのキューに入れられます。最終的には、クライアントが接続を終了します。

Oracle HTTP Serverへの着信接続を処理するサーバー・プロセスの数、および1プロセス当たりのスレッドの数(ThreadsPerChild)を定義できます。ThreadsPerChildプロパティには、サーバー(子)・プロセスの下に作成可能なスレッドの数の上限を指定します。

注意:

ThreadsPerChild、StartServers、ServerLimitの各プロパティは、MaxClients設定と相互に関係しています。MaxClientsで指定した数の接続を得るには、これらのプロパティをすべて正しく設定する必要があります。すべてのHTTP構成プロパティの説明は、表6-1「Oracle HTTP Server構成プロパティ」を参照してください。

2.9.1.2 KeepAlive

永続的(KeepAlive)なHTTP接続は、接続リクエストの処理中でなくても、接続期間中はhttpd子プロセス(スレッド)を消費します。

十分なキャパシティがある場合は、KeepAliveを有効にしてください。永続的な接続を使用することで、パフォーマンスが向上し、HTTP接続の再確立によるCPUリソースの浪費が回避されます。通常、KeepAliveパラメータの変更は不要です。

注意:

永続的な接続に対するデフォルトの最大リクエスト数は100です。これはhttpd.confのMaxKeepAliveRequestsディレクティブで指定されています。デフォルトでは、サーバーはクライアントからのリクエストを15秒間待ってから接続をクローズします。これはhttpd.confのKeepAliveTimeoutディレクティブで指定されています。

2.9.1.3 HTTP Serverモジュールのチューニング

Oracle HTTP Server (OHS)は、mod_wl_ohsモジュールを使用して、基礎となるWeblogic ServerまたはWeblogic Serverクラスタへリクエストを転送します。mod_wl_ohsの構成の詳細は、configディレクトリのmod_wl_ohs.confファイルで確認できます。

mod_wl_ohsのチューニング・パラメータの詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』の「Oracle HTTP Serverモジュールの理解」を参照してください。

2.9.2 接続プールの構成

接続プーリングは、Javaランタイムごとに構成および保守します。接続は、異なるランタイム間で共有されません。接続プーリングを使用するのに、構成は必要ありません。構成が必要なのは、プール・サイズやプールされる接続のタイプを制御するなど、プーリングの実行方法をカスタマイズする場合のみです。

接続プーリングは、プログラムの起動時にシステム・プロパティの数を使用して構成します。これらは環境プロパティではなくシステム・プロパティであるため、すべての接続プーリング・リクエストに作用することに注意してください。

データベースを使用するアプリケーションの場合、データ・ソースに関連付けられている接続プールの接続数を制限すると、パフォーマンスが向上します。MaxCapacity属性を使用してOracle Application Serverからのデータベース・リクエストを制限することで、受信リクエストが原因でデータベースが飽和状態になったり、データベース・アクセスが原因でOracle Application Server層のリソースが過負荷状態になったりすることを回避できます。

接続プールのMaxCapacity属性は、接続プールに作成できる接続の最大数を示します。デフォルトでは、MaxCapacityの値は15に設定されています。最適なパフォーマンスを得るには、データベースのパフォーマンス特性に適した数値をMaxCapacityに指定してください。

オープンしているデータベース接続の総数を、データベースで処理可能な数に制限することは、チューニングの際の重要な考慮事項です。データベースが、すべてのデータ・ソースのMaxCapacityオプションで指定されている値の合計と同じ数以上の接続をオープンできるよう構成されていることを確認してください(このオプションはデータベースにアクセスするすべてのアプリケーションで指定されています)。

2.9.3 WebLogic Severのスレッド・プールのチューニング

デフォルトでは、WebLogic Serverが使用するスレッド・プールは1つであり、その中であらゆるタイプの作業が実行されます。WebLogic Serverは、ワーク・マネージャを使用し、ユーザー定義ルールおよびランタイム・メトリック(リクエストの実行に要する実際の時間や、リクエストがプールに入る頻度とプールを出る頻度など)に基づいて処理の優先度を決定します。共通のスレッド・プールを管理するデフォルトのワーク・マネージャが存在します。

共通のスレッド・プールのサイズは、スループットが最大になるように自動的に変化します。WebLogic Serverでは、履歴に基づいてスループットを長期的に監視し、スレッド数の調整が必要かどうかを判断しています。たとえば、過去のスループット統計から、スレッド数を増やしたらスループットが向上したと判明した場合は、スレッド数を増やします。同様に、スレッド数を減らしてもスループットが低下しなかったと統計から判明した場合は、スレッド数を減らします。

WebLogic Serverのスレッド・プールのサイズはデフォルトで自動的に設定されるため、チューニングの必要はないことがほとんどです。ただし、特殊な要件がある場合は、管理者がカスタム・ワーク・マネージャを構成して、同様のパフォーマンス要件、可用性要件または信頼性要件を持つリクエスト・セットごとに、スレッド・プールをきめ細かく管理できます。カスタム・ワーク・マネージャでは、保留中の作業の割当て方法に関する優先度およびガイドラインを定義できます。たとえば、最小スレッド数または最大スレッド数に対する制約や、WebLogic Serverがリクエストを拒否し始めるまでにキューに入れる、または実行することのできるリクエストの総数に対する制約を指定します。

ワーク・マネージャを使用してスレッド管理をカスタマイズする必要があるかどうかは、次のガイドラインを基に判断してください。

デフォルト値では不十分である。

通常、これが該当するのは、特定のアプリケーションに他のアプリケーションより高い優先度を付ける必要がある場合です。
レスポンス時間の目標を設定する必要がある。
最小スレッド数制約を指定して、サーバーのデッドロックを回避する必要がある。
アプリケーションでMDBを使用している。

MDBに割り当てるサーバー・スレッド・リソースを明確に定義して、それをMDBに確実に使用させる場合や、MDBの同時実行性をチューニングする場合は、最大スレッド数制約が指定されたカスタム・ワーク・マネージャを参照するように、ほとんどのMDBを変更する必要があります。一般に、カスタム・ワーク・マネージャが便利なのは、複数のMDBデプロイメントが存在する場合や、特定のMDBが多くのスレッドを必要とする場合です。

2.10 ロギング・レベルの設定

アプリケーションがログに記録する情報の量は、環境の構成およびアプリケーション・コードのインストゥルメント状況によって異なります。パフォーマンスを最大化するには、デフォルトのINFOレベルより高いロギング・レベルを設定しないでください。ロギング設定がデフォルト・レベルと異なる場合は、最適なパフォーマンスが得られるよう、ロギング・レベルをデフォルトに戻します。

アプリケーションおよびサーバーのロギング・レベルを正しく設定したら、デバッグ・プロパティやアプリケーション・レベルのその他のデバッグ・フラグが適切なレベルに設定されているか、または無効になっていることも確認します。パフォーマンスへの影響を回避するには、ロギング・レベルを、より多くの診断メッセージが生成されるレベル(FINEレベルまたはTRACEレベル)に設定しないでください。

コンポーネントごとに、特定の推奨ロギング・レベルがあります。詳細は、このドキュメントの該当するコンポーネントの章を参照してください。