ロード テストの実行
ロード テストのニーズに応じた構成オプションを作成、編集、設定した後で、Visual Studio Ultimate によって、ロード テストの実行用オプションが提供されます。
ヒント
ロード テストを実行する前に、ロード テストに含まれているすべての Web パフォーマンス テストと単体テストが、単独で実行された場合に成功するかどうかを確認することをお勧めします。 [テスト エクスプローラー] ウィンドウ、[テスト ビュー] ウィンドウ、または Web テスト エディターからテストを実行することにより、テストを検証できます。 データ バインディングのある Web パフォーマンス テストの場合は、すべてのデータ値を使用して実行します。
ロード テストの実行に関する考慮事項
ロード テストを実行する前に、ロード テストがテストの要件または目的に応じて適切に構成されていることを確認する必要があります。
適切なロード パターンを選択する |
テストの目的に応じたロード テストの各シナリオに対するロード パターンを選択します。
|
ロード テストの結果ストアの場所を選択する |
ロード テストの結果ストアに関する考慮事項 |
パフォーマンス カウンターのサンプリング間隔を適切に設定する |
パフォーマンス カウンターのサンプリング間隔に関する考慮事項 |
タイミングの詳細の指定とパーセンタイル データの収集を検討する |
タイミングの詳細の指定とパーセンタイル データの収集に関する考慮事項 |
SQL トレースの有効化を検討する |
SQL トレースの有効化の検討 |
追加のテスト エージェントが必要かどうかを判断する |
テスト エージェントをオーバーロードしない |
詳細については、「ロード テストに関する考慮事項」を参照してください。
グラフ モード
既定では、ロード テストの実行中は、ロード テスト アナライザーはグラフ ビューにあります。 グラフは次の 2 つのモードのいずれかで表示できます。
折りたたみモード 折りたたみは、ロード テストが実行されているときのロード テスト アナライザーの既定のグラフ モードです。 折りたたみグラフはロード テストの実行中に使用されます。このモードでは、テストの全実行時間のパフォーマンス カウンターの傾向が表示されますが、メモリに保持する必要があるデータの量は少なくて済みます。
スクロール モード スクロール グラフ モードは、ロード テストの実行中に結果を表示するときに使用できます。 スクロール グラフは、最近のデータ ポイントを示すオプションのビューです。 テストで最近 100 件のデータ間隔のみを表示するには、スクロール グラフを使用します。
注意
ズーム グラフ モードは、データベースを基に、完了したロード テスト結果を表示する場合にのみ使用できます。
グラフ モードの変更
ロード テスト中に折りたたみモードとスクロール モードを切り替えるには、ロード テスト アナライザーのツール バーにある [グラフのオプション] ドロップダウン リストを使用します。 折りたたみモードの場合は [実行全体のグラフ データ]、スクロール モードの場合は [最近のデータのみのグラフ表示] を選択します。
タスク
タスク |
関連するトピック |
|---|---|
ロード テストの実行設定の構成: 実行設定とは、ロード テストの実行方法に影響を与えるプロパティのセットです。 実行設定は、[プロパティ] ウィンドウでカテゴリ別に整理されています。 |
|
ロード テストの実行: さまざまなユーザー インターフェイス オプションを使用して、ロード テストを実行したり、コマンド ラインからロード テストを実行したりできます。 |
|
リモートでのロード テストの実行: テスト エージェントとテスト コントローラーを使用して、1 つ以上のリモート コンピューターでロード テストを実行できます。 |
|
テスト実行中のテスト結果のグラフィカルな表示: ロード テストの結果は、テストの実行中、およびテストの完了時に複数のペインのデータとして表示されます。 |
|
ロード テスト実行中のコメントの追加: ロード テストの実行中または完了後にロード テストを解析する場合、ロード テスト結果と共に、永続的に格納される説明付きのコメントと、任意の長さの解析コメントを追加できます。 |
|
すべてのコンピューターへのロード テストおよび Web パフォーマンス テストの配布: コンピューター グループを使用して、テスト用にシミュレートされた負荷を生成し、複数のコンピューターで同時にリモートでテストを実行できます。 |
|
Web パフォーマンス テストでの ASP.NET パフォーマンス データの収集: テストの設定の ASP.NET プロファイラー診断データ アダプターを使用して、ASP.NET Web アプリケーションの ASP.NET パフォーマンス データを収集します。 |
|
ロード テストのネットワーク エミュレーションのトラブルシューティング: ロード テストでネットワーク エミュレーションが正常に作動しているかどうかを確認できます。 |
|
チーム ビルドでのロード テストの実行: ビルドの完了後に実行されるように構成できるテスト カテゴリに、ロード テストを追加できます。 |
ロード パターンに関する考慮事項
テストの目的に応じたロード テストの各シナリオに対して、次のロード パターンのいずれかを選択します。
詳細については、「ロード パターンを編集して仮想ユーザー アクティビティをモデル化」を参照してください。
持続ロード パターンの使用
持続ロード パターンは、ロード テストの実行中に同じユーザー ロードを実行するために使用されます。 ユーザー数の多い持続ロード パターンを使用すると、ロード テストの開始時にサーバーに対して不適切で現実的ではない確認要求が行われる場合があるので、注意が必要です。 たとえば、ロード テストにホーム ページへの要求から始まる Web テストがあり、ロード テストの持続ロードを 1,000 ユーザーに設定すると、ロード テストでは最初の 1,000 の要求をできるだけ速くホーム ページに送信します。 これは、Web サイトへの実際のアクセスのシミュレーションとして現実的ではない場合があります。 これを軽減するには、徐々に 1,000 ユーザーまで増加するステップ ロード パターンの使用を検討するか、ロード テストの実行設定でウォームアップ期間を指定します。 ウォームアップ期間を指定すると、ロード テストではウォームアップ期間中に負荷が徐々に高くなっていきます。 詳細については、「シナリオの開始遅延の設定」を参照してください。
ステップ ロード パターンの使用
ステップ ロード パターンは、ロード テストの実行中にサーバーの負荷を上げるために使用できます。これにより、ユーザー ロードが増加するにつれてパフォーマンスがどのように変化するかを確認できます。 たとえば、ユーザー ロードが 2,000 ユーザーに増加したときにサーバーがどのように動作するかを確認するには、次に示すプロパティでステップ ロード パターンを使用して 10 時間のロード テストを実行します。
初期のユーザー カウント: 100
最大ユーザー カウント: 2000
ステップ実行間隔 (秒): 1800
ステップごとの傾斜増加時間 (秒): 20
ステップごとのユーザー カウント: 100
これらの設定では、100 人、200 人、300 人をはじめ、2,000 人までのユーザー ロードで、30 分 (1,800 秒) のロード テストを実行します。 これらのプロパティの中で "ステップごとの傾斜増加時間" プロパティは、新しいロード テスト ウィザードで使用できない唯一のプロパティです。 このプロパティでは、1 つのステップから次のステップ (たとえば、100 人から 200 人) へ突然増加するのではなく、徐々に増加させることができます。 この例では、ユーザー ロードは、20 秒にわたって 100 人から 200 人のユーザーに増加します。つまり、毎秒 5 人の増加です。 詳細については、「方法: ステップ ロード パターンの "ステップごとの傾斜増加時間" プロパティを指定する」を参照してください。
注意
Visual Studio Ultimate では、ロード テストをローカルで実行する場合、最大 250 の仮想ユーザーを使用できます。 ロード テストで必要な仮想ユーザーがこの数を超える場合、またはリモート コンピューターを使用する必要がある場合は、Visual Studio Load Test Virtual User Pack 2010 を購入する必要があります。 Visual Studio Ultimate を購入した場合は、Visual Studio Load Test Virtual User Pack 2010 を購入できます。 詳細については、「テスト コントローラーによるロード テスト用の仮想ユーザー ライセンスの管理」および「ロード テストのためのテスト コントローラーおよびテスト エージェントの構成」を参照してください。
ゴール志向ロード パターンの使用
ゴール志向ロード パターンは、リソース使用量があるレベルに達するまでにシステムでサポートできるユーザー数を決定する場合に便利です。 このオプションは、システムで制限されているリソース (つまり、ボトルネック) が既に特定されている場合に最適です。 たとえば、システムで制限されているリソースがデータベース サーバーの CPU であることがわかっており、データベース サーバーの CPU が約 75% ビジー状態になったときにサポートできるユーザー数を知りたい場合は、パフォーマンス カウンター "%Processor Time" の値を 70 ～ 80% に維持するゴール志向ロード パターンを使用できます。
ヒント
他の複数のリソースがシステムのスループットを制限している場合は、ゴール志向ロード パターンで指定されたゴールに達しない場合があります。また、ユーザー ロードは、[最大ユーザー カウント] に指定された値に達するまで増加し続けます。
このロード パターンでは、必要とする負荷が示されないことが多くあります。 したがって、ゴール志向ロード パターンでのパフォーマンス カウンターの選択には注意が必要です。また、[最大ユーザー カウント] の値をユーザー ロードの上限に設定するかどうかは慎重に決定してください。
ロード テストの結果ストアに関する考慮事項
Visual Studio Ultimate をインストールすると、ロード テストの結果ストアは、コンピューターにインストールされる SQL Express のインスタンスを使用するよう設定されます。SQL Express は、最大でディスク容量の 4 GB に使用が制限されています。 長期間にわたって多くのロード テストを実行する場合、使用可能であれば、ロード テストの結果ストアが完全な SQL Server 製品のインスタンスを使用するように構成することを考慮してください。 詳細については、「ロード テストの結果リポジトリ内のロード テストの結果の管理」を参照してください。
パフォーマンス カウンターのサンプリング間隔に関する考慮事項
ロード テストの長さに基づいて、ロード テストの実行設定の "サンプル速度" プロパティの値を選択します。 既定値 (5 秒) のようにサンプル速度が小さいと、ロード テスト結果のデータベースに必要な容量が増えます。 長いロード テストでは、サンプル速度を増加すると、収集するデータ量を減らすことができます。 詳細については、「方法: ロード テストの実行設定のサンプル速度を指定する」を参照してください。
以下は、サンプル速度のガイドラインです。
ロード テストの継続時間 |
推奨サンプル速度 |
|---|---|
< 1 時間 |
5 秒 |
1 ～ 8 時間 |
15 秒 |
8 ～ 24 時間 |
30 秒 |
> 24 時間 |
60 秒 |
タイミングの詳細の指定とパーセンタイル データの収集に関する考慮点
ロード テスト エディターの実行設定には、[タイミングの詳細ストレージ] という名前のプロパティがあります。 [タイミングの詳細ストレージ] プロパティを有効にすると、ロード テスト中に個々のテスト、トランザクション、およびページの実行にかかる時間が、ロード テストの結果リポジトリに格納されます。 これにより、90 パーセンタイル データや 95 パーセンタイル データが、ロード テスト アナライザーの [テスト]、[トランザクション]、および [ページ] の各テーブルに表示されます。
[タイミングの詳細ストレージ] プロパティを [StatisticsOnly] および [AllIndividualDetails] という実行設定プロパティで有効にするには、2 つの選択肢があります。 どちらのオプションの場合にも、すべてのテスト、ページ、およびトランザクションの時間が測定され、それぞれのタイミング データからパーセンタイル データが計算されます。 その違いは、[StatisticsOnly] オプションではパーセンタイル データが計算された直後に、個々のタイミング データがリポジトリから削除されます。 タイミング詳細を使用すると、結果リポジトリに必要な容量が減少しますが、 上級ユーザーは SQL ツールを使用して、他の方法でタイミング詳細データを処理することもできます。 この場合は、[AllIndividualDetails] オプションを使用して、その処理にタイミング詳細データを使用できるようにする必要があります。 さらに、このプロパティを [AllIndividualDetails] に設定した場合は、ロード テストの実行完了後にロード テスト アナライザーで仮想ユーザー アクティビティ チャートを使用して仮想ユーザーのアクティビティを分析できます。 詳細については、「ロード テスト アナライザーの詳細ビューでのロード テストの仮想ユーザー アクティビティの分析」を参照してください。
注意
旧バージョンの Visual Studio (Microsoft Visual Studio 2005、Visual Studio 2008 など) でも、[タイミングの詳細ストレージ] プロパティを [すべての個別詳細] 設定にすることはできました。 しかし、現在のバージョンと比較して、重要な相違点が 2 つあります。1 つは、[すべての個別詳細] 設定が既定の設定ではなかった点です。 もう 1 つは、[すべての個別詳細] 設定の構成はデータの収集後に行われていたため、この情報にアクセスするには、SQL クエリを使用するほかに方法がなかった点です。
ロード テストの結果リポジトリでタイミングの詳細データを格納するために必要なディスク容量が、長時間実行されるロード テストで特に大きくなります。 また、ロード テストの終わりにこのデータをロード テストの結果リポジトリに格納するのに時間がかかります。これは、ロード テストの実行が完了するまでデータがロード テスト エージェントに格納されるためです。 ロード テストが完了すると、データはリポジトリに格納されます。 [タイミングの詳細ストレージ] プロパティは、既定では有効になっています。 これがテスト環境で問題になる場合は、[タイミングの詳細ストレージ] を [なし] に設定します。
詳細については、「方法: ロード テストの実行設定の [タイミングの詳細ストレージ] プロパティを指定する」を参照してください。
SQL トレースの有効化の検討
SQL パフォーマンスの問題を診断するために、ロード テスト エディターの実行設定にある一連のプロパティを使用して、Microsoft SQL Server の SQL トレース機能をロード テストの期間中有効にできます。 SQL トレース機能を有効にすると、ロード テスト アナライザーのテーブル ビューで使用可能な [SQL トレース] テーブルに SQL トレース データを表示できます。
SQL トレースは使用方法が簡単で、ロード テストの実行中に SQL Profiler セッションを別途起動する代わりに利用できます。 この機能を有効にするには、ロード テストを実行しているユーザーが SQL トレースの実行に必要な SQL 特権を持ち、トレース ファイルが書き込まれるディレクトリを指定する必要があります。 通常、このディレクトリは共有です。 ロード テストが完了すると、トレース ファイル データはロード テストの結果リポジトリにインポートされ、実行されたロード テストに関連付けられるので、後でロード テスト アナライザーを使用していつでも表示できます。
詳細については、「SQL トレース データの収集によるロード テストでのパフォーマンスの監視と向上」を参照してください。
テスト エージェントをオーバーロードしない
テスト エージェント コンピューターによる CPU 使用率が 75% を超える場合、または使用可能な物理メモリが 10% を下回る場合は、ロード テストにエージェントを追加して、エージェント コンピューターがロード テストのボトルネックにならないようにしてください。
詳細については、「方法: ロード テスト シナリオで使用するテスト エージェントを指定する」および「テスト コントローラーおよびテスト エージェントを使用した複数のテスト コンピューターへのロード テストの分散」を参照してください。
関連するタスク
ロード テストと Web パフォーマンス テストの作成と編集
ロード テストや Web パフォーマンス テストを作成および編集する手順を紹介します。
ロード テストで Web パフォーマンス テストを実行する方法について説明します。
参照
概念
その他の技術情報
Consideration for Load Tests that Contain Web Performance Tests