JMeterのインストールからシナリオ作成、シナリオ実施まで一通りやってきました。JMeterシリーズはこちらです。

今回はこんな時はどうする？　という部分の追記になります。

これを発見するために性能試験を実施していますので、この状態が発生したら喜んでください！

但し、正しくテストを実施できていない可能性がありますので、次のポイントを確認しましょう。

エラーが発生したHTTPサンプラーのレスポンスの中身を確認してください。HTTPステータスコード500などで戻ってきている場合は、Webサーバ側のログを確認しましょう。原因が特定できると思います。

ここにはJMeterのスタックトレースが出力されていることがありますので、特にテスト対象のシステムがJavaで作られている場合は勘違いしやすいので注意が必要です。まぁ冷静に考えるとHTTPレスポンスでスタックトレースを返すわけがないので気が付きそうなものですが、テスト期間中で納期に追われていると案外見落とします。

もっとリクエストを捌けるはずだったのに、なぜか想定より早めにエラーが発生する。

長いシナリオの場合はスレッド数が多すぎると、スレッドが終了する前に次のスレッドが起動してしまい、テスト実施中盤にてリクエストの多重度が想定以上になることがあります。

この場合は、スレッド数を減らして均すか、シナリオに定数タイマーを追加してリクエストが集中しないよう調整するとよいでしょう。

これもあるあるですが、あまりにも高負荷設定でJMeterを実行すると一見その負荷でテストを実施した用に見えますが、サーバ側のアクセスログと突き合わせると想定密度でリクエストが来ていない、ということがあります。

この場合は、JMeterを実行しているパソコン側の性能不足の可能性があります。JMeter自体もJavaで作られており、限界があります。

このような時は、GUI実行が重いので、CUIで実行してみてください。

それでもまだ負荷が掛けきれていないという場合は、JMeterを実行するパソコンを増やすか、または専用パソコンを用意しましょう。

わざわざそのためだけにパソコンを購入するのももったいないので、GCP/AWS等なら専用の高スペックインスタンスを作ってそこから実行するとよいでしょう。

それでも足りない場合は、JMeter実行インスタンスをスケールアウトしましょう。

JMeterはJavaで作られているため、JMeter本体のVMメモリが不足するとフルGCが実行されてしまいます。

この状態になるとシナリオ実行が停止されてしまうため、想定していた負荷がかからなくなってしまいますので、これも注意が必要です。

長いシナリオを大量のスレッドで実行する場合などはVMのメモリ割り当てを増やすなどして、GCが実行されないようにします。

JMeterは設定を変更しないとJMeterのログを残します。

ちょっと油断すると、こんな感じで大きなログファイルが作成されてしまいますので注意が必要です。

GUIで動かすから特にログは記録しなくてよい、という場合は、ログの出力設定をOFFにすればログが出力されなくなります。

設定変更前に出力されたログは自動では消えませんので、手で削除してください。JMeterの本体が格納されている bin フォルダ内に jmeter.log という名前で作成されていると思います。

私もこれからも使っていきますので、なにかトラブルがあって解決した時は、ここに追記していこうと思います。

システム開発に性能テストは不可欠です。ほとんどのシステム開発現場で性能テストを実施しましたので、JMeterの使い方は習得しておいて損はありません。むしろ推奨します。

そして求められる性能が出せない場合は、チューニングしましょう。ここまでがワンセットです。