里見大希
その他
JMeterRamp-Up定数スループットタイマ無限ループ負荷試験

【Jmeter】負荷試験 Ramp-Up期間 無限ループの設定意図

その他
この記事は約6分で読めます。

はじめに

株式会社implの里見です。

RDS for Postgresのアップデートを行い、JMeterを使用した性能試験を実施したため共有します。

※概要に入る前に設定意図まで飛ばしたい方はこちら

性能試験の概要

構成

EC2
  • 負荷試験用Jmeter環境構築インスタンス(windowsサーバ) ×2
  • web/APサーバ(apache tomcat) ×4
RDS
  • DBインスタンス×2(最新本番スナップショットからリストア)

試験内容

  • １分間でリクエスト数の多かったAPIに対し、作成したシナリオで約20分間リクエストを投げ続け目標レスポンスタイム以内で処理できるか
  • RDS for Postgres 11の時に実施した試験の結果と比較し、似たような計測結果になるか

Jmeterのインストール・起動

Jmeter公式サイトから最新版のzipファイルをダウンロードし展開。

bin/Jmeterファイルを開いて実行。

デフォルトでは言語が英語なので、bin/Jmeter.propertiesの中身を書き換える。

#language=en
language=ja

これで基本セットアップは完了したので、次にシナリオの作成に入る。

テストシナリオ作成

要件

(目標値)
  • 目標RPS : 120.0
  • 目標レスポンスタイム(90%line) : 3秒
(RDS for PostgreSQL11時の試験結果)
  • 実測RPS : 147.0
  • 実測レスポンスタイム : 33m/s

上記に基づき、RDS for PostgreSQL11の結果と大きくパフォーマンスが変わらないことを確認する。

シナリオ構成

下記の構成でシナリオを作成します。

テスト計画
　┗スレッドグループ
　┗HTTPリクエスト
　┗定数スループットタイマー
　┗統計レポート

スレッドグループ

  • 「追加 > Threads(Users) > スレッドグループ」を選択
  • 複数のテストを同時並行して負荷テストをしたい場合は、それぞれのシナリオごとにスレッドグループを作成する

○スレッド数 : 120
　JMeterが生成するスレッド数で、1スレッドが1ユーザに相当する　


○Ramp-Up期間 : 300秒(5分)
　全てのスレッドが起動するまでの時間　※テストの実行時間ではない
　　＝テストに必要なスレッド数を、設定した時間で整備する
　　※0を指定するとすべて同時に実行する


○ループ回数 : 無限
　1つのスレッドが1つのテストケースを何回実行するか
　※無限ループにすると自動でテストが終わらないため手動で停止する

HTTPリクエスト

  • スレッドグループの上で右クリック「追加 > サンプラー > HTTPリクエスト」を選択
  • 実際にテストでアクセスする先の情報を設定
  • ポート番号：プロトコルがhttpなら80、httpsなら443

定数スループットタイマ

○ターゲットスループット : 60.0req/m
　= 1秒1リクエストになるように設定

  • スレッドグループの上で右クリック「追加 > タイマ > Constatnt Throughput Timer」を選択
  • calculate throughput based on : this thread onlyを選択
  • ループが一気に実行されないように、各リクエストの送信の間に間隔を入れる

統計レポート

  • スレッドグループの上で右クリック「追加 > リスナー > 統計レポート」を選択
  • テスト結果に基づき、リクエストの応答時間、スループット、エラー率などが表示される

上記までで作成するシナリオについて紹介しました。
では、今回の趣旨である定数スループットタイマ・Ramp-Up期間の必要性について比較解説します。

定数スループットタイマ・Ramp-Up期間を設けない場合

  • Ramp-Up期間を設けないと、テスト開始と同時に120スレッドが一気に立ち上がる
  • 定数スループットタイマを設けないと、テスト開始と同時にテストを止めるまで休みなくリクエストが走り続け過度な負担がかかる

上記の理由から、正確な値を計測することができない。

定数スループットタイマ・Ramp-Up期間を設けた場合

  • Ramp-Up期間を設け、全てのスレッドが起動してから実際に計測できる状態を作る
  • Ramp-Up(300秒) / スレッド(120) = 2.5秒のため、2.5秒ずつずれてスレッドが起動する
  • 処理ごとに定数スループットタイマーを設け、処理時間を一定にする
    →60.0を設定したため、1分で60リクエスト＝1秒で１リクエスト処理する

つまり、実際に値を計測するタイミングは下記画像の水色で囲っている箇所になります。

まとめると下記の通りになります。

  • Ramp-Up期間
    →一気にスレッドを立ち上げるのではなく徐々に負荷をかけていき、計測可能な状態を準備する
    　ための期間。
  • 定数スループットタイマ
    →スレッドごとのループの間隔を制御し、等間隔なリクエストが無限ループする状態を作り出す
    　ためのタイマー。

テスト実行

前項を加味してテスト実施します。左上にある緑色の再生ボタンから実行していきましょう。

※JMeterを用いてAPIのテストや負荷テストを行う際は、DoS・DDoS攻撃とみなされないよう必ず自分や所属する組織が作成したWebサーバやAPIに対して事前に許可を取ってから実施しましょう。
また、いきなり大きい負荷をかけるのではなく小さい負荷から試験してください。

テスト結果確認

テストが終わり、実際に結果を確認します。

統計レポートの確認

名称説明
Labelサンプラーの名称
#Samplesサンプル数
Average平均応答時間(ms)
Median応答時間の中央値(ms)
90%Line90%信頼区間(少なくとも90%はこの値に収まる。単位(ms)
95%Line95%信頼区間(少なくとも95%はこの値に収まる。単位(ms)
99%Line99%信頼区間(少なくとも99%はこの値に収まる。単位(ms)
Min最小応答時間(ms)
Max最大応答時間(ms)
Error%エラーの割合(%)
Throughputスループット(1秒間に何件のリクエストに対し応答できたか)
Received1秒当たりの平均転送データ量(KB)
  • リクエスト頻度は計画値通りか
    → JMeterの統計レポートの「Throughput」やWEBサーバのアクセスログで確認
  • レスポンスステータスが200以外のものがないか
    → JMeter > 統計レポートの「Error%」が0である事、または結果ファイルのステータスコードが
    　200のみである事を確認
  • レスポンスタイムは許容時間内か
    → JMeterの結果を表で表示の「SampleTime」が想定時間内であることを確認

その他確認項目

  • サーバリソースに余裕はあったか（WEB・DBサーバのCPU・メモリなど）
    →RDS、EC2、ALB等のモニタリングから負荷が問題ないか確認

結果

前回の試験結果
  • 実測RPS : 147.0
  • レスポンスタイム : 33m/s
今回の試験結果
  • 実測RPS : 138.4
  • レスポンスタイム : 32m/s

上記のような結果となり、若干の性能向上が確認できました。

さいごに

Ramp-Up期間・定数スループットタイマの設定意図が伝わりましたでしょうか。

少しでも考え方の参考になれば幸いです。