このタスクについて
パフォーマンス上の問題を解決するには、ほとんどの場合、次のプロセスを反復して行います。
1 つのボトルネックが除去されると、パフォーマンスはシステムの別の部分によって制限されるため、多くの場合はこのプロセスを反復して行います。
例えば、遅いハード・ディスクを高速のものと取り替えると、ボトルネックはシステムの CPU にシフトします。
システム・パフォーマンスの測定とパフォーマンス・データの収集
-
ベンチマーク、実行する操作の標準セットを選択して開始します。
このベンチマークでは、パフォーマンス上の問題があるアプリケーション機能が実行されます。
複雑なシステムでは、オブジェクトをキャッシュに入れたり、コード・パスを最適化したりする
ウォームアップ期間が必要となります。
ウォームアップ期間中のシステム・パフォーマンスは、通常、ウォームアップ期間後よりはるかに遅くなります。
ベンチマークは、パフォーマンス分析に使用される測定値を記録する前に、システムをウォームアップする作業を生成できなければなりません。
システムの複雑さに応じて、ウォームアップ期間の範囲は、数千のトランザクションから 30 分以上にまで変化します。
- 調査中のパフォーマンス上の問題が、多数のクライアントによってシステムが使用されたときにのみ発生する場合、
ベンチマークは複数のユーザーをシミュレートする必要もあります。
その他の重要な要件として、ベンチマークは同じ結果を繰り返し生成する必要があります。
実行するたびに結果が数パーセント以上異なる場合は、システムの初期状態が実行ごとに異なる可能性、
ウォームアップ期間に測定が行われている可能性、またはシステムが別にワークロードを実行している可能性を
考慮してください。
- 幾つかのツールを使用すると、ベンチマークの開発が容易になります。
ツールは、単に URL を起動するツールから、アプリケーションによって生成される動的データと対話可能な
スクリプト・ベースの製品まで、多岐にわたります。
IBM Rational には、テスト中にシステムと複雑な対話を生成し、多数のユーザーをシミュレートすることができるツールがあります。
便利なベンチマークを作成するには努力が必要であり、その作成は開発過程に含める必要があります。
アプリケーションの作成に入るまで待たずに、パフォーマンスの測定方法を決定してください。
- ベンチマークは、グラフやその他の分析技術が可能な形式で、スループットと応答時間の結果を記録します。
WebSphere Application Server Performance Monitoring Infrastructure (PMI) によって提供されるパフォーマンス・データは、アプリケーション・サーバーのパフォーマンスをモニターし、調整するために役立ちます。
要求メトリックは、WebSphere Application Server によって提供されるパフォーマンス・データの別のソースです。
要求メトリックによって、要求の時間を WebSphere Application Server コンポーネント境界で計り、
主なコンポーネントごとにかかる時間を判別することができます。
ボトルネックの発見
以下のシナリオおよび推奨解決策を参照してください。
- シナリオ: 単一ユーザーのみの使用によって、ローパフォーマンスが発生します。
推奨
解決策: 要求メトリックを使用して、
各コンポーネントが全体の応答時間にどのぐらい影響を与えているかを判別します。
ほとんどの時間を占めるコンポーネントに注目します。
Tivoli Performance
Viewer を使用して、ガーベッジ・コレクションの頻度など、リソースの消費を確認します。
問題を特定のメソッドに切り分けるには、コード・プロファイル・ツールが必要となる場合があります。
- シナリオ: 複数のユーザーの使用によってのみ、ローパフォーマンスが発生します。
推奨
解決策: システムで CPU、ネットワーク、またはディスクの使用率が高いかどうかを判別するために確認し、
これらに対処します。
クラスター化構成の場合は、クラスター・メンバー間でのロードの不均衡を確認します。
- シナリオ: いずれのシステムにも CPU、メモリー、ネットワーク、またはディスクの制約が
ないように見えますが、複数のユーザーの使用によるパフォーマンス上の問題が発生します。
推奨解決策:
- テスト中のシステムに作業が到達しているかを確認します。ある外部装置が、システムに到達する作業量を制限していないかを確認します。
Tivoli Performance Viewer は、システムの要求数を判別するのに役立ちます。
- スレッド・ダンプによって、同期化済みメソッド、またはリソースに対して待機している多数のスレッドでの
ボトルネックを明らかにできる場合があります。
- IBM HTTP Server、データベース、およびアプリケーション・サーバーで、作業を処理するためのスレッドが
十分に使用可能であることを確認します。反対に、スレッドが多すぎると、リソースの競合が増加し、
スループットが低下する場合があります。
- Tivoli Performance Viewer、または Java 仮想マシンの verbosegc オプションでガーベッジ・コレクションを
モニターします。
過度のガーベッジ・コレクションは、スループットを制限する場合があります。
ボトルネックの除去
ボトルネックを除去するには、以下のような方法があります。
- 要求の削減
- リソースの増加
- ワークロード分散の改善
- 同期の削減
幾つかの方法で、リソースに対する要求を削減することができます。
キャッシングを使用すると、以前にキャッシュされた応答を戻すことによって、システム・リソースの使用を大幅に
削減することができます。
これによって、元の応答を構成する必要のある作業を回避します。
キャッシングは、以下のシステムの幾つかのポイントでサポートされています。
- IBM HTTP Server
- コマンド
- Enterprise Bean
- オペレーティング・システム
アプリケーション・コード・プロファイルを使用すると、最適化できる場所を指定することに
よって、CPU 要求を削減することができます。
コード・プロファイルを実行するツールは、IBM Rational のツール、および他の会社が
提供するツールを利用できます。
アプリケーションの分析によって、ある種のトランザクションのために作業を削減できる場所を明らかにできる可能性があります。
リソースを増加するために、ファイル・ハンドルの数などのチューニング・パラメーターを変更します。
また、より高速な CPU の使用、アプリケーション・サーバーの追加など、ハードウェアの変更が必要になる場合もあります。
主なチューニング・パラメーターは、パフォーマンス上の問題の解決を容易にするため、
主な WebSphere Application Server コンポーネントごとに記載されています。
また、パフォーマンス・アドバイザーも、
実際のロードまたはシミュレーション上のロードにより、実動システムの調整に関するアドバイスを提供します。
ワークロードの分散は、一部のリソースが十分に利用されておらず、
その他のリソースが過負荷になっていると、パフォーマンスに影響を与えることがあります。
WebSphere Application Server ワークロード管理機能は、作業が分散される方法を決定するいくつかの方法を提供しています。
ワークロードの分散は、単一サーバー、および複数のサーバーとノードを持つ構成の両方に適用されます。
ワークロード管理を参照してください。
ワークロード管理を参照してください。
アプリケーションとサーバー・コードの一部のクリティカル・セクションでは、
複数のスレッドがこのコードを同時に実行して間違った結果を出さないように、同期が必要です。
同期によって正確さは保持されますが、1 つのスレッドがクリティカル・セクションを出るまで
幾つかのスレッドが待機しなければならなくなり、スループットが削減される場合もあります。
幾つかのスレッドがクリティカル・セクションに入るために待機している場合は、
同じプロシージャーで待機しているこれらのスレッドが、スレッド・ダンプに示されます。
同期の削減は、必要な場合にのみ同期を使用するようコードを変更したり、同期化済みコードのパス長さを削減したり、
同期化済みコードの呼び出し頻度を削減したりすることで行うことができます。