ロード テストの作成と編集
ソリューションにロード テストを追加する Web パフォーマンス テストおよびロード テスト プロジェクトを作成できます。ロード テストには、単体テストと Web パフォーマンス テストの両方を含めることができます。ロード テストの主な目的は、多数のユーザーによるサーバーへの同時アクセスをシミュレートすることです。ロード テストにより、アプリケーションのストレスおよびパフォーマンスのデータを利用できるようになります。ロード テストは、ユーザーのロードやネットワークの種類など、さまざまなロード条件をエミュレートするように構成できます。新しいロード テストの作成には、新しいロード テスト ウィザードを使用します。このウィザードで、ロード テストの初期設定を指定します。初期設定には、シナリオ、カウンター セット、実行設定などがあります。
要件
- Visual Studio Ultimate
" "を参照してください。ビデオ: Visual Studio のロード テストのアプリケーション
タスク
タスク |
関連するトピック |
|---|---|
新しいロード テストの作成: Visual Studio Ultimate の新しいロード テスト ウィザードを使用して、アプリケーションのストレスおよびパフォーマンスをテストするためのロード テストを作成できます。 |
|
ロード テストが新しいロード テスト ウィザードを使用して作成された後既存のロード テストを編集する:、ロード テスト エディターを使用してさまざまな設定とプロパティを変更して構成できます。 |
|
コード化された UI テストでのロード テスト: パフォーマンス テストとして使用する、コード化された UI テストを含むロード テストを作成できます。コード化された UI テストでは UI 層でのパフォーマンスをキャプチャできるため、特定の状況では役立ちます。 |
|
ロード テストへの 64 ビット プロセスの指定: 64 ビット プロセスを使用する場合は、ロード テストで使用するテストの設定で指定できます。 |
関連タスク
実行設定とは、ロード テストの実行方法に影響を与えるプロパティのセットです。実行設定は、[プロパティ] ウィンドウでカテゴリ別に整理されています。
ロード テストの実行に関する考慮事項
Visual Studio Ultimateで大規模なロード テストを実行するには、次のヒントを検討する必要があります:
適切なロード パターンの選択
適切な接続モデルの選択
サンプル速度とデータ収集
待ち時間
Web パフォーマンス テスト要求に関する応答時間の目標の設定
タイミングの詳細の指定とパーセンタイル データの収集
[新しいユーザーのパーセンテージ] プロパティの設定
ASP.NET プロファイラーの有効化
仮想ユーザー ログの有効化
SQL トレースの有効化
適切な数のエージェント コンピューターの維持
適切なロード パターンの選択
ロード パターンには、持続、ステップ、およびゴール志向の 3 つの種類があります。個々のロード テストに適したロード パターンを選択するには、それぞれの種類の長所を理解しておく必要があります。詳細については、「ロード パターンを編集して仮想ユーザー アクティビティをモデル化」を参照してください。
定数 |
持続ロード パターンは、長時間にわたって同じユーザー ロードを使用してロード テストを実行する場合に便利です。持続ロード パターンを使用して高ユーザー ロードを指定する場合は、ロード テストのウォームアップ時間も指定することをお勧めします。ウォームアップ時間を指定することで、何百もの新しいユーザー セッションがサイトに同時にヒットするなどの過剰なストレスを防ぐことができます。 |
手順 |
ステップ ロード パターンはユーザー ロードを増加させながらシステムのパフォーマンスを監視できるため、最もよく使用される便利なロード パターンの 1 つです。ユーザー ロードを増加させながらシステムを監視することで、許容できる応答時間を確保できるユーザー数を調べることができます。逆に、パフォーマンスが許容できないレベルになるユーザー数を調べることができます。 各ステップが複数のユーザー (50 人以上のユーザーを追加する場合は、[Step Ramp Time] のプロパティをステップでユーザーの開始をずらすために使用することを検討してください。詳細については、「方法: ステップ ロード パターンの "ステップごとの傾斜増加時間" プロパティを指定する」を参照してください。 |
ゴール志向 |
ゴール志向ロード パターンでは、ユーザー ロードが時間の経過とともに増加しているステップ ロード パターンに似ています。ただし、パフォーマンス カウンターが特定のレベルに達したときにロードが増加するなるように指定することができます。たとえば、ゴール志向ロード パターンでは、負荷を増やし続け、ターゲット サーバーのいずれかが 75% ビジーになったら負荷を一定に保つことが可能です。 |
ニーズに合った定義済みのロード パターンがない場合は、カスタム ロード テスト プラグインを実装して、ロード テストの実行中にユーザー ロードを制御できます。詳細については、「ロード テストと Web パフォーマンス テストのカスタム プラグインの作成と使用」を参照してください。
適切な Web パフォーマンス テスト接続モデルの選択
ロード テストの実行設定は [Web Test Connection Model] のプロパティを使用して Web サーバーへのユーザーのつながりをシミュレートするためのさまざまなオプションがあります。モデル 3 種類の接続の種類があります: テスト イテレーション別接続プールと、つながりつながりごとにつながり。個々のロード テストに適した接続モデルを選択するには、それぞれの種類の長所を理解しておく必要があります。
ユーザー別接続 |
ユーザー別接続のモデルは、実際のブラウザーの動作を非常によくシミュレートします。Web パフォーマンス テストを実行している各仮想ユーザーは、各 Web サーバーへの接続を最大 6 つ使用します。仮想ユーザー専用の Web サーバーの接続は開いたままになります。1 番目の接続は、Web パフォーマンス テストで最初の要求が発行されたときに確立されます。追加のつながりは、ページに複数の依存要求が含まれている場合に使用されることがあります。これらの要求は追加のつながりを使用して並列に発行する場合があります。古いブラウザーでは Web サーバーごとに最大 2 つの接続を使用しますが、FireFox 3 と Internet Explorer 8 では Web サーバーごとに最大 6 つの接続を使用します。これらの同じ接続が、ロード テスト全体にわたって仮想ユーザーに再利用されます。 ユーザー モデルごとにつながりの短所はつながりの数が複数の Web サーバーが対象とするユーザー ロードの場合、または上位の 6 倍につながりと、この大量の計算をサポートするために必要なリソース単一のロード テストのエージェントから呼び出すことができるユーザー ロードが制限される可能性が高いコンピューターが存在する可能性があるエージェントで開くことです。 |
接続プール |
接続プール モデルは、複数の仮想 Web パフォーマンス テスト ユーザー間で Web サーバーへの接続を共有することによって、Load Test Agent のリソースを節約します。接続プール モデルでは、ロード テストのエージェントと Web サーバーとの間の接続数の上限が接続プール サイズで規定されます。ユーザー ロードが接続プール サイズよりも大きい場合は、複数の仮想ユーザーによって実行される Web パフォーマンス テストの間で接続が共有されます。これは、アプリケーション層に最も多くのロードを生成するために最適なモデルです。 つながりを共有すると、別の Web パフォーマンス テストがつながりを使用する場合は、1 回の Web パフォーマンス テストは要求を発行する前に待機する必要があります。ことを意味します。要求を送信する前に Web パフォーマンス テストが待機する平均時間は、ロード テストのパフォーマンス カウンターの Avg. Connection Wait Time によって追跡されます。この値は、ページの平均応答時間を下回る必要があります。そうでない場合は、接続プール サイズが小さすぎると考えられます。 |
テスト イテレーション別接続 |
テスト イテレーション別接続では、各テスト イテレーションの後に接続を閉じ、次のイテレーション時に新しい接続を開きます。 この設定では、ネットワークにログオンほとんどのストレスを設定します。これが必要ない場合は、前の 2 個のオプション 1 の使用をお勧めします。 |
サンプル速度とデータ収集
ロード テストの継続時間に基づいて適切なサンプル速度を選択してください。サンプル速度が小さい場合、たとえば 5 秒の場合には、サンプル速度が大きい場合より多くのデータを各パフォーマンス カウンターから収集できます。大量のデータを長時間にわたって収集すると、ディスク容量不足によるエラーになる可能性があります。時間がかかるロード テストでは、サンプル速度を大きくして、収集するデータ量を減らす必要があります。パフォーマンス カウンター数も収集されるデータ量に影響します。テスト対象のコンピューターでカウンターの数を減らすことで、収集するデータ量が減ります。
どのようなサンプル速度を特定のロード テストに最適かを確認するには、実験する必要があります。次の表は、始まるために使用できる推奨サンプル速度を示します。
ロード テストの継続時間 |
推奨サンプル速度 |
|---|---|
< 1 時間 |
5 秒 |
1 ～ 8 時間 |
15 秒 |
8 ～ 24 時間 |
30 秒 |
> 24 時間 |
60 秒 |
待ち時間
Web パフォーマンス テスト要求の待ち時間は、妥当な応答時間を確保できるユーザー数に大きな影響を及ぼします。2 秒から 10 秒までの待機時間を変更すると、通常はモデルと 5 倍そのユーザーを有効にします。ただし、目標が実際のユーザーをシミュレートする場合、ユーザーが Web サイトで行うように基づいて設定方法に要求する待ち時間を必要があります。待ち時間を長くし、ユーザー数を増やすことが、Web サーバーに対するストレスを増加させるとは限りません。Web サイトで認証を使用する場合は、使用する認証方法がパフォーマンスに影響します。
Web パフォーマンス テストの待ち時間を無効にする場合は、あたりの要求に関してより高いスループットがあるロード テストを生成できます。待ち時間を無効にする場合は、待ち時間が有効の場合よりユーザー数をかなり少なく設定する必要があります。たとえば、待ち時間を無効にして 1,000 ユーザーを実行すると、ターゲット サーバーまたはロード テストのエージェントが過負荷になる可能性があります。
詳細については、「待ち時間を編集してロード テスト シナリオにおける Web サイトでの対話操作の遅延をシミュレート」を参照してください。
Web パフォーマンス テスト要求に関する応答時間の目標の設定
Web テスト要求のプロパティの 1 つに、応答時間の目標があります。Web パフォーマンス テスト要求に応答時間の目標を定義しておくと、ロード テストで Web パフォーマンス テストを実行したときに、応答時間が目標に達しなかった Web パフォーマンス テストの割合がロード テスト アナライザーによって報告されます。既定では、Web 要求に応答時間の目標は定義されていません。
また、応答時間の目標の検証規則を使用すると、応答時間が目標に達しないページはロード テストでエラーになります。ログオン エラーを使用すると、ページの表示が遅くなったときに仮想ユーザーが何をしていたかを確認できます。
詳細については、「方法: Web パフォーマンス テストのページ応答時間の目標を設定する」を参照してください。
タイミングの詳細の指定とパーセンタイル データの収集および詳細ビューの有効化
実行設定には、[タイミングの詳細ストレージ] というプロパティがあります。このプロパティを有効にすると、ロード テスト中に個々のテスト、トランザクション、およびページの実行にかかる時間が、ロード テストの結果リポジトリに格納されます。これにより、ロード テスト アナライザーで仮想ユーザー アクティビティ チャートが有効になります。また、90 パーセンタイル、95 パーセンタイル、99 パーセンタイル、および標準偏差も、ロード テスト アナライザーの [テスト]、[トランザクション]、および [ページ] の各テーブルに表示されます。
既定では、"タイミングの詳細ストレージ" プロパティが有効になっているため、ロード テスト アナライザーのロード テスト結果の詳細ビューに仮想ユーザー アクティビティ チャートが表示されます。
大きなテストの場合は、"タイミングの詳細ストレージ" プロパティを無効にすることを検討してください。これには 2 つの重要な理由があります。
ロード テストの結果リポジトリでタイミングの詳細データを格納するために必要なディスク容量が、長時間実行されるロード テストでは特に大きくなります。
ロード テストの終わりにこのデータをロード テストの結果リポジトリに格納するのに時間がかかります。これは、ロード テストの実行が完了するまでデータがロード テストのエージェントに格納されるためです。
ロード テストの結果リポジトリに十分なディスク容量がある場合は、[タイミングの詳細ストレージ] を有効にして、パーセンタイル データを取得してかまいません。[タイミングの詳細ストレージ] を有効にするオプションには、[StatisticsOnly] と [AllIndividualDetails] の 2 つがあります。どちらのオプションで、すべてのテスト使用して、ページ、およびトランザクションの時間が測定され、パーセンタイル データは、個々のタイミング データから計算されます。[StatisticsOnly] を選択すると、パーセンタイル データの計算後に、個々のタイミング データは結果リポジトリから削除されます。データを削除することで、結果リポジトリに必要な容量が節約されます。ただし、SQL ツールを使用して、タイミングの詳細データを直接処理する場合、または仮想ユーザー アクティビティ チャートで仮想ユーザーの詳細の表示を有効にする場合は、[AllIndividualDetails] を選択して、タイミングの詳細データが結果リポジトリに保存されるようにします。
詳細については、「ロード テスト アナライザーの詳細ビューでのロード テストの仮想ユーザー アクティビティの分析」および「方法: 詳細情報を収集するようにロード テストを構成してテスト結果で仮想ユーザー アクティビティを有効にする」を参照してください。
[新しいユーザーのパーセンテージ] プロパティの設定
ロード テストの各シナリオには、[新しいユーザーのパーセンテージ] という名前のプロパティがあります。このプロパティは、Web ブラウザーによって実行されるキャッシュ処理をロード テスト ランタイム エンジンがシミュレートする方法に影響します。[新しいユーザーのパーセンテージ] の既定値は 0 です。これは、各仮想ユーザーが依存要求の仮想キャッシュを保持し、さらにテスト イテレーション間のクッキーの一覧を保持することを意味します。キャッシュはブラウザーのキャッシュのように動作します。したがって、URL への以降の要求は実行されません。これには、実際の Web ブラウザーに似ています。
[新しいユーザーのパーセンテージ] が 100% に設定されている場合は、各ユーザーが事実上 "ワンタイム ユーザー" になり、そのサイトに決して戻りません。この場合は、ロード テストで実行される Web パフォーマンス テストがイテレーションされるたびに、すべてのユーザーが Web サイトに初めてアクセスするかのように扱われることを意味します。つまり、ブラウザーのキャッシュに Web サイトへの以前のアクセスによるコンテンツがないユーザーとして扱われます。したがって、Web パフォーマンス テストのすべての要求がダウンロードされます。これは、イメージなどの依存要求が含まれています。
[!メモ]
キャッシュできる同一リソースが Web パフォーマンス テスト内で複数回要求される場合は例外です。
Web サイトのアプリケーション層に最も多くのロードを生成するために [0 percent new users] の既定値を使用します。この値は、に実際のユーザーに似ており、ほとんどのパフォーマンス上の問題が発生したアプリケーション層に、より多くのロードを生成します。詳細については、「方法: Web キャッシュ データを使用する仮想ユーザーの割合を指定する」を参照してください。
ASP.NET プロファイラーの有効化
ASP.NET のプロファイラー診断データ アダプターは、ロード テストの実行中にアプリケーション層から ASP.NET のプロファイラー データを収集することができます。プロファイラー ファイルが大きくなる可能性があるため、ロード テストの最大で 1 時間のかかるロード テストのプロファイラーなどを実行しないようにしてください (数百 MB)。代わりに、ASP.NET プロファイラーを使用して、実行時間の短いロード テストを実行してください。その場合でも、パフォーマンスの問題を詳細に診断することができます。
詳細については、「方法: Visual Studio でテストの設定を使用して、ロード テスト用の ASP.NET プロファイラーを構成する」を参照してください。
仮想ユーザー ログの有効化
失敗したテストのまたはテストを記録する頻度を指定して詳細なログを収集できます。ログは、"テストの失敗時にログを保存" プロパティ、"完了したテストのログ頻度を保存" プロパティ、および "テスト ログの最大数" プロパティによって制御されます。収集されるログの数は、"テスト ログの最大数" プロパティと "完了したテストのログ頻度を保存" プロパティの設定によって制御されます。既定では、多数のログが収集されないように設定されています。何百万の要求を生成する長期間のテストにログの数が大きくなりすぎないため [完了したテストのログ頻度を保存] 設定を使用しないでください。また、[テスト ログの最大数] のプロパティを適切な数値で置かせ続行します。コントロールこのプロパティを設定するエラーの種類別のログの最大数。したがって、この設定を維持する必要があります。これは数万のログを収集することを防止できます。多すぎるログを収集すると、テストの末尾に時間がログを収集するインクリメントし、ロード テスト データベースのストレージ領域を受け取ります。
詳細については、「ロード テストのログ設定の変更」を参照してください。
SQL トレースの有効化
実行設定には、[有効な SQL トレース] という名前のプロパティがあります。このプロパティを使用すると、ロード テストの継続時間中に Microsoft SQL Server のトレース機能を有効にできます。これは、SQL Profiler セッションを別途起動してロード テストの実行中に SQL のパフォーマンスの問題を診断する代わりになります。このプロパティが有効の場合、SQL トレース データはロード テスト アナライザーに表示されます。これは [SQL トレース] ページの [テーブル] ページに表示されます。
この機能を有効にするには、ロード テストを実行するユーザーに、SQL トレースの実行に必要な SQL 特権が必要です。テスト エージェントとテスト コントローラーを使用してロード テストをリモート コンピューターで実行している場合は、コントローラーのユーザーに SQL 特権が必要です。また、トレース データ ファイルが書き込まれるディレクトリを指定する必要があります。このディレクトリは、通常、ネットワーク共有です。ロード テストが完了すると、トレース データ ファイルはロード テストの結果リポジトリにインポートし、ロード テストに関連付けられます。トレース データ ファイルがロード テスト アナライザーを使用して後で表示できます。
詳細については、「ロード テストの実行設定の構成」および「SQL トレース データの収集によるロード テストでのパフォーマンスの監視と向上」を参照してください。
適切な数のエージェント コンピューターの維持
エージェント コンピューターによる CPU 使用率が 75% を超える場合、または使用可能な物理メモリが 10% を下回る場合は、過負荷になっています。テスト コントローラーにエージェントを追加して、エージェント コンピューターがロード テストのボトルネックにならないようにしてください。
詳細については、「テスト コントローラーおよびテスト エージェントを使用した複数のテスト コンピューターへのロード テストの実行の分散」および「方法: ロード テスト シナリオで使用するテスト エージェントを指定する」を参照してください。
外部リソース
.gif "Dd728098.collapse_all(ja-jp,VS.110).gif")
ビデオ
Visual Studio のロード テストのアプリケーション
参照
処理手順
チュートリアル: Web パフォーマンス テストを含むロード テストの作成と実行
チュートリアル: 単体テストを含むロード テストの作成と実行
概念
Visual Studio の Web パフォーマンス テストとロード テストを使用したパフォーマンスおよびストレスのテスト