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