BEA ホーム | 製品 | dev2dev | support | askBEA |
![]() |
![]() |
|
![]() |
e-docs > WebLogic Server > WebLogic Server パフォーマンス チューニング ガイド > WebLogic Server アプリケーションのチューニング |
WebLogic Server パフォーマンス チューニング ガイド
|
WebLogic Server アプリケーションのチューニング
WebLogic Server のパフォーマンスは、その上で動作するアプリケーションによって決まります。以下の節では、パフォーマンスを低下させるボトルネックの解決について説明します。
この節では、WebLogic Server での OptimizeItTM および JProbeTM の各プロファイラの使用方法について説明します。
プロファイラは、高い CPU 使用率または共有リソース競合率を引き起こすアプリケーション内のホット スポットを発見するためのパフォーマンス解析ツールです。一般的なプロファイラについては、パフォーマンス解析ツールを参照してください。
JProbe Suite は、パフォーマンス ボトルネックの検出、メモリ リークの検出と修正、コード カバレッジの実行、およびその他のメトリックの実行機能を備えた製品ファミリです。 製品の詳細については、http://www.quest.com/jprobe/ を参照してください。
JProbe の Web サイトでは、テクニカル ホワイト ペーパー「Using Sitraka JProbe and BEA WebLogic Server」を提供しています。BEA WebLogic Server 内で動作する JProbe Suite 製品を使用して開発者がコードを分析する方法について説明しています。
Borland の Optimizeit Profiler は、Solaris および Windows プラットフォーム用のパフォーマンス デバッグ ツールです。
Borland は、WebLogic Server で機能するバージョンの Optimizeit Profiler について詳しい J2EE 統合チュートリアルを提供しています。
データベース アプリケーションのパフォーマンスの良し悪しはほとんどの場合、アプリケーションがどのように設計されているかによって決定まります。クライアントの数と場所、DBMS テーブルおよびインデックスのサイズと構造、およびクエリの数とタイプは、すべてアプリケーションのパフォーマンスに影響を与えます。
JDBC に合わせてアプリケーションを最適化する方法の詳細については、『WebLogic JDBC プログラマーズ ガイド』の「JDBC アプリケーションのパフォーマンス チューニング」(を参照してください。
Type 4 MS SQL ドライバ向けの JDBC の最適化
Type 4 MS SQL ドライバを使用すると、SQL 文の作成および実行速度が大幅に向上する場合があります。その場合は、一連の長い setXXX() 呼び出しの後に execute() を実行するのではなく、パラメータを指定しないか、またはパラメータ値を対応する文字列に変換し、その文字列に追加します。
詳細については、『WebLogic jDriver for Microsoft SQL Server のコンフィグレーションと使い方』(を参照してください。
セッションの永続性およびセッションを処理する場合、アプリケーションの作業ができるだけ少なくなるようアプリケーションを最適化します。
インメモリ レプリケーションは、セッション ステートの JDBC ベースの永続性に比べて最大で 10 倍高速です。可能であれば、インメモリ レプリケーションを使用してください。
JDBC ベースの永続性を使用する場合、コードを最適化して、セッション ステートの永続性の粒度をできるだけ高くします。JDBC ベースの永続性の場合、セッション「格納」処理を実行するたびに、オブジェクト全体のデータベースへの書き込みが行われます。
HTTP セッション中に情報が永続化される頻度を最小限に抑える必要があります。実行される「格納」を調べ、可能な場合は、それらを 1 つの大きい「格納」に統合します。
アプリケーションをチューニングして最高のパフォーマンスを引き出すには、WebLogic Server のセッション管理の方法をコンフィグレーションすることが重要になります。以下のことを考慮してください。
『Web アプリケーションのアセンブルとコンフィグレーション』の「セッション管理の設定」(を参照してください。
アプリケーションの実行スレッドへのアクセスをきめ細かくチューニングし、パフォーマンスを最適化および抑制するには、WebLogic Server で複数の実行キューを使用します。ただし、未使用のスレッドは、Weblogic Server システムのリソースをかなり消費する点に注意してください。他のキューのアプリケーションがアイドル状態でスレッドが使用可能になるのを待機している間に、コンフィグレーションされた実行キューの使用可能なスレッドが未使用になることがあります。この場合、スレッドを複数のキューに分割したことが原因で、1 つのデフォルト実行キューの場合よりも全体のパフォーマンスが低下する可能性があります。
WebLogic Server をデフォルト インストールした場合、実行キューはデフォルトにコンフィグレーションされます。この実行キューは、サーバ インスタンス上で実行中のすべてのアプリケーションで使用されます。キューは、以下の目的のためにコンフィグレーションして追加できます。
システム全体でスレッドを適切に使用するには、必ず各実行キューをモニタしてください。スレッド数の最適化に関する概要については、スレッド数の設定を参照してください。
実行キューは、1 つまたは複数の指定されたサーブレット、JSP、EJB、または RMI オブジェクトで利用可能な実行スレッドの名前付きコレクションを表します。実行キューは、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>
Administration Console で新しい実行キューを作成するには、次の手順に従います。
初期化パラメータの実行キュー名を識別することにより、コンフィグレーションされた実行キューにサーブレットまたは JSP を割り当てることができます。初期化パラメータは、サーブレットまたは JSP のデプロイメント記述子ファイル web.xml の init-param 要素内で指定されています。実行キューを割り当てるには、次に示すように 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 に渡されます。
![]() |
![]() |
![]() |
![]() |
||
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |