Out Of My Memory

雨垂れ石を穿つ

【Jmeter】負荷量を調整する方法

要約

この記事ではJmeterで負荷量を調整する方法2つを説明している

1.Think Timeで負荷量を調整する
2.定数スループットタイマーで負荷量を調整する

  • Think Timeで負荷量を調整した場合、何らかの理由ででサーバ側のレスポンスタイムが落ちた場合、目標スループットは出せなくなる。
  • 定数スループットタイマーで負荷量を調節した場合、何らかの理由でサーバ側のレスポンスタイムが落ちた場合でも目標スループットが達成できる時がある。

使用資材・環境など

Jmeterから同じ端末内のApacheへアクセスして静的コンテンツを取得するだけのシナリオを使用する。
また、目標スループットは10TPSとする。

f:id:pzdl-HIRAKU:20191222134701p:plain
負荷掛け環境イメージ

Apacheへアクセスすると It works! と表示されるhtmlが返却されるだけ。

f:id:pzdl-HIRAKU:20191222135808p:plain

負荷シナリオの共通設定

  • 使用するシナリオはスレッドグループの中に1つのHTTPサンプラーがあるだけ。
  • スレッドグループの設定は同じで以下の通り
    • スレッド数:20
    • RampUp:0秒
    • ループ回数:無限
    • 「Specify Thread lifetime」にチェックを入れ「Duration」を60秒に設定する。

下記シナリオに「Think Time」または「定数スループットタイマー」を入れ負荷量を調節する。

f:id:pzdl-HIRAKU:20191222140242p:plain
使用する負荷シナリオ

そのまま負荷掛けしてみる

「Think Time」も「定数スループットタイマー」も入れずにそのまま負荷掛けしてみる。
スタートした後、約5秒でsocket枯渇によるエラーが発生した。

f:id:pzdl-HIRAKU:20191222142045p:plain
socket枯渇によるエラー

●参考

unageanu.hatenablog.com

Jmeterはリクエストに対するレスポンスを受け取るとすぐに次のリクエストを送信するため、レスポンスタイムがとても速いとsocketの作成がsocketの上限値に達してしまい、socket枯渇のエラーが出てしまう。

●テスト結果

Jmeterはレスポンスを受け取るとすぐに次のリクエストを送信するため、Think Time等を設定してリクエスト間隔を調整しないと、socket枯渇のエラーにかかわらずとても多くの負荷を生成してしまう。

f:id:pzdl-HIRAKU:20191222151812p:plain
何も設定せずに行った負荷掛けの結果

Think Timeで負荷量を調整してみる

静的コンテンツを返却するだけなのでレスポンスタイムは100ミリ秒もかかっていない。また、スレッド数は20なのでThink Timeを1秒程度では目標スループットに対して過負荷になってしまうため1.9秒としてみる。

「Think Time」 という名前で「Flow Control Action」というサンプラーを追加している。

f:id:pzdl-HIRAKU:20191222152808p:plain
Think Timeを追加したシナリオ

負荷をかけてみると大体10TPSにはなっている。

f:id:pzdl-HIRAKU:20191222152954p:plain
負荷試験結果(Think Time追加ver)

Think Timeで調節をする場合はスレッド数やレスポンスタイムからどれくらいThink Time を入れる必要があるか計算して調節する必要がある。
今回はとても簡単な負荷シナリオなので計算も簡単だったが、負荷シナリオが長く、レスポンスタイムにもばらつきがある場合は負荷をかけて結果を見ての繰り返しでThink Timeを調節する必要がある。

定数スループットタイマーで調整してみる

<定数スループットタイマーについて>
設定したスループットTPM)になるように送ったリクエストの結果に応じて次のリクエストの送信を遅らせ、目標TPSになるようにリクエスト間隔をよしなに調整してくれるタイマー。

スレッドグループの下に定数スループットタイマーを入れ、TPM(Transaction Per Minutes)に600を入力。TPS(Transaction Per Second)ではなくTPMなので注意。
また、Calculate Throughtput based on: を「all active threads in current thread group (shared) 」にする。ここの設定をミスると全く狙ったスループット通りにならないので注意すること。

f:id:pzdl-HIRAKU:20191222153750p:plain
負荷シナリオ(定数スループットタイマーver)

今回はとても単純な負荷シナリオのため、10TPSちょうどとなった。
定数スループットタイマーは正確に狙ったスループットになるわけではないが、そうなるようにリクエスト間隔を調節してくれるので、大体近しいTPSになる。

f:id:pzdl-HIRAKU:20191222154940p:plain
負荷試験結果(定数スループットタイマー追加ver)

まとめ

  • Think Time
    • 負荷量調整が面倒くさい。
    • サーバのレスポンスタイムに関係なくThink Timeで設定した秒数待機してから次のリクエストを送信する。そのためサーバ側のレスポンスタイムが遅れた場合、目標とするスループットが達成できなくなる。
    • サーバ側のレスポンスが遅れた場合、目標TPSを達成しないためJmeterとサーバのどこかで何らかのボトルネックがあることがすぐにわかる。
  • 定数スループットタイマー
    • 負荷量調整が簡単
    • レスポンスタイムに応じてリクエスト間隔を調節してくれるため、サーバ側のレスポンスタイムが遅れた場合でも目標とするスループットを達成できる場合がある。
    • 言い換えると、目標TPSを達成するために負荷量を増やしたりしていないか注意する必要がある。