ナビゲーションをスキップ

eDocs ホーム > BEA WebLogic Server 8.1 ドキュメント > WebLogic Server パフォーマンス チューニング ガイド > WebLogic Server アプリケーションのチューニング

WebLogic Server パフォーマンス チューニング ガイド

  前 次 前/次ボタンと目次ボタンとの区切り線 目次  

WebLogic Server アプリケーションのチューニング

WebLogic Server のパフォーマンスは、その上で動作するアプリケーションによって決まります。『Mastering BEA WebLogic Server: Best Practices for Building and Deploying J2EE Applications』の言葉を借りれば、「アプリケーションのパフォーマンスは、アプリケーションの設計で決まります。複雑すぎるアプリケーションや設計が稚拙なアプリケーションは、システム レベルのチューニングを施してもパフォーマンスを大きく向上させることはできません」。言い換えれば、稚拙な設計のアプリケーションでは、不必要なボトルネックが発生してしまうのです。たとえば、リソースの競合はアプリケーション ドメインに内在するものではなく、悪い設計の一例なのです。

この節では、アプリケーションのパフォーマンスを低下させるボトルネックを特定する方法について説明します。

 

パフォーマンス解析ツールの使い方

この節では、WebLogic Server での OptimizeitTM および JProbeTM の各プロファイラの使用方法について説明します。

プロファイラは、高い CPU 使用率または共有リソース競合率を引き起こすアプリケーション内のホット スポットを発見するためのパフォーマンス解析ツールです。一般的なプロファイラについては、「パフォーマンス解析ツール」を参照してください。

JProbe Profiler の使い方

JProbe Suite は、パフォーマンス ボトルネックの検出、メモリ リークの特定と修正、コード カバレッジの実行、およびその他のメトリックの実行機能を備えた製品ファミリです。

JProbe の Web サイトには、技術的なホワイト ペーパー「Using Sitraka JProbe and BEA WebLogic Server」があります。このホワイト ペーパーでは、開発者が BEA WebLogic Server 内で JProbe Suite ツールのいずれかを実行してコードを解析する方法が説明されています。

Optimizeit Profiler の使い方

Borland の Optimizeit Profiler は、Solaris および Windows プラットフォーム用のパフォーマンス デバッグ ツールです。

Borland は、WebLogic Server で機能するバージョンの Optimizeit Profiler について詳しい J2EE 統合チュートリアルを提供しています。

 

JDBC アプリケーションのチューニング

データベース アプリケーションのパフォーマンスの良し悪しはほとんどの場合、アプリケーションがどのように設計されているかによって決まります。クライアントの数と場所、DBMS テーブルおよびインデックスのサイズと構造、およびクエリの数とタイプは、すべてアプリケーションのパフォーマンスに影響を与えます。

JDBC に合わせたアプリケーションの最適化および WebLogic JDBC 接続プールのチューニングの詳細については以下を参照してください。

 

JMS アプリケーションのチューニング

JMS アプリケーションのパフォーマンスには、さまざまな設計上の選択が影響します。また、信頼性、スケーラビリティ、管理容易性、モニタ、ユーザ トランザクション、メッセージ駆動型 Bean のサポート、アプリケーション サーバとの統合などもパフォーマンスに影響します。さらには、パフォーマンスに直接影響する WebLogic JMS の拡張や機能もあります。

JMS に合わせたアプリケーションの最適化および WebLogic JMS のチューニングの詳細については以下を参照してください。

 

EJB アプリケーションのチューニング

「WebLogic Server EJB のチューニング」では、WebLogic Server エンタープライズ Java Bean をアプリケーションのニーズに合わせてチューニングする方法について説明します。

 

Web サービスのチューニング

WebLogic Web サービスをプログラミングする際にパフォーマンスに関して留意すべき事項については以下を参照してください。

 

セッションの管理

セッションの永続性およびセッションを処理する場合、一般にはアプリケーションの作業ができるだけ少なくなるようアプリケーションを最適化する必要があります。また、環境およびアプリケーションに合わせてセッション管理戦略を設計する必要もあります。

セッションの永続性の管理

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 で新しい実行キューを作成するには、次の手順に従います。

  1. 管理サーバが起動していない場合は、起動します。
  2. ドメインの Administration Console にアクセスします。
  3. 左ペインの [サーバ] ノードを展開して、ドメインでコンフィグレーションされたサーバを表示します。
  4. 実行キューを追加するサーバ インスタンスの名前を右クリックし、ポップアップ メニューで [実行キューを表示] を選択します。
  5. 実行キューの [コンフィグレーション] タブで、[新しい Execute Queue のコンフィグレーション] リンクをクリックします。
  6. 実行キューの [コンフィグレーション] タブで、以下の属性の値を変更するか、システムのデフォルトをそのまま使用します。
  7. [作成] をクリックして、新しい実行キューを作成します。
  8. サーバを再起動して新しい設定内容を有効にします。

サーブレットおよび JSP の実行キューへの割り当て

初期化パラメータの実行キュー名を識別することにより、コンフィグレーションされた実行キューにサーブレットまたは 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 オブジェクトの実行キューへの割り当て

コンフィグレーションされた実行キューに EJB オブジェクトを割り当てるには、weblogic-ejb-jar.xml で新しい dispatch-policy 要素を使用します。詳細については、「weblogic-ejb-jar.xml デプロイメント記述子のリファレンス」を参照してください。

appc コンパイラの -dispatchPolicy フラグを使用してディスパッチ ポリシーを設定することもできますが、フラグではなくデプロイメント記述子を使用することをお勧めします。この方法により、たとえばデプロイ中に EJB が再コンパイルされる場合でも、設定が失われません。

コンフィグレーションされた実行キューに RMI オブジェクトを割り当てるには、rmic コンパイラで -dispatchPolicy オプションを使用します。次に例を示します。

java weblogic.rmic -dispatchPolicy CriticalAppQueue ...

 

フッタのナビゲーションのスキップ  ページの先頭 前 次