テスト実行・検証
実行
それでは、これまで設定した情報でテストを実行してみます。実行するには、メニューから［実行］→［開始］を選択します。実行を開始した後にリスナーを表示させると、情報を収集して表示し始めているのが分かります。実行が終わったら3つのリスナーをそれぞれ確認してみましょう。
グラフ表示リスナーからの検証
グラフは以下のようになりました。
色別に分かれていて、 「現在のレスポンス時間（黒）」、「平均のレスポンス時間（青）」、「標準偏差（赤）」、「現在のスループット（緑）」ということを意味します。ここで、レスポンス時間とスループットについて、そしてそれらのグラフをどのように解釈して対策をするかについて解説します。
スループットとは、単位時間あたりにシステムがどれほどのリクエストを処理しているかを数値化したものです。また、レスポンス時間とは、リクエストを受けてからレスポンスを返すまでの時間です。負荷を与えていくとそれらが一般的にどうなっていくかのおおまかなイメージを図にしました。
スループットは負荷を与えていくごとに数値が上がっていきます。これは、増加した負荷をそれだけ処理できていることを意味します。しかし、システムの処理能力には限界があるので、そのまま負荷を与え続けるといずれ限界に達します。これが図の限界線の部分です。限界線を超えてさらに負荷を与え続けると、そのままそれを維持するか（図の「1」）、下降をたどっていきます（図の「2」）。そのままスループットを維持することができれば理想ですが、多くのシステムの場合はスループットが下がっていきます。スループットがあまりに下がりすぎると、多くのユーザがアクセスがした際にシステムが止まってしまうということになりかねないので、注意が必要です。
また、レスポンス時間は、スループット限界線に達するまでは比較的低い数値を示しますが、その後大きく数値が上がっていきます。これは、スループット限界線に達するまでは、システム能力に見合った処理が行えているので、レスポンス時間が安定して速い数値を示しますが、スループット限界線を超えると、新たに増えた負荷に対して十分に処理できていないため、レスポンス時間が遅い数値を示していることを意味します。
では実際にボトルネックはどのようなプロセスで発見していけばいいでしょうか？ まず、スループットの限界に達する前にレスポンス時間が遅い場合には単一のリクエスト処理が遅いということが言えるので、1つのスレッドで実行してみて、特に重い処理を確認します。そして、その後にスループットの限界線をどうやって必要なところまで伸ばし、維持するかを考えていきます。ボトルネックは、アプリケーション、DB、ハードウェアなどどこに問題があるかさまざまですが、ログなどを確認し、仮説を立てて、検証していくことが大切です。
本稿のテストでは、環境的な問題もあり、あまり分かりやすいグラフは出力されませんでしたが、上の図と解説を参考に検証してみてください。
結果を表で表示リスナーからの分析
このリスナーでは、リクエストごとに行が分かれ非常に行が多いため、分かりやすく抜粋しました。ここではテスト直後、テストピーク時、テスト終了直前の3つのポイントで各リクエストの情報を表示しています。左から、リクエストの連番、HTTPリクエスト名、レスポンス時間（ミリ秒）、リクエストが成功したかどうか、レスポンスのバイト数です。これをみるとテスト直後とピーク時ではレスポンス時間に5倍近くの差があるのが分かります。ただ、ピーク時でも2秒もかかっていないことを考えると、今回の負荷程度であればユーザはそれほど不満なく使えるということが言えそうです。このように、表のリスナーを見ることにより、数値を用いた細かい分析を行えます。
5 STEP2-WRITE 350 true 163022 6 STEP2-WRITE 311 true 163286 7 STEP2-WRITE 340 true 163550 8 STEP2-WRITE 370 true 163814 9 STEP2-WRITE 501 true 164078 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 731 STEP2-WRITE 210 true 126062 732 STEP2-WRITE 1452 true 122366 733 STEP2-WRITE 1813 true 144542 734 STEP2-WRITE 1863 true 137150 735 STEP2-WRITE 1693 true 118670 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 1006 STEP2-WRITE 310 true 138998 1007 STEP2-WRITE 291 true 139262 1008 STEP2-WRITE 480 true 139526 1009 STEP2-WRITE 291 true 139790 1010 STEP2-WRITE 340 true 140054
アサーション結果リスナーからの分析
アサーション結果リスナーでは、アサーションの結果が表示されています。もし結果がエラーであれば、Testfailedといった文字列が表示されます。今回は全てのリクエストが正常に処理され、メモ一覧画面が表示されています。
補足
本稿のはじめの方で書いたように、負荷テストで正しいテスト結果を得るためには、正しい環境である必要があります。多くのリクエストを送信してテストする場合には、1台のPCではCPU、ネットワークの限界があり、正しいテスト結果を得るのは難しいでしょう。そこで、JMeterにはリモートテストと呼ばれる機能が存在します。これを使用することにより、複数の端末のJMeterをコントロールし負荷テストを行うことができます。詳細は、本稿では取り上げていませんので、Apache JMeter:Remote Testingを参照してください。
まとめ
昔、ブロードバンド回線がまだ流行っていない時代に「8秒ルール」という言葉がありました。これは、Webページを表示するのに8秒以上かかると表示されないだろうと思って他のページへ飛んでしまい、次に訪れてくれる可能性も非常に低いというルールです。しかし、今はブロードバンド回線も普及し、2、3秒でも耐えられないユーザも増えてきていることは間違いないでしょう。サービスをリリースする前からJMeterを使用し、どの位のユーザ数を超えると品質を維持できなくなるかを検証して対策をとることは、とても重要なことです。本稿がJMeterを用いた負荷テストの導入のお役に立てれば幸いです。
