3 パフォーマンス・チューニングのロードマップ

この章では、システム・パフォーマンスの向上に利用できるチューニングのロード・マップおよびヒントを示します。

• パフォーマンス・チューニングのロードマップ

• チューニングのヒント

パフォーマンス・チューニングのロードマップ

ここでは、現在のアプリケーション環境をチューニングしてパフォーマンスを最適化するのに役立つロードマップを示します。

1. パフォーマンスに関する目標の設定

2. パフォーマンス・メトリックの測定

3. システムにおけるボトルネックの特定

4. ボトルネックによる影響の軽減

5. パフォーマンス目標の達成

パフォーマンスに関する目標の設定

パフォーマンスの目標を決めるには、デプロイされているアプリケーションや、システム環境の制約について理解する必要があります。アプリケーションのコンポーネントの条件にかなうアクティビティのレベルに関する情報を収集してください。これには次のものが含まれます。

• 予想されるユーザーの数

• リクエストの数とサイズ

• データの量と一貫性

• 目標とするCPU使用率

  目標とするCPU使用率を100%にすることはできません。目標とするCPU使用率は、使用しているアプリケーションのニーズ(ピーク使用時のCPUサイクルなど)に基づいて決定する必要があります。通常の負荷時にCPU使用率が100%に最適化されている場合、ピーク時の負荷を処理するキャパシティが残っていないことになります。待機時間に敏感なアプリケーションでは、高速なレスポンス時間を実現できることが重要になります。CPU使用率が高い(使用率が100%に近づく)と、レスポンス時間が長くなる場合があります。一方、スループットは一定に保たれるか、サーバーで処理がキューイングされるため増大します。このようなアプリケーションでは、CPU使用率を70 - 80%にすることをお薦めします。待機時間に敏感でないアプリケーションにおいては、90 %程度を目標に設定することをお薦めします。

パフォーマンスの目標は、次のような制約によって制限されます。

• CPUの種類、ディスク・サイズとディスク速度の関係、メモリーが足りているかどうかなど、ソフトウェアおよびハードウェアの構成

  ハードウェア要件を決定する式は、1つではありません。キャパシティ・プランニングとは、アプリケーションのニーズによってハードウェアおよびソフトウェアの構成のタイプを決定するプロセスです。キャパシティ・プランニングでは、システムのパフォーマンス目標の評価およびアプリケーションの理解が必要です。サーバーのハードウェアのキャパシティ・プランニングでは、最大パフォーマンス要件に重点をおく必要があります。付録B「キャパシティ・プランニング」を参照してください。

• ドメイン間での相互運用、レガシー・システムの使用、およびレガシー・データのサポートが可能かどうか

• 開発、実装、およびメンテナンスの費用

こうした情報を使用して、特定のハードウェアにおけるレスポンス時間、スループット、および負荷など、現在のアプリケーション環境における現実的なパフォーマンス目標を設定します。

パフォーマンス・メトリックの測定

「パフォーマンス目標の理解」でパフォーマンスの基準を決定した後、パフォーマンス目標の定量化に使用するメトリックを計測します。次の項では、基本パフォーマンス・メトリックの計測に関する情報が提供されています。

• ディスクおよびCPUの使用状況のモニター

• ネットワーク上のデータ転送のモニター

ディスクおよびCPUの使用状況のモニター

高い負荷をかけた状態でアプリケーションを実行して以下をモニターします。

• アプリケーション・サーバー(ディスクおよびCPUの使用率)

• データベース・サーバー(ディスクおよびCPUの使用率)

目的は、設定した目標のCPU使用率をアプリケーション・サーバーが達成することです。アプリケーション・サーバーのCPU使用率が低い場合は、データベースにボトルネックがないかどうかを確認します。データベース・サーバーのCPU使用率が100%に達する場合は、アプリケーションのSQL呼出し問合せのプランを見直します。たとえば、SQL呼出しで、索引を使用したりリニア検索を実行したりしていないかを確認します。また、データベース・サーバーのCPUに負荷がかかるORDER BY句を、アプリケーションで使用しすぎていないかどうかも確認します。第4章「オペレーティング・システムのチューニング」を参照してください。

データベース・サーバーのディスクがボトルネックになっている(ディスクの使用率が100%に達している)ことが判明したら、アプリケーションで必要とされるだけの書込みが実行できていないとみなし、より高速なディスクに交換するか、RAID (redundant array of independent disks)構成に変更します。

データベース・サーバーがボトルネックではないと判明したら、アプリケーション・サーバーのディスクがボトルネックになっていないかどうかを確認します。アプリケーション・サーバーのディスクがボトルネックになる原因としては以下が考えられます。

• 永続ストアの書込み

• トランザクション・ロギング(tlog)

• HTTPロギング

• サーバー・ロギング

アプリケーション・サーバーでのディスクI/Oを最適化する方法としては、より高速なディスクやRAIDの使用、JMSの同時書込みの無効化、tlogへのJTA直接書込みの使用、HTTPログ・バッファの増設などがあります。

ネットワーク上のデータ転送のモニター

アプリケーションとアプリケーション・サーバーおよびアプリケーション・サーバーとデータベース・サーバーの間で転送されるデータ量を確認します。このデータ量は、ネットワークの帯域幅を超えてはいけません。超えると、ネットワークがボトルネックになる可能性があります。「オペレーティング・システムのチューニング」を参照してください。

システムにおけるボトルネックの特定

ネットワークおよびデータベース・サーバーがボトルネックになっていないことが判明したら、オペレーティング・システム、JVM、およびWebLogic Serverの構成を調べます。もっとも重要なのは、クライアントの負荷が高い状態で、WebLogic Serverを実行するマシンのCPU使用率が目標値に達するかどうかです。目標値に達しない場合は、アプリケーション内でロックが発生していないかどうかを確認します。ボトルネックを特定してアプリケーションのパフォーマンスを向上させるには、市販されているツール(JProbe、OptimizeItなど)を使用してアプリケーションをプロファイリングします。

ヒント: CPU使用率が100%に達している場合でも、アプリケーションをプロファイリングしてパフォーマンスを向上させることをお薦めします。

ボトルネックによる影響の軽減

この手順では、現在の環境をチューニングして、設定したパフォーマンス目標に対するボトルネックの影響を軽減します。この手順では、ボトルネックの影響を排除するのではなく、軽減するという点に注意してください。チューニングでは、リソースを調整して設定したパフォーマンス目標を達成できます。このドキュメントで説明する範囲は次のとおりです(重要性の高い項目からリストされています)。

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

• DBのチューニング

• WebLogic Serverパフォーマンス・パラメータのチューニング

• JVMのチューニング

• オペレーティング・システムのチューニング

• WebLogic永続ストアのチューニング

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

『Oracle WebLogic Server: Optimizing WebLogic Server Performance』の著者を引用すると、「アプリケーションの設計がよい場合、パフォーマンスもよくなります。複雑すぎるアプリケーションまたは設計の悪いアプリケーションは、システム・レベル・チューニングおよびパフォーマンスを向上させるためにベストなプラクティスを行ったとしても、パフォーマンスは悪くなります。」つまり、設計の悪いアプリケーションでは、不必要なボトルネックが発生する可能性があります。たとえば、リソース競合は、アプリケーション・ドメインに伴うものではなく、悪い設計によるものである場合があります。

詳細は、次を参照してください:

• 第10章「WebLogic Server EJBのチューニング」

• 第11章「メッセージドリブンBeanのチューニング」

• 第12章「データ・ソースのチューニング」

• 第13章「トランザクションのチューニング」

• 第14章「WebLogic JMSのチューニング」

• 第15章「WebLogic JMSストア・アンド・フォワードのチューニング」

• 第16章「WebLogicメッセージング・ブリッジのチューニング」

• 第17章「リソース・アダプタのチューニング」

• 第18章「Webアプリケーションのチューニング」

• 第19章「Webサービスのチューニング」

• 第20章「WebLogic Tuxedo Connectorのチューニング」

DBのチューニング

データベースがエンタープライズ・レベルのボトルネックになる可能性もあります。データベースの最適化は複雑となる場合があるため、ベンダーに依存する場合があります。「データベースのチューニング」を参照してください。

WebLogic Serverパフォーマンス・パラメータのチューニング

WebLogic Serverでは、実際の環境やアプリケーションにあわせて細かくチューニングできるパフォーマンス関連の多数のOOTB (out-of-the-box)パラメータを使用しています。これらのパラメータをシステム要件に基づいてチューニングすることで、デフォルト設定のまま実行する場合に比べ、単一ノードのパフォーマンスおよびアプリケーションのスケーラビリティ特性を大きく向上させることができます。第7章「WebLogic Serverのチューニング」を参照してください。

JVMのチューニング

Java仮想マシン(JVM)は、マイクロプロセッサ上でJavaクラス・ファイルのバイト・コードを実行する仮想の「実行エンジン」インスタンスです。第5章「Java仮想マシン(JVM)のチューニング」を参照してください。

オペレーティング・システムのチューニング

設定されているデフォルトのチューニング・パラメータは、オペレーティング・システムによって異なります。Windowsプラットフォームの場合、通常はデフォルト設定を変更する必要はありません。一方、UNIXおよびLinuxオペレーティング・システムでは、通常は適切なチューニングを行う必要があります。第4章「オペレーティング・システムのチューニング」を参照してください。

パフォーマンス目標の達成

パフォーマンス・チューニングは反復操作です。システム上でボトルネックの影響を軽減したら、2つ目の手順の「パフォーマンス・メトリックの測定」に進み、パフォーマンス目標を満たしているかどうかを判断します。

チューニングのヒント

この項では、システム・パフォーマンス全体をチューニングする際のヒントおよびガイドラインを示します。

• パフォーマンス・チューニングは特効薬ではありません。すなわち、優れたシステム・パフォーマンスは、優れた設計、優れた実装、明確なパフォーマンス目標、およびパフォーマンス・チューニングに基づきます。

• パフォーマンス・チューニングは継続的操作です。設定したパフォーマンス目標に対して比較可能なパフォーマンス・メトリックを提供するメカニズムを実装します。これによって、システムに障害が発生する前にチューニング局面をスケジュールできます。

• 目的は、設定したパフォーマンス目標を満たすことであって、すべてのボトルネックを排除することではありません。システム内のリソースは有限です。本質的に、少なくとも1つのリソース(CPU、メモリー、またはI/O)がシステムのボトルネックになります。チューニングすることによって、設定したパフォーマンス目標に対するボトルネックの影響を軽減できます。

• 次の点を考慮したパフォーマンスを発揮するアプリケーションを設計します。

  • 何事もシンプルに保つ - 公開されているパターンを不適切に使用しないでください。

  • Java EEのパフォーマンス・パターンを適用します。

  • Javaコードを最適化します。