目次


ケース・スタディー: WebSphere Application Server V7、V8 のパフォーマンス・チューニング

Comments

はじめに

IBM WebSphere Application Server は、開発者がアプリケーションで利用できるコンポーネント、リソース、およびサービスのコア・セットを提供する、堅牢なエンタープライズ・クラスのアプリケーション・サーバーです。あらゆるアプリケーションには独自の要件があり、多くの場合 1 つのアプリケーション・サーバーのリソースを非常に幅広い方法で使用します。このような多様なアプリケーションに対して高い柔軟性とサポートを提供するため、WebSphere Application Server では、アプリケーションのパフォーマンスの向上に利用できる広範なチューニング用「ノブ」とパラメーターを用意しています。

アプリケーション・サーバーで最もよく使われるチューニング・パラメーターに対してはデフォルト値が設定され、そのままでも多様なアプリケーションが十分なパフォーマンスを発揮できるようになっています。しかし、まったく同じアプリケーションや、完全に同じ方法でアプリケーション・サーバーを使用するアプリケーションは存在しないため、1 組のチューニング・パラメーターがすべてのアプリケーションに完全に適合するという保証はありません。この事実により、個別のアプリケーションに焦点を当てたパフォーマンス・テストおよびチューニングを実施することの重要性が明らかになりました。

この記事では、WebSphere Application Server V7 および V8 (さらに以前のリリース) で最もよく使用されるパラメーター、およびそれらのパラメーターのチューニングに使用される方法をいくつか説明します。文書化されている多くのチューニングに関する提案とは異なり、この記事では Apache DayTrader Performance Benchmark Sample アプリケーションをケース・スタディーとして使用します。DayTrader アプリケーションを使用すると、使用中の重要なサーバー・コンポーネントを明確に識別し、これらの領域に焦点を当てたチューニングを行い、さらにチューニングのそれぞれの変更点に関連するパフォーマンスの向上を理解することができます。

この記事に記載されている内容は、特に断りがない限り、WebSphere Application Server V7 および V8 の両方に当てはまります。

先へ進む前に、アプリケーション・サーバーのパフォーマンス・チューニングの際に考慮すべき点を、以下にいくつか追加しておきます。

  • パフォーマンスの向上によって、アプリケーションやアプリケーション・サーバーの特徴や機能がある程度損なわれる場合があります。パフォーマンス・チューニングの変更を評価するときは、パフォーマンスと機能との間のトレードオフを慎重に検討する必要があります。
  • アプリケーション・サーバー以外の要因が、パフォーマンスに影響する可能性があります。例えば、ハードウェア構成、OS 構成、システムで実行中の他のプロセス、バックエンド・データベース・リソースのパフォーマンス、およびネットワーク待ち時間などです。パフォーマンスの評価を実施する際は、これらの要因を考慮する必要があります。
  • ここで詳しく説明するパフォーマンスの改善点は、これから説明する DayTrader アプリケーション、ワークロード・ミックス、およびここで取り上げているハードウェアとソフトウェアの組み合わせに特有のものです。この記事で詳述するチューニングの変更によるアプリケーションのパフォーマンスの向上は、さまざまな要因で変化するので、各自がパフォーマンス・テストを実施して評価する必要があります。

DayTrader アプリケーション

Apache DayTrader Performance Benchmark Sample アプリケーションは、株式取引をシミュレートするシンプルなアプリケーションです。このアプリケーションでは、ユーザーは、ログイン/ログアウト、ポートフォリオの表示、株価情報の検索、株の売買、およびアカウント情報の管理を行うことができます。DayTrader は機能テスト用のアプリケーションとして優れているだけでなく、アプリケーション・サーバー・レベルおよびコンポーネント・レベルで、パフォーマンスの特性分析と測定を行うために使用できる標準的なワークロード・セットも提供しています。DayTrader (および当初 IBM が開発し DayTrader の基になった Trade Performance Benchmark Sample) は、最適なパフォーマンスを提供するために作成されたものではなく、アプリケーション・サーバーの各リリースの間での相対的なパフォーマンスの比較、および異なる実装スタイルや実装パターンの間での同様の比較ができるように作られています。

DayTrader は、プレゼンテーション層として Java サーブレットと JSP (JavaServer™ Pages)、バックエンドのビジネス・ロジックおよびパーシスタンス層として JDBC (Java Database Connectivity)、JMS (Java Message Service)、EJB (Enterprise JavaBeans™)、およびメッセージ駆動型 Bean (MDB) を含む Java EE (Java™ Enterprise Edition) 技術のコア・セットを基に構築されています。図 1 に、概要レベルのアプリケーション・アーキテクチャーを示します。

図 1. DayTrader アプリケーションの概要
DayTrader アプリケーションの概要
DayTrader アプリケーションの概要

一般的な Java EE パーシスタンスおよびトランザクション管理パターンを評価するため、DayTrader は 3 つの異なるビジネス・サービスの実装を提供しています。これらの実装 (実行時のモード) を表 1 に示します。

表 1. DayTrader の実装
実行時のモードパターン説明
ダイレクトサーブレットから JDBC へCRUD (作成、取得、更新、および削除) 操作は、カスタム JDBC コードを使用して、データベースに対して直接実行されます。データベースの接続、コミット、およびロールバックはコード内で、手動で管理されます。
セッション・ダイレクトサーブレットからステートレス・セッション Bean 経由で JDBC へCRUD 操作は、カスタム JDBC コードを使用して、データベースに対して直接実行されます。データベースの接続はコード内で、手動で管理されます。データベースのコミットとロールバックは、ステートレス・セッション Bean によって自動管理されます。
EJBサーブレットからステートレス・セッション Bean 経由でエンティティ Bean へEJB コンテナーが、すべてのクエリー、トランザクション、およびデータベース接続の責任を負います。

この記事では、これら 3 つの実行時のモードを取り上げ、それぞれのチューニングの変更が、これら 3 つの一般的な Java EE パーシスタンスおよびトランザクションの実装スタイルに対して及ぼす影響を示します。

WebSphere Application Server のチューニング可能要素の概要

前述のように、パフォーマンスのチューニングにおいて、アプリケーションのアーキテクチャー、サーバー・コンポーネント、およびアプリケーションが利用するリソースの重要性はいくら強調しても十分ではありません。この知識があれば、チューニング可能なパラメーターのリストから、アプリケーションに直接影響する重要なチューニング可能要素を選別し、それらに焦点を当てることができます。

通常、パフォーマンスのチューニングは、アプリケーション・サーバーの基盤となっている JVM (Java Virtual Machine) から開始します。そこから先は、アプリケーションが使用するアプリケーション・サーバー・コンポーネントを中心にチューニングを進めていきます。例えば、アーキテクチャー図 (図 1) を使用すると、以下に示す DayTrader アプリケーションの重要なチューニング可能サーバー・コンポーネントをいくつか特定することができます。

  • Web コンテナーと EJB コンテナー
  • 関連したスレッド・プール
  • データベース接続プール
  • デフォルトのメッセージング・プロバイダー

この記事ではこの後、上に挙げたコンポーネントをベースにして、DayTrader のパフォーマンスに影響するいくつかのチューニング・オプションの詳細について説明します。これらのオプションは以下のセクションに分けることができます。

  • 基本的なチューニング: このグループのチューニング・パラメーターは、最も一般的にチューニングされ、しかも多用される JVM を始めとした少数のアプリケーション・サーバー・コンポーネントを対象にしています。これらの設定は、従来から最も労力に見合う価値を提供してきました。
  • 高度なチューニング: 補助的なグループである高度なチューニング・パラメーターは、通常は特定のシナリオに固有のパラメーターであり、多くの場合、システムから最大のパフォーマンスをしぼり出すために使用されます。
  • 非同期メッセージングのチューニング: ここで説明するオプションは、非同期メッセージング用に WebSphere Application Server のメッセージング・コンポーネントを利用するアプリケーションに特有のものです。

各チューニング・パラメーターをこれらのセクションにグループ化して、適用可能性についての詳細な説明、および機能のトレードオフやパフォーマンスへの最終的な影響に関連した情報 (該当する場合は、パーシスタンスおよびトランザクション管理パターンごとに) と合わせて紹介します。特定のパラメーターのチューニングに役立つツールについても説明します。関連する WebSphere Application Server インフォメーション・センターのドキュメント、およびその他の関連資料のリンクはセクションごとに示し、さらに「参考文献」セクションにも一覧にしてまとめます。

基本的なチューニング

このセクションでは以下の項目について説明します。

  1. JVM ヒープ・サイズ
  2. スレッド・プール・サイズ
  3. 接続プール・サイズ
  4. データ・ソース・ステートメントのキャッシュ・サイズ
  5. ORB 参照渡し

a. JVM ヒープ・サイズ

JVM ヒープ・サイズ・パラメーターは、ガーベッジ・コレクション動作に直接影響します。JVM ヒープ・サイズを増やすと、割り当てエラーの発生によってガーベッジ・コレクションが開始される前に、より多くのオブジェクトを作成できるようになります。これによって、アプリケーションは必然的に、ガーベッジ・コレクション (GC) サイクルの間に、より長時間実行できるようになります。残念ながら、ヒープ・サイズの増加に伴うマイナス面は、ガーベッジ・コレクションの対象となるオブジェクトの検出と処理に要する時間がその分だけ増えることです。その結果、JVM ヒープ・サイズのチューニングでは、多くの場合、ガーベッジ・コレクションの間隔と、ガーベッジ・コレクションの実行に要する停止時間との間でバランスを取る必要があります。

JVM ヒープ・サイズのチューニングを行うためには、verbose GC を有効にする必要があります。このためには、WebSphere Application Server 管理コンソールから、「Servers (サーバー)」 => 「Application servers (アプリケーション・サーバー)」 => [サーバー名] => 「Process definition (プロセス定義)」 => 「Java Virtual Machine (Java 仮想マシン)」の順にナビゲートします。verbose GC を有効にすると、JVM はガーベッジ・コレクションのたびに、ヒープ内の空き/使用バイト数、ガーベッジ・コレクションの間隔、および停止時間などの有用な情報を表示するようになります。この情報は native_stderr.log ファイルに記録されるので、ヒープ使用状況を視覚化するさまざまなツールで使用できます。

WebSphere Application Server のデフォルトのヒープ設定では、初期ヒープ・サイズは 50 MB、最大ヒープ・サイズは 256 MB です。通常はパフォーマンスを最大にするために、最小ヒープ・サイズと最大ヒープ・サイズを同じ値に設定することが推奨されます。その理由については、後のセクションを参照してください。

テスト

verbose GC を有効にし、初期ヒープ・サイズと最大ヒープ・サイズの両方をそれぞれ 256 MB、512 MB、1024 MB、2048 MB に設定して、4 つのラボ・テストを実施しました。verbose GC は手動でも分析できますが、IBM Monitoring and Diagnostic Tools for Java - Garbage Collection and Memory Visualizer (無償でダウンロードできる IBM Support Assistant にパッケージされています) などのグラフィカル・ツールを使用すると、非常に容易に処理できるようになります。DayTrader アプリケーションの適切なヒープ・サイズを見つけるための調整ができるように、ラボ・テストではこのツールを使用して verbose GC を分析しました。

verbose GC の出力において最初に監視しなければならない項目の 1 つは、コレクション後の空きヒープです。このメトリックは、通常、アプリケーション内に Java メモリー・リークが存在するかどうかを判断する場合に使用されます。このメトリックが一定値に収束せず、時間と共に減り続ける場合は、アプリケーション内にメモリー・リークが存在する明らかな指標になります。コレクション後の空きヒープのメトリックは、ヒープ・サイズと組み合わせて、サーバーやアプリケーションによって使用されている作業メモリー (「フットプリント」) を計算するためにも使用できます。単純に、合計ヒープ・サイズから空きヒープ値を引くと、この値が得られます。

図 2. コレクション後の空きヒープのサマリー
コレクション後の空きヒープのサマリー
コレクション後の空きヒープのサマリー

verbose GC のデータと図 2 のチャートは Java ヒープ内のメモリー・リークの検出に役立ちますが、ネイティブなメモリー・リークは検出できないことに注意してください。ネイティブなメモリー・リークは、ネイティブ・コンポーネント (C/C++ で作成され、JNI (Java Native Interface) API によって呼び出されるベンダーのネイティブ・ライブラリなど) による、Java ヒープの外側でのネイティブなメモリー・リークがある場合に発生します。このような状況では、プラットフォーム専用のツール (Linux® プラットフォームの ps コマンドや top コマンド、Windows® プラットフォームの Perfmon など) を使用して、Java プロセスのネイティブなメモリー使用状況を監視する必要があります。WebSphere Application Server のサポート・ページには、メモリー・リークの診断に関する詳細なドキュメントがあります。

新たに狙いをしぼる 2 つのメトリックは、各コレクションのガーベッジ・コレクション間隔平均停止時間です。GC 間隔は、ガーベッジ・コレクション・サイクル間の時間です。停止時間は、ガーベッジ・コレクション・サイクルが完了するまでにかかる時間です。図 3 に、4 つのヒープ・サイズごとのガーベッジ・コレクション間隔のチャートを示します。平均値は 0.6 秒 (256 MB)、1.5 秒 (512 MB)、3.2 秒 (1024 MB)、6.7 秒 (2048 MB) でした。

図 3. ガーベッジ・コレクション間隔
ガーベッジ・コレクション間隔
ガーベッジ・コレクション間隔

図 4 に、4 つのヒープ・サイズごとの平均停止時間を示します。ラボ・テストでの平均値は、62 ミリ秒 (256 MB)、69 ミリ秒 (512 MB)、83 ミリ秒 (1024 MB)、117 ミリ秒 (2048 MB) でした。このことは、Java ヒープ・サイズの増加に関連した標準的なトレードオフを明確に示しています。ヒープ・サイズを増やすと、GC 間隔が長くなり、JVM が停止してガーベッジ・コレクション・ルーチンを実行する前に、より多くの作業を実行できるようになります。しかし、ヒープを増やすと、ガーベッジ・コレクションで処理しなければならないオブジェクトが増加するので、結局は GC 停止時間が長くなることも意味します。

図 4. 平均停止時間
平均停止時間
平均停止時間

GC 間隔と停止時間の両方で、ガーベッジ・コレクションで消費される時間が決まります。ガーベッジ・コレクションで消費される時間の割合は、IBM Monitoring and Diagnostic Tools for Java - Garbage Collection and Memory Visualizer ツールで表示されますが、次の公式で計算できます。

ガーベッジ・コレクションで消費される時間の割合

ガーベッジ・コレクションで消費される時間の割合

ガーベッジ・コレクションで消費される時間、および実行ごとに得られるスループット (要求数/秒) を図 5 に示します。

図 5. ガーベッジ・コレクションで消費される時間とスループット
ガーベッジ・コレクションで消費される時間とスループット
ガーベッジ・コレクションで消費される時間とスループット

この図によると、DayTrader アプリケーションに推奨される初期ヒープ・サイズと最大ヒープ・サイズの設定は 1024 MB です。この時点で、ヒープ・サイズをさらに増やしても、それに見合うパフォーマンスの向上は得られない限界点に到達しています。この設定が、長いガーベッジ・コレクション間隔と短い停止時間の間の適切なバランスであり、ガーベッジ・コレクションに消費される時間は短くなります。

JVM のチューニングに関するもう 1 つの重要な問題は、ガーベッジ・コレクション・ポリシーです。3 つの主要な GC ポリシーを以下に挙げます。

  • optthruput: (V7 のデフォルト) アプリケーションのスループットを最大にするため、アプリケーションが停止し、ガーベッジ・コレクションが実施されている間に、マーク・アンド・スイープ操作を実行します。
  • optavgpause: 停止時間を最小にするため、アプリケーションの実行中にマーク・アンド・スイープ操作を同時に実行します。これにより、最良のアプリケーション応答時間を実現します。
  • gencon: (V8 のデフォルト) 存続時間の短いオブジェクトと長いオブジェクトを別々に取り扱うことで、短い停止時間と高いアプリケーション・スループットの両方を実現します。

DayTrader アプリケーションでは存続時間の長いオブジェクトを多用しないので、通常はデフォルトの optthruput GC ポリシーが最適です。しかし、アプリケーションは多様なので、各 GC ポリシーを評価して、各自のアプリケーションに最適なものを見つける必要があります。developerWorks の記事「Garbage collection policies」は、GC ポリシーをさらに学習するために大変役立つ資料です。

図 6 に、DayTrader の異なる実行時のモードごとに JVM ヒープ・サイズをチューニングすることで実現したパフォーマンスの向上 (アプリケーションのスループットから判断しました) を示します。チャート内の青いバーは基準スループット値を表し、赤いバーは前述のチューニング・パラメーターを調整した後のスループット値を表します。さまざまな実行時のモード間での相対的なスループットの違いを示すため、すべての測定値は EJB モードの基準値との比較になっています。

例えば、チューニング前のセッション・ダイレクト・モードとダイレクト・モードでは、EJB モードの基準値よりそれぞれ 23% および 86% 速くなっています。2 番目の縦軸上の折れ線は、実行時のモードごとの全体的なパフォーマンスの向上を表します。この場合、3 つの実行時のモードに、独自のオブジェクト割り当てパターンがそれぞれ関連付けられているため、JVM チューニングによるパフォーマンスの向上はまちまちでした。パフォーマンスの向上はわずか 3% (JDBC モード) から最高でも 9% (EJB モード) の範囲でした。

この情報は、各チューニング・パラメーターの最後の該当するところに示されます。各チューニング・パラメーターの適用によるパフォーマンスの向上は、前のセクションのパラメーターに加えられます。この記事の最後のチャート (図 22) に、適用されたすべてのチューニングによって達成された最終的なパフォーマンスの向上を示します。

図 6. JVM ヒープ・サイズのチューニングによるパフォーマンスの向上
JVM ヒープ・サイズのチューニングによるパフォーマンスの向上
JVM ヒープ・サイズのチューニングによるパフォーマンスの向上

JVM 最小ヒープ・サイズ = 最大ヒープ・サイズ

先ほど説明したように、通常は実行時のパフォーマンスを最大にするために、最小ヒープ・サイズと最大ヒープ・サイズを同じ値に設定することが推奨されます。このように設定すると、ヒープ・サイズが動的に変更される圧縮処理が JVM では行われなくなります。圧縮は非常にコストがかかる処理で、ガーベッジ・コレクションによる停止時間の 50% を占める場合もあります。最小ヒープ・サイズと最大ヒープ・サイズを同じ値に設定すると、主要なパラメーターの値が固定されるのでガーベッジ・コレクションの分析が容易になるという利点もありますが、その一方で JVM の起動時に割り当てるヒープ・サイズが大きくなるため、起動に時間がかかるようになるという代償を伴います。

最小ヒープ・サイズと最大ヒープ・サイズを異なる値に設定した方がメリットがある場合もあります。その一例が、異なるワークロードを実行している複数のアプリケーション・サーバー・インスタンスが同じサーバー上にホストされているような場合です。このような場合には、JVM は変化するワークロード要求に動的に対応し、より効果的にシステム・メモリーを活用することができます。

最小ヒープ・サイズと最大ヒープ・サイズを同じ値に設定することによるメリットを説明するために、最大ヒープ・サイズを 1024 MB (1 GB) に固定し、最小ヒープ・サイズを大きくしていったときのパフォーマンスを測定するというテストを行いました。その結果を以下の図 7 のグラフに示します。

図 7. 最小ヒープ・サイズと最大ヒープ・サイズを同じ値に設定したときのパフォーマンス上のメリット
最小ヒープ・サイズと最大ヒープ・サイズを同じ値に設定したときのパフォーマンス上のメリット
最小ヒープ・サイズと最大ヒープ・サイズを同じ値に設定したときのパフォーマンス上のメリット

最小ヒープ・サイズが 50 MB、最大ヒープ・サイズが 256 MB というデフォルト・ヒープ・サイズを基準とします。このワークロードの場合、最大ヒープ・サイズを 1 GB としただけでは、あまりパフォーマンスが改善されない (2% 未満) ことが見て取れます。これは圧縮量が非常に大きいためですが、最小ヒープ・サイズを最大ヒープ・サイズに近づけていくと、圧縮量が減るため、ガーベッジ・コレクションに要する時間が短くなります。最終的に、アプリケーション全体のスループットは 10% 程度増大し、ガーベッジ・コレクションに要する時間が占める割合はデフォルト構成時の割合にかなり近い値になっています。

新しい世代 (nursery) 領域のヒープ・サイズのチューニング

WebSphere Application Server V8 では、デフォルトのガーベッジ・コレクション・ポリシーは gencon に変更されました。gencon ではヒープを新しい世代 (Nursery) 領域と古い世代 (Tenured) 領域の 2 つの領域に分け、新しい世代領域には生存期間の短いオブジェクトを割り当て、古い世代領域には生存期間の長いオブジェクトを割り当てます。そして、ある一定期間存在しているオブジェクトは、新しい世代領域から古い世代領域へと移されます。新しい世代のコレクションはグローバル・コレクションに比べ、はるかに停止時間が短いため、gencon は有益な GC ポリシーです。

ここでチューニング設定として重要なのは、新しい世代領域のヒープ・サイズ (-Xmn) です。そのデフォルト値は最大ヒープ・サイズの 25% であり、古い世代領域のヒープ・サイズは最大ヒープ・サイズの 75% になっています。生存期間が長いオブジェクトが大半を占めるようなアプリケーションには、この設定値はかなり適切な値となります。一方で生存期間が短いオブジェクトが多いアプリケーションの場合、新しい世代領域のヒープ・サイズを大きくすると、パフォーマンスの向上が見られるようになります。

DayTrader のようなトランザクション・ベースのアプリケーションは、新しい世代領域のヒープ・サイズを大きくするとメリットが得られるアプリケーションの一例です。トランザクション・ベースのアプリケーションでは、トランザクションを実行するために多くのオブジェクトが作成され、トランザクションが完了するとそのオブジェクトは削除されるからです。この例を説明するために、最小ヒープ・サイズと最大ヒープ・サイズを 1024 MB に設定し、新しい世代領域のヒープ・サイズを 256 MB (デフォルト)、512 MB、768 MB と変化させてパフォーマンスを測定するテストを行いました。その結果を図 8 に示します。

図 8. 新しい世代領域のヒープ・サイズをチューニングしたときのパフォーマンス上のメリット
新しい世代領域のヒープ・サイズをチューニングしたときのパフォーマンス上のメリット
新しい世代領域のヒープ・サイズをチューニングしたときのパフォーマンス上のメリット

以下のリンク先のページには JVM ヒープ・サイズに関するさらなる情報が記載されています。

b. スレッド・プール・サイズ

サーバーで実行される各タスクは、WebSphere Application Server の多数のスレッド・プールのいずれかから取得したスレッド上で実行されます。スレッド・プールにより、サーバーのコンポーネントはスレッドを再利用できるので、新しい要求に応えて実行時に毎回新しいスレッドを作成する必要がなくなります。アプリケーション・サーバー内で最もよく使用される (そして、チューニングされる) スレッド・プールは以下の 3 つです。

  • Web コンテナー: HTTP 経由での要求時に使用されます。DayTrader アーキテクチャー図 (図 1) を見ると、ほとんどのトラフィックは Web コンテナー・スレッド・プール経由で DayTrader に入るのがわかります。
  • デフォルト: メッセージ駆動型 Bean に対する要求時、またはあるトランスポート・チェーンが特定のスレッド・プールに限定されていない場合に使用されます。
  • ORB: EJB アプリケーション・クライアント、リモート EJB インターフェース、または別のアプリケーション・サーバーから、エンタープライズ Bean に対するリモート要求が RMI/IIOP 経由であった場合に使用されます。

スレッド・プールに関連した重要なチューニング可能オプションを表 2 に示します。

表 2. チューニング可能なスレッド・プール・オプション
設定説明
最小サイズプール内で許容されるスレッド数の最小値です。アプリケーション・サーバーの起動時に、最初からスレッド・プールに割り当てられるスレッドはありません。アプリケーション・サーバーに割り当てられたワークロードからの要求があると、プール内のスレッド数が最小サイズ・フィールドに指定された数になるまで、スレッドがスレッド・プールに追加されます。この時点以降、ワークロードの変化にしたがって、追加スレッドが追加されたり、削除されたりします。しかし、スレッドの一部がアイドル状態になっても、プール内のスレッド数は、最小サイズ・フィールドに指定された数より少なくなることはありません。
最大サイズデフォルトのスレッド・プール内のスレッド数の最大値を指定します。
スレッド非活動タイムアウトスレッドが再利用されるまで待機する非活動時間 (ミリ秒) を指定します。値 0 は待機しないことを示し、負の値 (0 未満) は永久に待機することを意味します。

コンピューターに 1 つのアプリケーション・サーバー・インスタンスがある場合、適切なやり方は、デフォルト・スレッド・プールに対してはサーバー CPU コアごとに 5 スレッド、ORB スレッド・プールと Web コンテナー・スレッド・プールに対してはサーバー CPU ごとに 10 スレッドを使用することです。CPU が 4 個以下のコンピューターの場合、通常はデフォルト設定がほとんどのアプリケーションにとって適切な開始点になります。コンピューターに複数のアプリケーション・サーバー・インスタンスがある場合は、スレッド・プール・サイズを相応に減らす必要があります。逆に、遅い I/O や長時間のバックエンド接続のために、状況によってはスレッド・プール・サイズを増やす必要がある場合もあります。表 3 に、最も一般的なチューニングをされたスレッド・プール向けの、デフォルトのスレッド・プール・サイズと非活動タイムアウトを示します。

表 3. デフォルトのスレッド・プール・サイズと非活動タイムアウト
スレッド・プール最小サイズ最大サイズ非活動タイムアウト
デフォルト:20205000 ミリ秒
ORB10503500 ミリ秒
Web コンテナー505060000 ミリ秒

スレッド・プール設定を変更するには、管理コンソールから、「Servers (サーバー)」 => 「Application Servers (アプリケーション・サーバー)」 => [サーバー名] => 「Thread Pool (スレッド・プール)」の順にナビゲートします。パフォーマンス・アドバイザーを使用して、スレッド・プール・サイズや他の設定の推奨値を得ることもできます。

IBM Tivoli® Performance Viewer は、管理コンソールに組み込まれているツールであり、ほとんどすべてのサーバー・コンポーネントと関連した PMI (Performance Monitoring Infrastructure) データを参照できます。このビューアーは、システムを最適なパフォーマンスにするチューニングに役立つアドバイスを提供し、非効率的な設定に対する代替案を提案します。Tivoli Performance Viewer で PMI データを利用可能にして参照する方法については、WebSphere Application Server のインフォメーション・センターを参照してください。

図 9 に、DayTrader アプリケーションが増加し、定常的な高負荷状態で実行されている間の、Web コンテナー・スレッド・プールの PMI データを示します。プール・サイズ (オレンジ) はプール内の平均スレッド数、アクティブ・カウント (赤) は同時にアクティブなスレッド数です。このグラフは、最大 Web コンテナー・スレッドのデフォルト設定 (50 本) が、このケースではうまく機能していることを示しています。つまり、50 本のスレッドすべてが割り当てられているわけではなく、同時ワークロードの平均では約 18 本のスレッドを使用しているからです。デフォルトのスレッド・プール・サイズで十分だったので、スレッド・プール・サイズは変更されませんでした。

図 9. Web コンテナー・スレッド・プールに対する PMI データ
Web コンテナー・スレッド・プールに対する PMI データ
Web コンテナー・スレッド・プールに対する PMI データ

WebSphere Application Server V6.x より前のバージョンでは、同時クライアント接続数と Web コンテナー・スレッド・プール内のスレッド数は 1 対 1 で対応していました。言い換えると、アプリケーションにアクセスするクライアント数が 40 個だとすると、その要求を処理するために 40 本のスレッドが必要でした。WebSphere Application Server V6.0 と 6.1 では、ネイティブ I/O (NIO) と非同期 I/O (AIO) が導入され、比較的少ないスレッド数で何千ものクライアント接続にまで拡張できる能力を獲得しました。これが、図 9 において、HTTP ロード・ドライバーからの 50 本の同時クライアント接続をサポートするために、なぜ平均で 18 本のスレッドが使用されたのかの理由です。この情報に基づいて、スレッド・プール・サイズを小さくして、必要以上に大きいスレッド・プールの管理に関わるオーバーヘッドを削減できます。しかし、多数のスレッドが実際に必要なピーク負荷に対しては、サーバーの応答能力が低下します。スレッド・プール・サイズを決定するときは、予想される平均およびピーク時のワークロードなどを慎重に考慮する必要があります。

c. 接続プール・サイズ

アプリケーションがバックエンド・ストア (データベースなど) にアクセスしようとするたびに、そのデータ・ストアへの接続の作成、維持、および解放のためのリソースが必要になります。このプロセスがアプリケーション・リソース全体に及ぼす負担を軽減するため、アプリケーション・サーバーは、アプリケーション・サーバー上でアプリケーションが共有できるバックエンド接続のプールを設置できるようにします。接続プールによって、接続オーバーヘッドが、複数のユーザー要求全体に分散されるので、その後の要求のために必要なアプリケーション・リソースを節約できます。接続プールに関連した重要なチューニング可能オプションを表 4 に示します。

表 4. 接続プールのチューニング・オプション
設定説明
最小接続数維持すべき物理接続数の最小値です。接続プールのサイズが最小接続プール・サイズ以下になると、未使用のタイムアウト・スレッドは物理接続を廃棄しなくなります。ただし、プール単独では、最小接続プール・サイズを維持するために、接続を作成することはありません。
最大接続数このプール内に作成できる物理接続数の最大値です。これらは、バックエンド・データ・ストアへの物理接続です。この数に達すると、新しい物理接続は作成されなくなります。そうすると、要求側は、現在使用中の物理接続がプールに返されるか、接続タイムアウト設定に基づいて ConnectionWaitTimeoutException がスローされるまで待つ必要があります。最大接続数の値を高く設定すると、バックエンド・リソースを圧迫するほどの接続要求が行われる可能性があります。
スレッド非活動タイムアウトスレッドが再利用されるまで待機する非活動時間 (ミリ秒) を指定します。値 0 は待機しないことを示し、負の値 (0 未満) は永久に待機することを意味します。

接続プールのチューニングの目標は、データベースへの接続を必要とする各スレッドが 1 つの接続を保持し、要求がデータベースへのアクセス待ちのキューに入らないようにすることです。DayTrader アプリケーションの場合、各タスクはデータベースに対するクエリーを実行します。各スレッドが 1 つのタスクを実行するので、同時に存在するスレッドがそれぞれデータベース接続を必要とします。一般に、すべての要求は HTTP 経由でなされ、Web コンテナー・スレッドで実行されます。したがって、最大接続プール・サイズは、少なくとも Web コンテナー・スレッド・プールの最大サイズと同じ大きさにする必要があります。

ただし、これがすべてのシナリオに対するベスト・プラクティスというわけではないので注意してください。Web コンテナー・スレッド・プールより大きいサイズか同じサイズの接続プールを使用すれば、接続を待機しているスレッドは確実になくなり、1 台のサーバーで最大のパフォーマンスが実現されるようになります。一方で、多数のアプリケーション・サーバーがすべて同じバック・エンド・データベースに接続するような環境では、接続プール・サイズを注意深く検討する必要があります。例えば、10 台のアプリケーション・サーバーがすべて、接続プールに 50 の接続を持つ 1 つのデータベースにアクセスする場合、そのデータベースには一度に最大 500 の接続が要求されることになります。このような負荷によって、データベースでは簡単に問題が発生する可能性があります。

このような場合に適した方法は、Web コンテナーのスレッド数が接続プールの接続数よりも必ず多くなるような「じょうご式」の方法です。この方法を使えば、負荷が極めて高い状況下でも、すべてのアクティブなスレッドが同時にデータベースに接続しているようなことはなくなります。この方法では、応答時間は長くなりますが、はるかに安定した環境が提供されるようになります。

一般的なベスト・プラクティスは、どのスレッド・プールがデータ・ソース接続を要求するタスクに対応するかを決めて、それに応じてプール・サイズを決めることですが、ここでは 1 台のサーバーで最大のパフォーマンスを実現することに重点を置いているので、最大接続プール・サイズを、デフォルトの最大接続プール・サイズと Web コンテナー・スレッド・プールの最大サイズの合計 (70) に設定しました。接続プール設定を変更するには、管理コンソールから、「Resources (リソース)」 => 「JDBC」 => 「Data Sources (データ・ソース)」 => [データ・ソース名] => 「Connection pool properties (接続プール・プロパティー)」の順にナビゲートします。接続管理の観点からみると、すべてのアプリケーションが DayTrader のように動作するわけではなく、スレッドごとに複数の接続を使用する場合もあることに注意してください。

図 10 に、DayTrader アプリケーションが定常的な高負荷状態で、デフォルトの接続プール・サイズが最小 1、最大 10 として実行されている場合の、接続プールに対する PMI データを示します。FreePoolSize (オレンジ) はプール内の空き接続数、UseTime (緑) は接続が使用される平均時間 (ミリ秒) です。このグラフは、10 本の接続すべてが常に使用中だったことを示します。グラフ化されたメトリックに加え、この表にはその他の重要なメトリックもいくつか示されています。WaitingThreadCount は、33 本のスレッドがデータベースへの接続を待っていることを示し、その平均 WaitTime は 8.25 ミリ秒です。また、PercentUsed メトリックで示されているように、プール全体の使用率は 100% です。

図 10. 接続プールをチューニングする前の PMI データ
接続プールをチューニングする前の PMI データ
接続プールをチューニングする前の PMI データ

図 11 に、接続プールのサイズを最小 10、最大 70 にチューニングした後の同じチャートを示します。これは使用可能な空き接続が多数あり、接続待ちのスレッドがなかったことを示しています。これにより、応答時間が大幅に短くなっています。

図 11. 接続プールをチューニングした後の PMI データ
接続プールをチューニングした後の PMI データ
接続プールをチューニングした後の PMI データ
図 12. 接続プール・サイズのチューニングによるパフォーマンスの向上
接続プール・サイズのチューニングによるパフォーマンスの向上
接続プール・サイズのチューニングによるパフォーマンスの向上

詳細については、以下のトピックを参照してください。

d. データ・ソース・ステートメントのキャッシュ・サイズ

データ・ソース・ステートメントのキャッシュ・サイズでは、接続ごとにキャッシュできる準備済み JDBC ステートメント数を指定します。WebSphere Application Server データ・ソースは、準備済みステートメントと呼び出し可能ステートメントの処理を最適化します。この最適化は、アクティブな接続で使用されていない準備済みステートメントをキャッシュすることで行われます。アプリケーションが DayTrader のように多数のステートメントを利用する場合は、このパラメーターを増やすことでアプリケーションのパフォーマンスが向上する可能性があります。ステートメントのキャッシュ・サイズを構成するには、「Resources (リソース)」 => 「JDBC」 => 「Data sources (データ・ソース)」 => 「[データ・ソース名]」 => 「WebSphere Application Server data source properties (WebSphere Application Server データ・ソース・プロパティー)」の順にナビゲートします。

データ・ソース・ステートメントのキャッシュ・サイズは、いくつかの方法でチューニングできます。1 つのテクニックは、すべての一意の準備済みステートメント用のアプリケーション・コード (またはデータベースやデータベース・ドライバーから収集した SQL トレース) を調べて、キャッシュ・サイズがその値より大きいことを確認することです。もう 1 つのテクニックは、PMI データによってこれ以上キャッシュが廃棄されないようになるまで、キャッシュ・サイズを少しずつ増やし、定常的な高負荷状態でアプリケーションを実行することです。図 13 に、接続プールの同じ PMI チャートを示しますが、ここではデータ・ソース・ステートメントのキャッシュ・サイズがデフォルト・サイズ (10) から 60 に増加しています。PrepStmtCacheDiscardCount メトリック (赤) は、キャッシュが満杯なので廃棄されたステートメントの数です。図 11 のチャートに戻ると、データ・ソース・ステートメントのキャッシュ・サイズのチューニング前は、廃棄されたステートメント数は 170 万個を超えていました。それに対して、図 13 のチャートでは、キャッシュ・サイズのチューニング後はステートメントが廃棄されなかったことを示しています。

図 13. データ・ソース・ステートメントのキャッシュ・サイズのチューニング後の PMI メトリック
データ・ソース・ステートメントのキャッシュ・サイズのチューニング後の PMI メトリック
データ・ソース・ステートメントのキャッシュ・サイズのチューニング後の PMI メトリック
図 14. データ・ソース・ステートメントのキャッシュ・サイズの増加によるパフォーマンスの向上
データ・ソース・ステートメントのキャッシュ・サイズの増加によるパフォーマンスの向上
データ・ソース・ステートメントのキャッシュ・サイズの増加によるパフォーマンスの向上

詳細については、次のトピックを参照してください。

e. ORB 参照渡し

ORB (Object Request Broker) 参照渡しオプションにより、EJB 要求に関連するパラメーター・オブジェクトを処理する場合に、参照渡しセマンティクスを使用するか、値渡しセマンティクスを使用するかどうかを決めることができます。このオプションを見つけるには、管理コンソールで、「Servers (サーバー)」 => 「Application Servers (アプリケーション・サーバー)」 => [サーバー名] => 「Object Request Broker (オブジェクト・リクエスト・ブローカー) (ORB)」の順にナビゲートします。デフォルトでは、このオプションは無効 (値渡し) になっており、各パラメーター・オブジェクトのコピーが作成され、呼び出された EJB メソッドに渡されます。この方法は、既存のパラメーター・オブジェクトの単なる参照を渡すよりも、大幅に負担がかかります。

まとめると、ORB 参照渡しオプションは、基本的には呼び出された EJB メソッドを (リモート・インターフェースを持つ EJB の場合でも) ローカル呼び出しとして扱い、必要なオブジェクトのコピーを回避します。リモート・インターフェースが必須ではない場合、チューニングが不要で少し簡単な代替手段として、ローカル・インターフェースを持つ EJB を使用することができます。しかし、リモート・インターフェースでなくローカル・インターフェースを使用することにより、一般にリモート・インターフェースに関連する利点である、分散環境でのロケーションの透過性、およびワークロード管理機能が失われてしまいます。

ORB 参照渡しオプションがその利点を発揮するのは、EJB クライアント (つまり、サーブレット) と、呼び出される EJB モジュールが同じクラスローダー内にある場合だけです。つまり、EJB クライアントと EJB モジュールの両方が同じ EAR ファイルでデプロイされ、同じアプリケーション・サーバー・インスタンス上で実行される必要があることを意味します。EJB クライアントと EJB モジュールが異なるアプリケーション・サーバー・インスタンスにマップされた場合 (しばしば分割層と呼ばれます) は、EJB モジュールは値渡しセマンティクスを使用してリモートで呼び出す必要があります。

DayTrader アプリケーションでは、同じ EAR 内に WEB モジュールと EJB モジュールの両方が含まれ、両方が同じアプリケーション・サーバー・インスタンスにデプロイされるので、ORB 参照渡しオプションを使用してパフォーマンスを向上させることができます。図 15 の測定で示されているように、サーブレットからのすべての要求がリモート・インターフェース経由でステートレス・セッション Bean に渡される DayTrader では、このオプションは非常に有効です。ただし、ダイレクト JDBC トランザクションと手動トランザクションの代わりに EJB コンテナーがバイパスされるダイレクト・モードの場合は除きます。

図 15. ORB 参照渡しによるパフォーマンスの向上
ORB 参照渡しによるパフォーマンスの向上
ORB 参照渡しによるパフォーマンスの向上

詳細については、次のトピックを参照してください。

高度なチューニング

このセクションでは以下の項目について説明します。

  1. サーブレット・キャッシング
  2. HTTP トランスポートにおけるパーシスタント接続
  3. ラージ・ページのサポート
  4. 未使用サービスの無効化
  5. Web サーバーの場所

a. サーブレット・キャッシング

WebSphere Application Server の DynaCache は、サーバーによって生成されたオブジェクトやページ・フラグメントに対して、一般的なメモリー内キャッシュ・サービスを提供します。DistributedMap インターフェースと DistributedObjectCache インターフェースをアプリケーション内で使用して、Java オブジェクトへの参照を後で使用するためにキャッシュ内に保存することによって、これらのオブジェクトをキャッシュして共有することができます。一方、サーブレット・キャッシングにより、サーブレットや JSP の応答フラグメントを保存し、カスタマイズ可能な一連のキャッシング・ルールによって管理できます。

DayTrader アプリケーションでは、ユーザーのホームページへアクセスするごとに市場概況 (Market Summary) が表示されます。この概況には、値上がり株および値下がり株の上位 5 位までのリスト、および現在の株価指数と出来高が含まれます。この処理には、データベース検索が数回必要なので、ユーザーのホームページの読み込みは大幅に遅くなります。サーブレット・キャッシングでは、marketSummary.jsp をキャッシュすることで負担の大きいデータベース検索を事実上なくし、ユーザーのホームページの応答時間を改善できます。キャッシュされたオブジェクトの更新間隔は構成可能で、リスト 1 に示す例では、60 秒に設定されています。Dynacache を、DayTrader 内の別のサーブレットや JSP のフラグメント、およびデータをキャッシュするために使用することもできます。ここでは、キャッシングによってパフォーマンスを向上し、複雑なサーバー処理を回避した例を示します。

サーブレット・キャッシングを有効にするには、管理コンソールで、「Servers (サーバー)」 => 「Application Servers (アプリケーション・サーバー)」 => [サーバー名] => 「Web Container Settings (Web コンテナー設定)」 => 「Web Container (Web コンテナー)」の順にナビゲートします。キャッシュするサーブレットまたは JSP の URI パスは、cachespec.xml ファイルに定義する必要があります。このファイルは、Web モジュールの WEB-INF ディレクトリ内にあります。DayTrader の marketSummary.jsp の場合、cachespec.xml はリスト 1 と類似したものになります。

リスト 1. cachespec.xml
cachespec.xml
cachespec.xml
図 16. サーブレット・キャッシングによるパフォーマンスの向上
サーブレット・キャッシングによるパフォーマンスの向上
サーブレット・キャッシングによるパフォーマンスの向上

詳細については、以下のトピックを参照してください。

b. HTTP トランスポートにおけるパーシスタント接続

パーシスタント接続では、発信 HTTP の応答は、1 つの要求または応答の交換が行われた後でクローズする接続ではなく、パーシスタント (キープアライブ) 接続を使用することを指定します。多くの場合、1 つの HTTP 接続で許可されるパーシスタント要求の最大数を増やすことで、パフォーマンスの向上を実現できます。SSL 接続では、接続当たりのパーシスタント要求数を無制限にすると、大幅なパフォーマンスの向上が見られます。というのは、SSL ハンドシェイク・プロセスを完了するためのキー交換とプロトコル・ネゴシエーションに、負担の大きいオーバーヘッドが発生するためです。接続当たりに処理できる要求数を最大にすると、このオーバーヘッドの影響は最小限に抑えられます。また、応答時間の短い、高スループットのアプリケーションでは、要求ごとに接続のオープンとクローズを繰り返すより、接続をオープンしたままにしておくことでパフォーマンスを向上させることができます。このプロパティーを 0 (ゼロ) に設定すると、アプリケーション・サーバーが実行されている限り、接続はオープンされたままになります。しかし、セキュリティーが問題になる場合は、この設定については慎重に検討してください。クライアントがキープアライブ接続に留まろうとする場合、このパラメーターは DoS 攻撃の防止に役立ちます。

HTTP トランスポートのパーシスタント接続を設定するには、管理コンソールから、「Servers (サーバー)」 => 「Application Servers (アプリケーション・サーバー」 => [サーバー名] => 「Ports (ポート)」の順にナビゲートします。そこで、変更したい HTTP トランスポート・チャネル設定と関連したポートを見つけて、「関連トランスポートの表示」をクリックしてください。

DayTrader のテストにおいて、「接続当たりの最大パーシスタント要求数」の値を 100 (デフォルト) から無制限に変更してテストを実施しました。図 17 のチャートに、標準 HTTP (SSL なし) と HTTPS (SSL) 経由でシンプルな「Hello World」サーブレットにアクセスした場合のスループットの結果を示します (接続当たりのパーシスタント要求数を無制限にする前と後の両方)。

図 17. 接続当たりのパーシスタント要求数を無制限にした場合のパフォーマンスの向上
接続当たりのパーシスタント要求数を無制限にした場合のパフォーマンスの向上
接続当たりのパーシスタント要求数を無制限にした場合のパフォーマンスの向上

詳細については、次のトピックを参照してください。

c. ラージ・ページのサポート

いくつかのプラットフォームでは、デフォルトのメモリー・ページ・サイズより大きなメモリー・ページを使用して、連続した大規模メモリー・セクションを確立することができます。プラットフォームによって異なりますが、デフォルトのページ・サイズ 4 KB に対し、ラージ・メモリー・ページ・サイズは 4 MB (Windows) から 16 MB (AIX) の範囲になります。多くのアプリケーション (Java ベースのアプリケーションも含みます) では、管理するページ数が少なくなることで CPU オーバーヘッドが減るので、多くの場合、ラージ・ページから恩恵を受けます。

ラージ・メモリー・ページを使用するには、最初にオペレーティング・システム内で定義して有効にする必要があります。各プラットフォームには、ラージ・ページのサポートを有効にする前に構成しなければならないさまざまなシステム要件があります。WebSphere Application Server のインフォメーション・センターには、以下に示すプラットフォーム別に、必要なステップが記載されています。

オペレーティング・システム内での構成が完了すると、JVM 内でのラージ・ページのサポートを有効にできます。これを行うには、管理コンソールで 「Servers (サーバー)」 => 「Application Servers (アプリケーション・サーバー)」 => [サーバー名] => 「Process Definition (プロセス定義)」 => 「Java Virtual Machine (Java 仮想マシン)」 の順にナビゲートし、「汎用 JVM 引数」の設定で「-Xlp」を指定します。ラージ・ページが有効になると、オペレーティング・システムは JVM 用に連続した大きなメモリー・チャンクを確保します。メモリーの残量が実行中の他のアプリケーションを処理するために十分ではない場合は、ページング (メモリー中のページを、ハードディスク上のページへスワッピング) が発生して、システム・パフォーマンスが大幅に低下します。

図 18. ラージ・ページによるパフォーマンスの向上
ラージ・ページによるパフォーマンスの向上
ラージ・ページによるパフォーマンスの向上

詳細については、以下のトピックを参照してください。

d. 未使用サービスの無効化

アプリケーションが必要としない未使用のサービスを無効にすると、パフォーマンスを向上させることができます。このような例の 1 つが PMI です。ただし、この記事で説明してきたメトリックを表示したり、パフォーマンス・アドバイザーからアドバイスを受けたりするには、PMI を有効にする必要があることに注意してください。PMI を無効にすると、これらの情報を参照できなくなりますが、パフォーマンスは少し向上します。PMI は個々のアプリケーション・サーバー単位で無効にできます。これを行うには、管理コンソールから、「モニターとチューニング」 => 「Performance Monitoring Infrastructure (PMI)」の順にナビゲートします。

図 19. PMI の無効化によるパフォーマンスの向上
PMI の無効化によるパフォーマンスの向上
PMI の無効化によるパフォーマンスの向上

詳細については、次のトピックを参照してください。

e. Web サーバーの場所

IBM HTTP Server などの Web サーバーを WebSphere Application Server デプロイメントの前面で使用して、静的コンテンツを処理したり、ワークロード管理 (WLM) 機能を提供したりすることがよくあります。WebSphere Application Server V6 より前のバージョンでは、前述のとおり、クライアント接続と Web コンテナー・スレッドが 1 対 1 で対応していたので、何千もの着信クライアント接続を効率的に処理するためにも Web サーバーが必要でした。しかし、WebSphere Application Server V6 以降は、NIO と AIO の導入によって必要なくなりました。Web サーバーを使用する環境では、Web サーバー・インスタンスは WebSphere Application Server インスタンスとは別の専用システムに配置する必要があります。Web サーバーを WebSphere Application Server インスタンスのあるシステム上に配置すると、貴重なプロセッサー・リソースを事実上共有することになり、構成全体のスループットが低下します。

IBM HTTP Server を WebSphere Application Server と同じマシン上にローカルに配置して、ある DayTrader テストを実施しました。別のテストは、Web サーバーを別の専用マシン上にリモートに配置して実施しました。表 5 に、Web サーバーとアプリケーション・サーバーが同じシステム上に配置された場合に、各プロセスによって消費される CPU サイクルの割合を示します。結果からわかるとおり、CPU の約 25% は HTTP Server のプロセスによって消費されました。これは、このテストで使用した 4 CPU システムのうち 1 つの CPU に相当します。

表 5. HTTP Server による CPU 使用率
プロセスCPU %
WebSphere Application Server66.3
IBM HTTP Server26.2

図 20 に、これら 2 つのシナリオと、Web サーバーがまったくない場合の、スループットと応答時間の比較を示します。

図 20. Web サーバーがある場合とない場合のスループット
Web サーバーがある場合とない場合のスループット
Web サーバーがある場合とない場合のスループット

非同期メッセージングのチューニング

ここまでのこの記事のほとんどの部分では、DayTrader アプリケーションと WebSphere Application Server の中核をなす Web サービスとパーシスタンスの側面に焦点を当ててきました。ここからは、DayTrader が JMS コンポーネントをどのように使用して、非同期の売買注文を処理したり、株価相場の変動をモニターしたりするかについて焦点を当てます。DayTrader ベンチマーク・アプリケーションには、個別に有効にしたり無効にしたりできる、以下に示す 2 つのメッセージング機能があります。

  • 非同期の注文処理: JMS キューと MDB によって非同期の売買注文を処理します。
  • 相場価格の一貫性のトラッキング: JMS トピックと MDB を使用して、株式売買注文と関連した株価の変動をモニターします。

メッセージ・ストアのタイプとメッセージの信頼性は、メッセージング構成と関連する、パフォーマンスに重大な影響を与える 2 つの主要チューニング・オプションです。これらのオプションと並んで、さらにパフォーマンスを向上させる高度なチューニング・テクニックは、高速ディスク上にトランザクション・ログとファイル・ストア (該当する場合) を配置するテクニックです。各トピックとそれに対応したパフォーマンスの向上について、これから詳しく説明します。

このセクションでは以下に示すトピックを説明します。

  1. メッセージ・ストアのタイプ
  2. メッセージの信頼性レベル
  3. トランザクション・ログとファイル・ストアの高速ディスクへの移動

a. メッセージ・ストアのタイプ

WebSphere Application Server の内部メッセージング・プロバイダーには、メッセージング・エンジンの「データ・ストア」という概念があります。このデータ・ストアは、エンジンによって処理されるメッセージのパーシスタント・リポジトリーとして機能します。シングル・サーバー環境でメッセージング・エンジンが作成されると、デフォルトのデータ・ストアとして使用されるファイル・ベースのストアが作成されます。WebSphere Application Server V6.0.x のデフォルトのデータ・ストアは、ローカルのプロセス内 Derby データベースによって提供されていました。ファイル・ベースのデータ・ストアと Derby ベースのデータ・ストアはシングル・サーバーのシナリオでは便利ですが、最高レベルのパフォーマンス、スケーラビリティー、管理の容易性、および高可用性は提供されません。このような要件を満たすには、以下に示すリモート・データベースによるデータ・ストアを使用します。

  • ローカル Derby データベースによるデータ・ストア: このオプションでは、ローカルのプロセス内 Derby データベースを使用して、メッセージング・エンジンと関連した運用情報やメッセージを保存します。開発目的では便利ですが、この構成では、保存されたメッセージを管理するために、アプリケーション・サーバー内の貴重なサイクルやメモリーを使用してしまいます。
  • ファイル・ベースのデータ・ストア: (デフォルト) ファイル・ベースのデータ・ストアを使用するようにメッセージ・エンジンが構成されている場合、運用情報やメッセージは、データベースではなくファイル・システムに保持されます。ファイル・システムは、ローカル Derby データベースより高速に実行されますが、さらに RAID などの高速ディスクを使用すると、ちょうどリモート・データベースと同じ速さで実行できます。ただし、以下に示したテストでは、ファイル・ベースのデータ・ストアに RAID デバイスを使用していないので、この追加のパフォーマンスの向上は結果に反映されていません。
  • リモート・データベースによるデータ・ストア: この構成では、リモート・システム上にあるデータベースがメッセージ・エンジンのデータ・ストアとして動作するように構成されます。Derby データベースやファイル・ベースのストアの管理のために使用されていたアプリケーション・サーバーの JVM プロセス用サイクルが、これによって解放され、さらに高性能な運用レベルのデータベース・サーバー (IBM DB2® Enterprise Server など) を使用できるようになります。データ・ストア用にデータベースを使用する技術的な利点の 1 つは、いくつかの J2EE™ アプリケーションでは 1 フェーズ・コミットの最適化から利益を得られるように、JDBC 接続を共有できることです。詳細については、1 フェーズ・コミットの最適化から利益を得る、接続の共有に関する情報を参照してください。ファイル・ストアは、この最適化には対応していません。

EJB 非同期モードで、この 3 種類のメッセージ・ストアのタイプを使用して DayTrader を実行しました。実行中、org.apache.geronimo.samples.daytrader.util.Log=all でトレース指定を有効にして、TradeBrokerMDB へのメッセージを受信した時刻を取得しました。非同期メッセージングのパフォーマンスを測定する際は、常に非同期の MDB 応答時間を測定基準とすることが重要です。同期している実際のページ応答時間は基準にはなりません。図 21 の結果によると、リモート・データベースによるデータ・ストアが、最短の MDB 応答時間と最高のスループットを示し、最高のパフォーマンスを実現しています。

図 21. メッセージ・ストアのタイプによるパフォーマンスの比較
メッセージ・ストアのタイプによるパフォーマンスの比較
メッセージ・ストアのタイプによるパフォーマンスの比較

詳細については、次のトピックを参照してください。

b. メッセージの信頼性レベル

メッセージの信頼性は、メッセージング・システムの重要な要素であり、WebSphere Application Server メッセージング・プロバイダーは 5 つの異なる信頼性レベルを提供します。

  • ベスト・エフォート非パーシスタント
  • 高速非パーシスタント
  • 高信頼性非パーシスタント
  • 高信頼性パーシスタント
  • 保証パーシスタント

パーシスタント・メッセージは、常に何らかの永続的なデータ・ストアに保存されますが、非パーシスタント・メッセージは通常は揮発性のメモリーに保存されます。メッセージの配信の信頼性と、その配信速度との間には、トレードオフがあります。図 22 に、異なる信頼性レベル (保証パーシスタントと高速非パーシスタント) のファイル・ストアを使用した、2 つのテストの実行結果を示します。結果は、信頼性レベルが下がるとメッセージの処理速度が上がることを明確に示しています。

図 22. メッセージの信頼性レベルによるパフォーマンスの比較
メッセージの信頼性レベルによるパフォーマンスの比較
メッセージの信頼性レベルによるパフォーマンスの比較

詳細については、次のトピックを参照してください。

c. トランザクション・ログとファイル・ストアの高速ディスクへの移動

ディスク I/O 操作は負担が大きいので、RAID などの高速ディスクにログ・ファイルを保存すると、パフォーマンスを大幅に向上させることができます。ほとんどの RAID 構成では、物理メディアへのデータの書き込みタスクは、複数のドライブ全体で分担しています。このテクニックにより、トランザクション情報を保持するストレージへの同時アクセス数を増加させることができ、ログからそのデータへのアクセスが高速になります。

トランザクション・ログ・ディレクトリーを設定するには、管理コンソールから、「Servers (サーバー)」 => 「Application Servers (アプリケーション・サーバー)」 => [サーバー名] => 「Container Services (コンテナー・サービス)」 => 「Transaction Service (トランザクション・サービス)」の順にナビゲートします。

ファイル・ストアのログ・ディレクトリは、SIBus メンバーの作成中に、AdminTask addSIBusMember コマンドの -logDirectory オプションを使用するか、または管理コンソールの SIBus メンバー作成パネルを用いて指定できます。

図 23 に、2 つのテストの実行結果を示します。1 つのテストではトランザクション・ログとファイル・ストアをハード・ドライブ上にローカルに保存し、もう 1 つのテストではそれらを RAMDisk (高速読み取りと書き込みのために、基本的にはメモリーのあるセクションをハードディスクとみなしたもの) 上に保存しています。この実行には、信頼性レベルとして高速非パーシスタントを使用しました。結果によると、ログを高速ディスクに保存した方が、応答時間とスループットが少し向上しました。

図 23. 高速ディスクの使用によるパフォーマンスの向上
高速ディスクの使用によるパフォーマンスの向上
高速ディスクの使用によるパフォーマンスの向上

詳細については、以下のトピックを参照してください。

まとめ

IBM WebSphere Application Server は、増加し続けるさまざまな領域のアプリケーションをホストするよう設計されていますが、アプリケーションそれぞれが独自の機能、要件、およびサービスを持っています。この柔軟性により、あるアプリケーション・サーバーをまったく同じ方法で使用するアプリケーションは二つとなく、1 組のチューニング・パラメーターが 2 つの異なるアプリケーションに対して最高のパフォーマンスをもたらすことはないということがわかります。

DayTrader が皆さんのアプリケーションと似ていないとしても、何をチューニングすべきか、どのようにチューニングに取り掛かればよいかを理解するための手法は同じです。重要なことは、アプリケーションのアーキテクチャーに基づいて、アプリケーションが使用する主要サーバー・コンポーネントとリソースを識別し、それらに焦点を当てることです。一般に、多くのアプリケーションでは、JVM、スレッド・プール、および接続プールという 3 つの主要領域のチューニングによってパフォーマンスが向上します。他のチューニング可能要素からも同じ程度の労力に見合ったパフォーマンスの向上が得られるかもしれませんが、通常は、アプリケーションが使用する特定の WebSphere Application Server 機能に限定されます。

この記事では、DayTrader アプリケーションに利益のある、一連の重要なチューニング可能要素および他のオプションについて説明しました。各オプションについては、チューニング可能で汎用的な推奨事項やトレードオフに関する注意事項、および関連ツールがある場合はその参照先の情報を示しました。図 24 に、DayTrader の実行時のモードごとに、以下に示すチューニング・オプションが適用された場合の全体的なパフォーマンスの向上を示します。

  • JVM ヒープ・サイズ
  • スレッド・プール・サイズ
  • 接続プール・サイズ
  • データ・ソース・ステートメントのキャッシュ・サイズ
  • ORB 参照渡し
  • サーブレット・キャッシング
  • 無制限のパーシスタント HTTP 接続
  • ラージ・ページのサポート
  • PMI の無効化
図 24. チューニング・オプション適用後の全体的なパフォーマンスの向上
チューニング・オプション適用後の全体的なパフォーマンスの向上
チューニング・オプション適用後の全体的なパフォーマンスの向上

この図から明確にわかるように、これらのチューニングにより、EJB モードでは 169%、セッション・ダイレクト・モードでは 207%、ダイレクト・モードでは 171% のパフォーマンスの向上が達成されています。これはかなり大きな向上ですが、他のアプリケーションでも同様のパフォーマンス向上を実現できます。ただし、この記事で説明した要因、また説明していない別の要因によっても、結果は変わってくることに注意する必要があります。

この記事で説明した情報やツールによっていくつかの重要な見識が得られ、特定のアプリケーションに対するアプリケーション・サーバーのチューニング作業の手ごわさが和らぎ、怖がらなくても済むようになることと思います。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere
ArticleID=604997
ArticleTitle=ケース・スタディー: WebSphere Application Server V7、V8 のパフォーマンス・チューニング
publish-date=04202012