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