「負荷テストあれこれ-JMeterの使い方- 」で、JMeterの利用方法について触れましたが一番肝心のレポートの見方について書いてませんでしたので、今回はその点を。
今回の記事をまとめるにあたり、下記の資料を参考にさせていただきました。
負荷テストの方法やレポートの見方について触れる前にまず、何を目的で負荷テストをするかについて触れてみたいかと。
これも様々なケースが想定されますが、取り合えず
1. 現在のインフラ、システムの構成でどれだけの負荷に耐えられるかを知る為
2. 想定される同時ユーザー数に耐えられるか検証したい
3. インフラ、システム構成の変更によりどれだけのパフォーマンスが向上したか知りたい
の3つをケースを考えてみたいと思います。
負荷テストのやり方
まず前提となるテストシナリオを作る部分から。
これは、「ログイン→Aページ遷移→Bページ遷移→ログアウト」などのように最も多く利用が想定される処理について一連の流れをまとめておきます。
実際のユーザーの利用にはアイドル時間があるため、タイマなどを使って遷移の間に待ち時間を作らせるなど、実際の利用方法に近いシナリオを作っておく方がテスト結果にブレがなくなります。
想定するシナリオをJMeterに設定する方法は、前回の「負荷テストあれこれ-JMeterの使い方- 」を参考にしてください。
次に、JMeterの負荷レベルの設定ですが、スレッドグループのスレッドプロパティ内にある「スレッド数」、「Ramp-Up期間」「ループ回数」の3つ値によって負荷レベルが決まります。
1スレッドは1シナリオ（ログイン～ログアウトなど）に該当しますので、1スレッドが1リクエストにはなりません。
一つのシナリオで4つのページ（各ページは1リクエストで構成）を遷移する場合、1スレッドで発生するリクエスト数は4になります。
Ramp-Up期間はスレッド数をどの位の間隔で発生させるかを調整する値ですが、スレッド数とループ回数の関係によって大きく動作が異なってきます。
- Ramp-Up期間を60秒、スレッド数を5、ループ回数1と設定した場合
この場合、スレッドは12秒（60秒÷5スレッド）ごとに1スレッド生成してリクエストを送信します。
○ －12秒 → ○ －12秒 → ○ －12秒 → ○ －12秒 → ○ ・・・この時点で60秒
○ ： スレッド
※ このスレッドの中に複数のHTTPリクエスト（サンプラー）を含めていた場合、
スレッド数 × 1スレッドで実行されるHTTPリクエスト数
となります。（上記で1スレッド辺り2つのHTTPリクエストをセットしていた場合は、合計で10リクエストが送信される）
となります。
- Ramp-Up期間を60秒、スレッド数を5、ループ回数2と設定した場合
ループ回数は、1つのシナリオ（スレッド）を何回繰り返すかを設定します。
先ほどの条件に加えループ回数を2とした場合、12秒ごとに生成されるスレッドが2回（ループ回数分）実行されます。
○◎ －12秒 → ○◎ －12秒 → ○◎ －12秒 →○◎ －12秒 →○◎ ・・・この時点で60秒
○ ： オリジナルのスレッド
◎ ： ループによって実行されたスレッド
この部分が少しややこしいですが、スレッド数に指定した個数のスレッド（上記の場合は5個）が、「Ramp-Up期間 ÷ スレッド数」の時間（上記の場合は12秒）ごとに、指定されたループ回数（上記の場合は2回）だけ実行されます。
生成されるスレッド数は、あくまで「スレッド数」で指定した数になります。
下記は、Jmeterのリスナーの1つである「結果を表で表示」でスレッドの様子を見た結果です。
12秒ごとにスレッドがループしていることがわかります。
1連のシナリオが終了してから、再度そのシナリオを繰り返す（ループさせる）というイメージでは無い点に注意が必要です。
私も初めは
○ －12秒 → ○ －12秒 → ○ －12秒 → ○ －12秒 → ○ ・・・ 1回目のシナリオ終了
→ 12秒 → ◎ －12秒 → ◎ －12秒 → ◎ －12秒 → ◎ －12秒 → ◎ ・・・2回目のシナリオ終了
○ ： オリジナルのスレッド
◎ ： ループによって実行されたスレッド
という動きを考えていたのですが、そうではありませんでした。
あくまでRamp-Up期間内でスレッドの生成を完了されます。
また、Ramp-Up期間とはスレッドの生成を完了させる期間で、負荷テストが完了させる時間ではありません。
全てのスレッドが即座に処理されるのであれば、Ramp-Up期間で負荷テストが完了しますが、高負荷をかけた場合は、クライアント側の処理待ちやサーバー側の処理街の為、Ramp-Up期間よりずっと長い時間がかかります。
- Ramp-Up期間を60秒、スレッド数を2、ループ回数5と設定した場合
では、スレッド数とループ回数を逆にした場合はどうなるでしょうか。
最終的に実行されるスレッドの回数はどちらも同じ10（5スレッド×2ループ又は2スレッド×5ループ）になります。
が、挙動が大きく異なってきます。
まずスレッド数が2である為、30秒に1スレッドが生成されます。
次にループ回数の影響により、1スレッドの生成を5回ループさせる言う動きになります。
つまり・・・
○◎◎◎◎ － 30秒 → ○◎◎◎◎
○ ： オリジナルのスレッド
◎ ： ループによって実行されたスレッド
となるわけです。
この2つは大きく違いますよね。
この点に注意が必要になります。
同時接続ユーザーがどの位の数まで耐えられるかという検証を行う場合（同時を1秒あたりのユーザー数と定義しますが）、じゃあRamp-Up期間を1秒にセットし、スレッド数を5、ループ
回数を1にセットすれば確かに同時5ユーザーのテストにはなります。
しかし、システム側は何も負荷がかかっていない状態で5同時接続ある場合と、5同時接続が常にあり、それなりに負荷がかかっている状態で、さらなるアクセスがあった場合とで処理能力は全然異なります。
（下図はJMeterのグラフ表示リスナー）
本当の意味で負荷テストをするのであれば、後者のやり方が正しいものになります。
ですので、Ramp-Up期間をそれなりに長い期間をセットし、後はスレッド数とループ回数で1秒当たりにどれだけの同時アクセスを行わせるかの調整を行えばよいと思います。
先に書いたように、リクエストを引っ切り無しに送り続けるテストは現実的ではありませんので実際のクライアントの想定操作の元で、シナリオを作成し実行してみる事が重要になります。
- 負荷テストのやり方 ： 1. の場合
まず想定件数も分からない場合は、地道に負荷のレベルを上げてテストを繰り返し、限界値を調査する手法をとるしかありません。
これは、ツールは違うにしろ「負荷テストあれこれ-Microsoft Web Application Stress Tool-」 で書いた方法と同じです。
Ramp-Up期間は固定にして、スレッド数とループ回数で1秒あたりの同時アクセス数を調整します。
1秒当たりに１アクセス、2アクセス、3アクセスと段々と数を増やして行きます。
このときに、リスナーの「統計レポート」を追加しておいて、その内容からスループットの合計値が順調に上がっていっているかを調べてみます。
同時アクセス数を増やしていき、スループットが変わらないもしくは下がったと言うところがその構成においての同時接続数の限界値となります。
- 負荷テストのやり方 ： 2. の場合
同時接続ユーザー数の想定値があるのであれば、その想定値と同じ負荷をJMeterに設定してみてその時のレスポンス時間を見てみればよいです。
例えば8秒ルールに従うというのであれば、その想定している同時接続ユーザーのアクセスと同様の負荷レベルでそれ以内のレスポンス時間かどうかを見比べます。
レスポンス時間を見たいのであれば、「統計レポート」が参考になると思います。
「Median」（中央値）の値を見てみて、どの位の応答時間（単位はミリ秒）なのかを把握します。
想定している応答時間以内であれば、負荷テストは成功となりますがそれ以上である場合はシステムの構成に手を加える必要が出てくるでしょう。
- 負荷テストのやり方 ： 3. の場合
システムの改善によりどれだけのパフォーマンス（応答時間）が改善されたかを調べるには、改善前に負荷テストをしておき、それと同レベルの負荷を改善後のシステムにかけ、結果を見比べる事で判断できます。
ただ、あちこちに改善を加えるてから負荷テストをするより、加えた改善を一つずつ検証してみてどこがボトルネックとなっていたかをしっかりと把握しておく事が重要になるはずです。
あちこちに改善を加える事で、新たな問題がシステムに起こる場合もありますし、システムの構成は単一的でないでしょうから、Webサーバーに原因があるのか、DBサーバーが原因なのか、その他にネットワークやその関連機器に問題があるのかを把握しなければ負荷テストに要する時間も大きくなってしまうでしょうから。
ネットワークに問題がある場合は、プログラムを変更したところで改善できませんからね。
※ 負荷テストのやり方については、下記の記事も参考にしてみてください。
Apache Bench、WAST、JMeterを使った負荷テストのポイント
JMeter各レポートの見方
JMeterで出力される各種レポートの中で、特に参考になるのは「グラフ表示」「統計レポート」、「結果をツリーで表示」の3つのリスナーです。
- 結果をツリーで表示
実行したスレッドが順番に表示されます。
赤字のスレッド名は何らかのエラーが発生している事を示しています。
スレッド（フォルダ）をクリックすれば、そのスレッド内で設定しているHTTPリクエストの詳細や実際の画面（HTMLタグ）を見ることも出来ますので、作成したシナリオが正常かどうか確認するときに役立ちます。
- 統計レポート
各スレッドの応答時間やスループットが確認できます。
Errorから各スレッドのエラー発生率も表示されますので、「結果をツリーで表示」リスナーと併せて確認して、問題を解決します。
応答時間の単位はミリ秒です。
ここから、想定している応答時間内か確認すればよいでしょう。
スループットの単位はHTTPリクエスト単位になります。
単位は結果によって変わってきますが、これによりそのスレッドが単位あたり幾つのHTTPリクエストを処理できるかのパフォーマンスが確認できます。
- グラフ表示
統計レポートの各数値をグラフに表したものです。
サーバーの限界値を把握するには、このグラフからの方が理解しやすいと思います。
JMeterを使った負荷テストに関しては、下記のページも参考になるかと思います。
2009.03.09 追記
記事の内容（実行されるスレッド数の表現）に誤りがあったため、一部記事を訂正しました。
2009.03.23 追記
記事の内容の誤り部分を見やすいように訂正しました。
また、生成されるスレッドの様子をわかりやすくするために図を追加しました。
関連記事
Apache Bench、WAST、JMeterを使った負荷テストのポイント
サーバー管理で知っておきたいコマンドあれこれ。 - sysstat編 -
サーバー管理で知っておきたいコマンドあれこれ。 - apachetop編 -