|
|
|
|
|
|
| | | |
WebLogic Server アプリケーションのチューニング
WebLogic Server のパフォーマンスは、その上で動作するアプリケーションによって決まります。以下の節では、パフォーマンスを低下させるボトルネックの解決について説明します。
この節では、WebLogic Server での OptimizeIt および JProbe の各プロファイラの使用方法について説明します。
プロファイラは、高い CPU 使用率または共有リソース競合率を引き起こすアプリケーション内のホット スポットを発見するためのパフォーマンス解析ツールです。一般的なプロファイラについては、 パフォーマンス解析ツールを参照してください。
JProbe Profiler with Memory Debugger は、パフォーマンス ボトルネックの検出、コード カバレッジの実行、およびその他のメトリックの実行機能を備えた製品ファミリです。
JProbe Profiler API を使用するには、以降の節での説明に従って、環境、コード、およびプログラムの起動を変更します。
環境の変更
環境に以下のような変更を行います。
PATH 変数に追加します。
.../jprobe../profiler
CLASSPATH 変数に追加します。
.../jprobe.../profiler/profilerAPI.jar
コードの変更
import com.klg.jprobe.profiler.api.*;
....
// 記録を開始する
JPPerformanceAPI.getInstance().pauseRecording();
JPPerformanceAPI.getInstance().clear();
JPPerformanceAPI.getInstance().resumeRecording();
// これらの呼び出しの戻り値は標準出力に出力できる。
// 戻り値はブール値でしかなく、問題が発生しても
// エラーの表示や、例外の送出は行われない
ここにコードが入る...
// JProbe データをスナップショットに保存する
JPPerformanceAPI.getInstance().pauseRecording();
if (!JPPerformanceAPI.getInstance().save("myprofile")) {
System.out.println ("COULD NOT SAVE PERF DATA");
System.exit(0);
}
プログラムの起動
次の例のように、プログラム（この場合は WebLogic Server）を起動します。
jplauncher -classic -jp_snapshot_dir=D:\temp \
-jp_function=performance \
-jp_java_exe=C:\java\java131\bin\java.exe \
-jp_java_home=C:\java\java131 \
-jp_vm=java2 \
-jp_measurement=elapsed \
-ms128m \
-mx128m \
-Dweblogic.management.username=system \
-Dweblogic.management.password=gumby1234 \
-Djava.security.policy==java.policy \
-Dweblogic.ConsoleInputEnabled=true \
-jp_record_from_start=performance \
weblogic.Server
OptimizeIt Java Performance Profiler は、Solaris および NT 用のパフォーマンス デバッグ ツールです。OptimizeIt Profiler API を使用するには、以降の節での説明に従って、環境、コード、およびプログラムの起動を変更します。
環境の変更
OptimizeIt Profiler API を使用するには、環境に以下のような変更を行います。
PATH 変数に追加します。
.../OptimizeIt40/lib
optit.jar を CLASSPATH 変数に追加します。
.../OptimizeIt40/optit.jar
コードの変更
// Security.Audit クラスもあるので、場所によっては
// 完全パッケージ名を使用する
intuitive.audit.Audit.start(
intuitive.audit.Audit.DEFAULT_PORT_NUMBER,
intuitive.audit.Audit.PROFILERS_ALWAYS_ENABLED,
intuitive.audit.Audit.SYSTEM_EXIT_DISABLED);
intuitive.audit.Audit.enableCPUProfiler();
ここにコードが入る...
intuitive.audit.Audit.disableCPUProfiler();
intuitive.audit.Audit.generateSnapshot("myprofile",
intuitive.audit.Audit.INCLUDE_CPU); // myprofile.snp を生成する
プログラムの起動
次の例のように、プログラム（この場合は WebLogic Server）を起動します。
java -classic -Xrunoii -Xnoclassgc \
-ms128m mx128m\
-Dweblogic.management.username=system\
-Dweblogic.management.password=gumby1234 \
-Djava.security.policy==java.policy \
-Dweblogic.ConsoleInputEnabled=true \
intuitive.audit.Audit -startCPUprofiler:type=cpu weblogic.Server
BEA では、WebLogic Server ソフトウェアで使用する 3 つの WebLogic jDriver を提供します。
『WebLogic jDriver for Oracle のインストールと使い方』を参照してください。
『WebLogic jDriver for Informix のインストールと使い方』、および『WebLogic jDriver for Microsoft SQL Server のインストールと使い方』を参照してください。
Type 2 ドライバでは、データベース ベンダが提供するクライアント ライブラリを使用します。一方、Type 4 ドライバは pure-Java であり、通信レベルでデータベース サーバに接続するので、ベンダ固有のクライアント ライブラリは不要です。
『WebLogic JDBC プログラミング ガイド』の「JDBC アプリケーションのパフォーマンス チューニング」を参照してください。
Type 4 MS SQL ドライバ向けの JDBC の最適化
Type 4 MS SQL ドライバを使用すると、SQL 文の作成および実行速度が大幅に向上する場合があります。その場合は、一連の長い setXXX() 呼び出しの後に execute() を実行するのではなく、パラメータを指定しないか、またはパラメータ値を対応する文字列に変換し、その文字列に追加します。
セッションの永続性を処理する場合、アプリケーションの作業ができるだけ少なくなるようアプリケーションを最適化します。WebLogic Server では、以下のオプションを使用してセッションの永続性を管理します。
詳細については、『WebLogic Server 管理者ガイド』の「セッションの永続性のコンフィグレーション」を参照してください。
インメモリ レプリケーションは、セッション ステートの JDBC ベースの永続性に比べて最大で 10 倍高速です。可能であれば、インメモリ レプリケーションを使用してください。
詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「HTTP セッション ステートのレプリケーションについて」を参照してください。
また、『WebLogic エンタープライズ JavaBeans プログラマーズ ガイド』の「ステートフル セッション EJB のインメモリ レプリケーション」も参照してください。
JDBC ベースの永続性を使用する場合、コードを最適化して、セッション ステートの永続性の粒度をできるだけ高くします。JDBC ベースの永続性の場合、セッション「格納」を実行するたびに、オブジェクト全体のデータベースへの書き込みが行われます。
HTTP セッション中に情報が永続化される頻度を最小限に抑える必要があります。実行される「格納」を調べ、それらを 1 つの大きい「格納」に統合します。
詳細については、『Web アプリケーションのアセンブルとコンフィグレーション』の「データベースの永続ストレージとしての使い方（JDBC 永続性）」を参照してください。
アプリケーションをチューニングして最高のパフォーマンスを引き出すには、WebLogic Server のセッション管理の方法をコンフィグレーションすることが重要になります。以下のことを考慮してください。
ステートをクライアント上で現実的に保持できない場合か、または URL 書き換えのサポートが必要な場合にのみ、セッションを使用します。ユーザ名などの単純なステートを直接クッキーに保持します。また、ラッパー クラスを記述して、これらのクッキーの取得および設定を行うこともできます。これにより、同じプロジェクトに参加しているサーブレット開発者の作業が簡素化されます。
『Web アプリケーションのアセンブルとコンフィグレーション』の「セッション管理の設定」を参照してください。
アプリケーションの実行スレッドへのアクセスをきめ細かくチューニングし、パフォーマンスを最適化または CPU 使用率を抑制するには、WebLogic Server で複数の実行キューを設定します。実行キューは、1 つまたは複数の指定されたサーブレット、JSP、EJB、または RMI オブジェクトで利用可能な実行スレッドの名前付きコレクションを表します。
WebLogic Server をデフォルト インストールした場合、実行キューは default にコンフィグレーションされます。この実行キューは、サーバ インスタンス上で実行中のすべてのアプリケーションで使用されます。キューは、以下の目的のためにコンフィグレーションして追加できます。
実行キューの欠点
実行キューを使用すると、アプリケーションのパフォーマンスをきめ細かくチューニングできます。ただし、未使用のスレッドは、Weblogic Server システムのリソースをかなり消費する点に注意してください。すべての実行キューのスレッド使用について慎重に考慮しないと、他のキューのアプリケーションがアイドル状態でスレッドが使用可能になるのを待機している間に、コンフィグレーションされた実行キューの使用可能なスレッドが未使用になってしまう可能性があります。この場合、スレッドをキューに分割したことが原因で、1 つのデフォルト実行キューの場合よりも全体のパフォーマンスが低下する可能性があります。
システム全体でスレッドを適切に使用するには、必ず各実行キューをモニタしてください。スレッド数の最適化に関する概要については、 スレッド数の設定を参照してください。
実行キューの作成
実行キューは、Server 要素の一部としてドメイン config.xml ファイル内で指定します。たとえば、名前が CriticalAppQueue でスレッドが 4 つある実行キューの場合、config.xml ファイルで次のように指定します。
...
<Server
Name="examplesServer"
ListenPort="7001"
NativeIOEnabled="true"/>
<ExecuteQueue Name="default"
ThreadCount="15"/>
<ExecuteQueue Name="CriticalAppQueue"
ThreadCount="4"/>
...
</Server>
WebLogic Administration Console で新しい実行キューを作成するには、次の手順に従います。
config.xml に新しいキューが作成されます。
サーブレットおよび JSP の実行キューへの割り当て
初期化パラメータの実行キュー名を識別することにより、コンフィグレーションされた実行キューにサーブレットまたは JSP を割り当てることができます。初期化パラメータは、サーブレットの init-param 要素内、または JSP のデプロイメント記述子ファイル web.xml 内で指定されています。実行キューを割り当てるには、次に示すように wl-dispatch-policy パラメータの値としてキュー名を入力します。
<servlet>
<servlet-name>MainServlet</servlet-name>
<jsp-file>/myapplication/critical.jsp</jsp-file>
<init-param>
<param-name>wl-dispatch-policy</param-name>
<param-value>CriticalAppQueue</param-value>
</init-param>
</servlet>
web.xml での初期化パラメータの指定に関する詳細については、『WebLogic HTTP サーブレット プログラマーズ ガイド』の「サーブレットの初期化」を参照してください。
EJBオブジェクトおよび RMI オブジェクトの実行キューへの割り当て
コンフィグレーションされた実行キューに RMI オブジェクトを割り当てるには、rmic コンパイラで -dispatchPolicy オプションを使用します。次に例を示します。
java weblogic.rmic -dispatchPolicy CriticalAppQueue ...
コンフィグレーションされた実行キューに EJB オブジェクトを割り当てるには、ejbc で -dispatchPolicy オプションを使用します。EJB のコンパイル時に ejbc コンパイラによって、このオプションと引数が rmic に渡されます。
|
|
|