Biz∫のWEBアプリケーションの負荷テストをしたい(2)

さて今日は、私自身もキチンと理解できていなかったスレッドグループの各種設定について検証します。
手始めに、

  1. 先頭ページを開く
  2. ログオンする
  3. ログオフする

といった簡単なシナリオを作成し、スレッド数3、Ramp-Up期間30、ループ回数1に設定してみます。(下の図)

結果以下のようになりました。
Ramp-Up期間とはスレッドを生成し終わる期間ととらえることができます。よって、下の図の結果のように、
Ramp-Up期間(30秒)/スレッド数(3)=10秒ごとにスレッドは生成されます。

今回のシナリオがとても単純で短時間で終了するため、図にすると以下のようになり、同時実行数は1となっています。

つぎに、ループ回数を増やしてみます。

下の結果となりました。ループ回数は、それぞれのスレッドが終わった後に、そのスレッドをもう一度繰り返すパラメータのようです。
1−2−3−1−2−3ではなく、1−1−2−2−3−3のようです。

今回も同時実行数は1となっています。

つぎに、Ramp-Up期間を弄ってみます。(30秒→3秒)

いままでは、10秒ごとにスレッド生成を行っていましたけれど、この変更で1秒ごとにスレッドが生成されるはずです。

思惑通りに1秒ごとにスレッドが生成されました。よって、同時実行数も2になる期間が発生しています。
このRamp-Up期間は0にすることも可能で、0にすれば、開始から同時実行数=スレッド数となります。


さて、最後に次のような負荷テストシナリオを考えてみます。

  • 最大同時アクセス数5
  • 開始時は同時アクセス数1から開始
  • 30秒ごとに同時アクセス数を増加

これを実現するためには、ループ回数のところを無限ループに指定してあげれば可能です。

負荷の増加イメージは以下のようになります。

下に、実行した様子をリスナーのグラフを利用して描画させた結果を示します。
同時実行アクセスをもっと大きく設定して実行すれば、スループットはだんだん稲穂の頭のようにお辞儀をするような感じになり、
どこかで頭打ちになるような曲線を描くと思います。

ただ、その原因は沢山の要素があるため、サーバ側や負荷をかけているクライアント側でも様々なリソース(CPU、メモリ、ネットワーク、DISK)をモニタリングする必要があります。