WebLogic Server パフォーマンス チューニング ガイド
![]() |
![]() |
![]() |
![]() |
WebLogic Server のパフォーマンスは、その上で動作するアプリケーションによって決まります。『Mastering BEA WebLogic Server: Best Practices for Building and Deploying J2EE Applications』の言葉を借りれば、「アプリケーションのパフォーマンスは、アプリケーションの設計で決まります。複雑すぎるアプリケーションや設計が稚拙なアプリケーションは、システム レベルのチューニングを施してもパフォーマンスを大きく向上させることはできません」。言い換えれば、稚拙な設計のアプリケーションでは、不必要なボトルネックが発生してしまうのです。たとえば、リソースの競合はアプリケーション ドメインに内在するものではなく、悪い設計の一例なのです。
この節では、アプリケーションのパフォーマンスを低下させるボトルネックを特定する方法について説明します。
この節では、WebLogic Server での OptimizeitTM および JProbeTM の各プロファイラの使用方法について説明します。
プロファイラは、高い CPU 使用率または共有リソース競合率を引き起こすアプリケーション内のホット スポットを発見するためのパフォーマンス解析ツールです。一般的なプロファイラについては、「パフォーマンス解析ツール」を参照してください。
JProbe Suite は、パフォーマンス ボトルネックの検出、メモリ リークの特定と修正、コード カバレッジの実行、およびその他のメトリックの実行機能を備えた製品ファミリです。
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 接続プールのチューニングの詳細については以下を参照してください。
JMS アプリケーションのパフォーマンスには、さまざまな設計上の選択が影響します。また、信頼性、スケーラビリティ、管理容易性、モニタ、ユーザ トランザクション、メッセージ駆動型 Bean のサポート、アプリケーション サーバとの統合などもパフォーマンスに影響します。さらには、パフォーマンスに直接影響する WebLogic JMS の拡張や機能もあります。
JMS に合わせたアプリケーションの最適化および WebLogic JMS のチューニングの詳細については以下を参照してください。
「WebLogic Server EJB のチューニング」では、WebLogic Server エンタープライズ Java Bean をアプリケーションのニーズに合わせてチューニングする方法について説明します。
WebLogic Web サービスをプログラミングする際にパフォーマンスに関して留意すべき事項については以下を参照してください。
jaxp.properties
ファイル(JAXP API) にルックアップを使用することでブートストラップを行っているために発生します。 実行時不必要なファイル処理を回避するおよびパフォーマンスとリソース使用量が向上するためにコマンドラインでプロパティを設定することを推奨します。
セッションの永続性およびセッションを処理する場合、一般にはアプリケーションの作業ができるだけ少なくなるようアプリケーションを最適化する必要があります。また、環境およびアプリケーションに合わせてセッション管理戦略を設計する必要もあります。
Weblogic Server は、さまざまなアプリケーション要件に対応できるよう、5 つのセッション永続性メカニズムを備えています。セッション永続性メカニズムは、Web アプリケーション レイヤでコンフィグレーションできます。どのセッション管理戦略を選択するかは、HTTP セッションのサイズ、セッションのライフ サイクル、信頼性、セッションのフェイルオーバといった実際の要件によって異なります。たとえば、フェイルオーバが不要な Web アプリケーションであれば単一メモリ ベースのセッションとして管理でき、セッション フェイルオーバ機能を必要とする Web アプリケーションであれば、そのライフ サイクルやオブジェクト サイズに応じてレプリケート セッションまたは JDBC セッションとして管理できます。
純粋にパフォーマンスの面から言えば、セッション ステートの JDBC ベースの永続性よりも、インメモリ セッションの永続性の方が全般的に優れています。「Session Persistence Performance in BEA WebLogic Server 7.0」の著者によれば、「データのシリアライズとデシリアライズに伴う負荷はすべてのセッション永続性メカニズムで扱わなければなりませんが、データベース対話に伴う追加的な負荷は JDBC ベースのセッション永続性のパフォーマンスに影響し、インメモリ レプリケーションのパフォーマンスを下回る原因となります」。ただし、インメモリ ベースのセッション永続性は、WebLogic クラスタを使用する必要があるため単一サーバ環境では選択できません。
一方、JDBC ベースの永続性を使用した環境では、WebLogic クラスタを使用する必要はなく、セッション ステートをより長い期間にわたってデータベースに保持できます。JDBC ベースの永続性のパフォーマンスを向上させるには、コードを最適化してセッション ステートの永続性の粒度をできるだけ高くします。また、データベースの選択、データベース サーバの適切なコンフィグレーション、JDBC ドライバ、JDBC 接続プールのコンフィグレーションなども、JDBC ベースの永続性のパフォーマンスに影響します。
セッション永続性の管理の詳細については以下を参照してください。
アプリケーションをチューニングして最高のパフォーマンスを引き出すには、WebLogic Server のセッション管理の方法をコンフィグレーションすることが重要になります。以下のことを考慮してください。
詳細については、『WebLogic Server Web アプリケーションの開発』の「セッション管理の設定」を参照してください。
WebLogic Server で複数の実行キューを使用すると、アプリケーションから実行スレッドへのアクセスを微調整できます (したがって、パフォーマンスを最適化できる)。 ただし、未使用のスレッドは、Weblogic Server システムのリソースをかなり消費する点に注意してください。他のキューのタスクがアイドル状態でスレッドが使用可能になるのを待機している間に、コンフィグレーションされた実行キューの使用可能なスレッドが未使用になることがあります。この場合、スレッドを複数のキューに分割したことが原因で、1 つのデフォルト実行キューの場合よりも全体のパフォーマンスが低下する可能性があります。
WebLogic Server をデフォルト インストールした場合、実行キューは weblogic.kernel.Default
にコンフィグレーションされます。この実行キューは、サーバ インスタンス上で実行中のすべてのアプリケーションで使用されます。キューは、以下の目的のためにコンフィグレーションして追加できます。
システム全体でスレッドを適切に使用するには、必ず各実行キューをモニタしてください。スレッド数の最適化に関する概要については、「デフォルトの実行キュー スレッドのチューニング」を参照してください。
実行キューは、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 で新しい実行キューを作成するには、次の手順に従います。
キューの長さ
] : [キューの長さ] は常にデフォルトの 65536 エントリのままにします。[キューの長さ] では、サーバがキューに保持できる同時リクエストの最大数を指定します。デフォルトの 65536 は非常に大きな数です。キューの未処理のリクエストがこの最大値に達することはほとんどありません。[キューの長さ] の値に達すると、超過分に対応するためにキューのサイズが自動的に 2 倍になります。ただし、キューのリクエストが 65536 を超えた場合、それはキューの長さではなくキューのスレッドに問題があること示します。実行キューでスタック スレッドがないか、またはスレッド数が不十分ではないかを確認してください。
キューの長さのしきい値比率
] : このサイズに到達するまではサーバがキューのオーバーフロー条件を示さない、Queue Length サイズのパーセンテージ (1 ~ 99) を入力します。しきい値のパーセンテージ以下の実際のキューの長さはすべて通常と見なされ、しきい値のパーセンテージを超えるサイズはオーバーフローを示します。オーバーフロー条件に達すると、WebLogic Server はエラー メッセージをログに記録し、[スレッド数の増分] 属性の値分だけキューのスレッド数を増やして負荷を軽減します。デフォルトでは、[キューの長さのしきい値比率] の値は 90% です。ほとんどの場合、この値は 90% のままにするか、その前後の値に設定します。処理リクエストの突然の増加に対処するために追加スレッドが必要になる可能性のある、現実に起こりそうなあらゆる状況に対応するためです。 [キューの長さのしきい値比率] は、自動チューニング パラメータとしては使用しないでください。通常の操作状況では、そのしきい値によってスレッド数の増加が誘発されることはありません。
スレッド数
] : このキューに割り当てられたスレッド数です。 デフォルトの 15 を超えるスレッドを使用する必要がない場合は、この属性の値を変更しないようにします。詳細については、「デフォルト スレッド数の変更」を参照してください。スレッド数の増分
] : WebLogic Server がオーバーフロー条件を検出したときにこの実行キューに追加するスレッドの数を入力します。ゼロ スレッド (デフォルト) を指定した場合、サーバはスレッドのオーバーフロー条件に対して自己の状態を「warning」に変更しますが、追加スレッドを割り当てて負荷を軽減することはありません。 注意 : WebLogic Server がオーバーフロー条件に反応してスレッド数を増やすと、その追加のスレッドはサーバが再起動されるまで実行キューにとどまります。エラー ログをモニタしてオーバーフロー条件の原因を判別し、同様の状況が今後起こらないように必要に応じてスレッド数を再コンフィグレーションします。[スレッド数の増分] と [キューの長さのしきい値比率] の組み合わせを自動チューニング ツールとして使用することはしないでください。そのようにすると、実行キューで必要以上のスレッドが割り当てられ、コンテキストの切り替えが原因でパフォーマンスが低下することになります。
最大スレッド数
] : この実行キューが持つことのできる最大スレッド数を指定します。この値によって、WebLogic Server が継続的なオーバーフロー条件に対してキュー内に過剰な数のスレッドを作成することを防ぎます。デフォルトでは、[最大スレッド数] は 400 に設定されています。スレッド優先順位
] : このキューに関連付けられたスレッドの優先順位を指定します。デフォルトでは、[スレッド優先順位] は 5 に設定されています。初期化パラメータの実行キュー名を識別することにより、コンフィグレーションされた実行キューにサーブレットまたは 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 オブジェクトを割り当てるには、weblogic-ejb-jar.xml
で新しい dispatch-policy
要素を使用します。詳細については、「weblogic-ejb-jar.xml デプロイメント記述子のリファレンス」を参照してください。
appc
コンパイラの -dispatchPolicy
フラグを使用してディスパッチ ポリシーを設定することもできますが、フラグではなくデプロイメント記述子を使用することをお勧めします。この方法により、たとえばデプロイ中に EJB が再コンパイルされる場合でも、設定が失われません。
コンフィグレーションされた実行キューに RMI オブジェクトを割り当てるには、rmic
コンパイラで -dispatchPolicy
オプションを使用します。次に例を示します。
![]() ![]() |
![]() |
![]() |