第3回：基礎データの取得方法では、基礎データの取得を行いました。基礎データの取得が完了したら、低負荷テストを行っていきます。
実施する意図についての詳細は、低負荷テストへ記載していますが、シナリオなどの各種設定が妥当なものになっているかを確認するためのテストになります。
段階的に負荷をかけるためのシェルの用意
低負荷テストでは、スレッド数「1」→「2」→「4」と低い負荷を段階的にかけていき、結果のスループットが、直線的にスケールしているかを確認します。
コマンドで手動実行してもいいですが、何度も同じことを繰り返すのは面倒なので、スレッド数を外部から指定可能なシェルを用意しておくと便利です。
参考までに、Windowsで実行する場合のバッチとLinux上で実行する場合のシェルを載せておきます。どちらも、「thread.csv」というスレッド数を記載したファイルを読み込み、行数分だけ連続実行するような内容になっています。また、外部から変数として、スレッド数、ランプアップ期間、ループ回数を指定するようにしているので、その部分は各シナリオに合わせて変更ください。
以下は、Windows用JMeter実行シェルです。
@echo off
rem Windows用JMeter実行バッチ
rem ベースディレクトリ
set DIR_BASE=シナリオや実行結果のベースディレクトリを記載
set DIR_JMETER=JMeterのインストールディレクトリを記載
set DIR_REPORT=%DIR_BASE%/report
rem ファイル名
set FILE_THREAD=thread.csv
set FILE_JMX=シナリオファイル名を記載
set FILE_JTL=結果ファイル名を記載
rem スレッド数分だけループ
for /f %%a in (%DIR_BASE%/%FILE_THREAD%) do (
%DIR_JMETER%\bin\jmeter -n -t %DIR_BASE%/%FILE_JMX% -l %DIR_REPORT%/%%a/%FILE_JTL% -e -o %DIR_REPORT%/%%a -Jthread=%%a -Jrampup=30 -Jloop=5
)
pauseこちらは、Linux用JMeter実行シェルとなります。
#!/bin/sh
## Linux用JMeter実行シェル
## ベースディレクトリ
DIR_BASE=シナリオや実行結果のベースディレクトリを記載
DIR_JMETER=JMeterのインストールディレクトリを記載
DIR_REPORT=%DIR_BASE%/report
# ファイル名
FILE_THREAD=thread.csv
FILE_JMX=シナリオファイル名を記載
FILE_JTL=結果ファイル名を記載
# 区切り文字
IFS=','
while read line
do
# コメントは削除
echo $line | grep -v '^#.*' > /dev/null
if [ $? -eq 0 ];then
# 区切り文字で分割($1,$2で取得可能)
set -- $line
${DIR_JMETER}/bin/jmeter -n -t ${DIR_BASE}/${FILE_JMX} -l ${DIR_REPORT}/$1/${FILE_JTL} -e -o ${DIR_REPORT}/$1 -Jthread=$1 -Jrampup=30 -Jloop=1
fi
done < ${FILE_THREAD}ベースディレクトリやファイル名は適宜置き換えてください。
低負荷テストを実施
今回は、「低負荷テスト」なのでthread.csvファイルに以下を記載して実行を行います。
1
2
4上記シェルを実行すると、結果が2種類の方法で出力されます。出力場所と概要は次の通りです。
| 出力結果 | 出力場所 | 概要 |
|---|---|---|
| csv | ${DIR_REPORT}/$1/${FILE_JTL} | GUIのリスナーへ読み込み可能なcsv形式です |
| HTMLレポート | ${DIR_REPORT}/$1/index.html | いい感じのHTMLレポートに仕上げてくれます |
※$1はスレッド数
※${DIR_REPORT}、${FILE_JTL}は上記のバッチで定義
結果を評価
結果をプロット
正常に実行が終了したら結果を表にまとめてプロットしていきます。まとめる結果は、各スレッドごとの「スループット」と「平均応答速度」です。結果の確認は「GUI」または「HTMLレポート」から行います。
GUIで確認する場合は、「統計レポート」へcsvファイルを取り込んで確認が可能です。その場合は、合計行の「Average」と「Throughput」を確認します。
統計レポートで結果を確認
HTMLレポートを見る場合は、StaticsのTotal行の「Average」と「Throughput」を確認します。
HTMLレポートで結果を確認
「t3.small」のインスタンスに対して実行した結果は次の通りでした。
| スレッド数 | スループット(tps) | 平均応答速度(ms) |
|---|---|---|
| 1 | 0.41 | 442 |
| 2 | 0.69 | 440 |
| 4 | 1.37 | 455 |
この結果を散布図でプロットすると次のようになりました。上記表の結果と理想スループットを追加してプロットしています。
結果をプロットする
結果の評価
プロットができたら結果の評価を行います。次のことから、今回の結果は正しいものと言えそうです。
スループットが直線的に上昇している
「スループット」が直線的に上昇しています。
スレッド数「１」の時のスループットにスレッド数を乗算したものを理想スループットという形でプロットしています。スループットは、負荷が低い状態では理想スループットに近い形で上昇していきます。
今回の例では、若干理想スループットを下回る状態になっていますが、ほぼ直線的に上昇しているので問題なさそうです。
平均応答速度が横ばいである
キャパシティに余裕があるうちは、平均応答速度は横ばいになり、余裕がなくなってくると急上昇していきます
今回の例では横ばいとなっているので、正しく負荷がかかっており、妥当なセットアップができているものと考えられます。
スケールしなかった場合の見直しポイント
もし、スループットが直線的にスケールしなかった場合の見直しポイントをみてみましょう。
問題がある結果の例
下の表は、Ramp-Up期間を「0」、タイマ設定を削除した状態の結果です。
タイマなしの結果
次のことから、何らかの問題がある状態と考えられます。
スループットが頭打ちになっている
グラフを見ると、理想スループットと実際のスループットの乖離が大きくなっています。また、スレッド数2から4の部分でスループットの上昇が緩やかになっており、頭打ちな状態に見えます。
平均応答速度が上昇している
スループットの低下とともに、平均応答速度も上昇しています。これは頭打ちをしている状態です。
見直しポイント
正常に結果がスケールがしなかった場合は、シナリオ含めた負荷テスト環境の見直しが必要となります。
主な見直しポイントは次の通りです。
- JMeterシナリオの、Ramp-Up期間が極端に小さくなっていないか
- JMeterシナリオの、タイマ設定が入っているか
- 負荷テスト環境のスペックが最小になっていないか
- 手動で実施した場合に正常に応答が返ってくるか
まとめ
この記事では、低負荷テストの実施方法について解説しました。低負荷テストは、シナリオなどの各種設定が妥当なものになっているかを確認するためのテストです。大きな負荷をかけるまえに実施することで、手戻りを防ぐことが可能です。
新たに負荷テストを実施する場合や、環境やシナリオを大きく変更した場合は、事前に低負荷テストの実施を行いましょう。
～～～～～～～～～～～～～～～～～～～～～
～ JMeterによる負荷テスト実施入門 ～
～～～～～～～～～～～～～～～～～～～～～
第1回：JMeterによる負荷テスト実施入門
第2回：CentOS環境へのJMeterインストールと実行コマンド
第3回：基礎データの取得方法
第4回：低負荷テストの実施方法
第5回：限界スループットの確認方法 ← 次の記事
第6回：チューニング実施と効果測定
第7回：マスタスレーブ構成を用いた負荷テストの行い方
参考サービス紹介：JMeterを使った負荷テストツール