システム開発を行っていると、その工程の中で負荷（パフォーマンス）テストという項目が出てきます。
かなり軽微でしかも使用者数が限定的であるならばそれほど気にするものでもありませんが規模が大きくなってくれば来るほど、この項目の重要性は増してきます。
負荷テスト自体には、Webサーバーへの負荷をかけるものや、DBへのクエリのレスポンスを見るもの、サーバーのディスクI/OやCPUの状況を見るものなど様々です。
負荷をかけてみた。何か重い。
それだけ分かったところで何処を改善すればよいのか目星がつかなければ意味がありません。
ただ、構築したアプリやサーバー自体がどれだけの負荷に耐えられるのかと言うものを知っておく事は運用の中で重要です。
サーバーの限界値を知っていれば、日々のアクセス数などと照らし合わせて事前に対処する事が可能になります。
限界値に近づいてきたからスケールアウトするかとか、サービスレベルを定義する指標にしてみたり。
負荷テスト用のツールは、数多くありますが多くは商用版でライセンス料も高価です。
「Microsoft Web Application Stress Tool 」は、フリーの負荷ツールで一通りの負荷に必要な機能が備わっています。
利用方法も簡単ですので、まずは全体のパフォーマンスの限界を知りたいと言う場合にはお勧めです。
セットアップ方法、利用法は下記のサイトに詳しく書かれています。
Web Application Stress Toolを使い倒そう！
※ ダウンロードページにあるMS Web Application Stress Toolへのリンクは、古いのでこちら
から。
Web Application Stress Toolの利用時の注意点
・ ダウンロードのページに書かれているように、2000年2月4日以降更新されていないようです。
ですので、今後バグなどの対応は行われないものと思われます。
・ このツールは、サーバーにかなりの負荷をかける事が可能です。
テストの対象は、自分の管理しているサーバーのみとし、またネットワークやサーバーの管理者と話し合った上で
実行した方が良いでしょう。
・ MS Web Application Stress Toolの利用時には、Microsoftの利用規約に従ってください。
Web Application Stress Toolで出来る事／出来ない事
・ Web Applicationという言葉がついている通り、Webアプリ専用です。
その他のテストには利用できません。
例えば、DBへの負荷テストなどを行う事は出来ません。WebアプリでDBへアクセスする簡易的なプログラムを書いて
おいても良いですが、Webアプリ経由になる為DB自体の正確な負荷を測る事はできません。
・ 上記に付随する事ですが、全体的なパフォーマンスを測る為のものです。
負荷の原因を調べるには別の手段が必要でしょう。
・ SSL通信下でのテストは出来ません。
・ 簡易的なシナリオテストしか出来ません。
例えば、ログインは1度のみとして、その後にあるページを複数回アクセスすると言った実際のユーザーの利用の
軌跡をシナリオとしてテストする事は出来ません。
ログインし、あるページを遷移していく事を一連の流れとして最初から（ログインから）繰り返すと言う事は出来ます。
・ 負荷テストのシナリオを登録する事は簡単に出来ますが、そのシナリオの中から余計なものを除外するのが結構
面倒です。
MS Web Application Stress Toolでシナリオを登録するのは、ツールから起動されるブラウザでアクセスしたページを
ツールが自動的に記録してくれます。
ツールは、そのブラウザがリクエストしたパスの情報を記録しており、そこにはJavaScriptファイルやCSSファイルも
含まれます。
しかし、多くの場合でそれらのリクエストを負荷テストに含める事はあまり意味がありませんので除外したいと考え
ますが、それらを除外するにはそれらのパスを全て取り除いて上げる必要があります。
（正規表現とかで予め設定したパスを負荷テストに含めないとかは出来ない）
・ 複数の端末を利用した負荷テストは出来ません。
負荷テストは、実施するクライアント側の端末の影響も大きいです。
負荷テスト実施側の端末に何か余計なアプリが入っていて起動していると、負荷をかけるリソースがそちらに取ら
れる為、想定していた負荷を実際にかける事が出来ていない場合があります。
こういったときの対策のために、複数台の負荷テスト用の端末を用意して、それらから一斉に負荷をかけそれらの
結果を集計すると言う事が望ましいのですが、そこまで高度な機能は用意されていません。
・ レポートのCSV形式での出力
負荷テストの結果をレポートにてまとめて出力されますが、それをCSV形式で出力する事も可能です。
出力したいレポートを画面に表示させてメニューの「File」→「Export Report」
ただ、単体でのレポートしか出力できませんので複数出力したい場合は、個々に上記の処理を繰り返して行く必要が
あります。
また、グラフ化したい場合はExcelなどを利用して出力したCSVを加工する必要があります。
Web Application Stress Toolの負荷のかけ方
一連のシナリオのレコードが完了すると、そのシナリオでどれ位の負荷をかけるかを設定します。
設定は、「Settings」のメニューの「Concurrent Connections」の項目にある「Stress level」と「Stress multiplier」で調整します。
この2つの項目の数値の掛算の結果が負荷のレベルになります。
「Stress level」を10、「Stress multiplier」を1にした負荷レベルと、「Stress level」を1、「Stress multiplier」を10にした結果はイコールになるようです。
「Stress level」が記録した一連のリクエストを同時にどのくらい実行するかを表し、「Stress multiplier」でそれをどのくらい並行して実行するかを表しています。
「Stress level」（スレッド数）が1の場合、Webサーバーに対するリクエストが1になるわけではありません。
記録したシナリオが10リクエストあり、それを10スレッド（Stress level）を5並行（Stress multiplier）して実行した場合10×10×5のリクエストがWebサーバーに飛んでいきます。
これを1つの処理として、どれ位の時間負荷をかけ続けるのかを、「Test Run Time」のセットしておきます。
ですので、正確に指定の時間でどれ位のリクエストがWebサーバーに飛んでいくかは結果を見ないと分かりません。
実行する時間（Test Run Time）によって結果もかなり大きく変わってくる場合があります。
これは、負荷をかける端末の状態や、ネットワーク、Webサーバー側のその時のその他の要因による負荷などが原因になるからです。
ですので、ある程度長い時間負荷をかけ続けた方が結果は安定してきます。
また、負荷をかける端末の性能にも左右されますので、実行しようとしている負荷がそのクライアント端末で
実現可能なレベルかどうかを確認しておく必要があります。
Web Application Stress Toolのレポートの読み方
一番大事なところ。
どんな構成のシステムでも負荷に対しての限界値というのは必ずあります。
大事なのは、その限界値をまずは知っておく事です。
Stress Toolのレポートを読むことである程度、そのシステムの限界と言うものが分かります。
その幾つか読む上で重要になる項目を解説します。
□ Overview
負荷テストの結果の概要を表示しています。
[ Number of hits ]
負荷テスト期間中にツールが受け取ったリクエストの結果数です。
Webサーバーに投げたリクエスト数と厳密にはイコールになりません。
（テスト時間が過ぎるとそこで打ち切られる為）
[ Request per Second ]
1秒間にいくつのリクエストを処理したかを表します。
□ Socket Statistics
通信状況を表示しています。総計でどれ位のデータ量を転送したのか、受け取ったのかなどです。
[ Socket Connects ]
Webサーバーに送ったリクエスト数の合計です。
この数はWebサーバーに記録されるアクセスログの数とイコールになります。
□ Result Codes
Webサーバーに送信したリクエストに対するステータスコードの一覧です。
「200」だと正確な結果を返してきた事になりますが、「404」だとリクエストの対象が存在しなかった事になります。
この結果を見て、テストのシナリオに問題ないかが判断できます。
□ Page Summary
各リクエストの詳細な結果です。
「Hits」がWebサーバーが応答して結果を受け取った数、「TTFB Avg」がレスポンスタイム（リクエストを出してから最初の結果を受け取るまでの時間）の平均値、「TTLB Avg」がターンアラウンドタイム（リクエストを出してから、全ての実行結果を受け取るまでの時間）の平均値です。
単位はどちらもミリ秒となります。
レポートを読むに当たっては、幾つか負荷レベルの異なるテスト結果を比べる必要があります。
同時スレッド10の結果、20の結果、50の結果を比べていく事でシステムの限界が分かります。
「Request per Second」は1秒辺りのリクエストの処理数を表すと書きましたが、スレッド数によってこの値が異なってきます。
その値がもっとも高くなった時のスレッド数がそのシステムの限界値になります。
一般的には、スレッド数を増やしていくと「Request per Second」も上昇し、あるところで緩やかに下降してそれ以降は、ほとんど変わらなくなります。
スレッドはテストシナリオの一連のリクエストをまとめたものと先に書きました。
ですので、このスレッド数の限界値がシステムの同時接続ユーザー数の限界値にもなります。
（もちろんテストシナリオ上ではと言う事ですが）
次に「TTLB Avg」を見ると、そのリクエストが完全に処理されるまでの時間が分かります。
テストシナリオによっては、画像のリクエストを除外していたり、リクエストがブラウザで処理される時間などがありますので、ユーザーが完全にそのシステムを利用できる状況になるまでの時間とはなりませんが、近い値として参考には出来ます。
8秒ルールに順ずるなら、8000ミリ秒以下になるスレッド数を把握しておけば、その限界値が分かります。
説明してきたように「Microsoft Web Application Stress Tool」負荷の全体像を把握する為だけのものです。
が、まずはそのシステムがどれ位の負荷に耐えれるかを把握する事や、何か負荷軽減の対策をした際にどれ位の効果があったのかなどの比較に使えるツールなのではと思います。