第4回：低負荷テストの実施方法では、低い負荷をかけてセットアップの確認を行いました。これが正常に完了したら、いよいよ負荷テストを行っていきます。
想定の負荷がある場合は想定の負荷をかけていきましょう。限界スループットの確認をする場合は、スループットが劣化するまで負荷を上げていきます。JMeterの実行結果だけでなく、システム側のメトリクスやログなども取得しておくことが重要になります
この記事では、AWSの「t3.small」インスタンスで動作させているEC-CUBEに対して、第1回：【負荷テスト】JMeterのシナリオ作成入門で作成したシナリオを使い、限界スループットの確認をしていきます。
負荷テスト実施
第4回：低負荷テストの実施方法と同じ要領で、スレッド数を増やしていきます。各スレッド数で出力された「スループット」および「平均応答速度」をプロットしていきます。下の表のように「スループット」が頭打ちになるまで繰り返していきます。
実際の負荷テストを行った場合のスループット推移
※グラフの見方が不明なかたは、限界スループットの確認方法をご覧ください
負荷テストの結果確認
実際に実施してみた結果、次のようになりました。
| スレッド数 | スループット(tps) | 理想スループット | 平均応答速度(s) |
|---|---|---|---|
| 1 | 0.41 | 0.41 | 442 |
| 2 | 0.69 | 0.82 | 440 |
| 4 | 1.37 | 1.64 | 455 |
| 8 | 2.82 | 3.28 | 390 |
| 16 | 5.46 | 6.56 | 501 |
| 24 | 7.44 | 9.84 | 934 |
| 32 | 8.45 | 13.12 | 1683 |
| 48 | 9.48 | 19.68 | 3362 |
理想スループットは、スレッド数「1」のスループットに対して、各スレッド数を乗じた値です。性能が頭打ちするまでは実際のスループットとの乖離が少なく推移します。
上の表を散布図にしてみたのが下のグラフとなります。
限界スループットの確認結果
スレッド数「16」まではスループットが直線的に上昇し、理想スループットと乖離が少ない状態です。「16」を超えてくると上昇が緩やかになり、理想スループットからの乖離が大きくなってきます。また、平均応答速度も悪化しています。この結果から、スループットは「7tps」あたりが性能の限界ということが言えます。
ボトルネック調査
限界スループットの確認ができたら、ボトルネックを探していきます。ボトルネックは、性能劣化が起きる程度の負荷をかけてあげて、システムの状況を確認していきます。
今回の例では、スレッド数「32」の段階で、平均応答速度も1秒以上に上昇しているため、スレッド数「32」の負荷をかけてみます。負荷テスト実施中に、対象サーバへログインしてリソース状況やスロークエリ発生状況、各種ログなどを確認していきます。
負荷テスト実施中のvmstatを1秒間隔で実施した結果は下記の通りです。結果を見てみるとJMeterを動かし始めた8行目あたりから負荷が上昇していることがわかります。また、CPU使用率が100%張り付き状態になっていることが見て取れます。
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 512 824216 0 282076 0 0 0 0 230 426 0 0 100 0 0
0 0 512 824216 0 282076 0 0 0 32 253 475 0 0 100 0 0
0 0 512 824216 0 282076 0 0 0 0 239 435 0 0 100 0 1
0 0 512 824216 0 282076 0 0 0 0 235 429 0 1 100 0 0
9 0 512 824216 0 282076 0 0 0 0 410 506 3 0 97 0 1
13 0 512 816908 0 282076 0 0 0 0 2125 454 75 5 0 0 20
1 0 512 776588 0 282176 0 0 0 0 2480 879 89 10 1 0 0
0 0 512 725684 0 282216 0 0 0 0 1688 771 53 8 39 0 0
1 0 512 656436 0 282252 0 0 0 0 1704 702 54 9 37 0 0
5 0 512 570912 0 282292 0 0 0 0 2213 849 76 12 12 0 0
10 0 512 540880 0 282320 0 0 0 0 1940 853 65 6 29 0 0
15 0 512 476540 0 282328 0 0 0 0 2264 673 91 9 0 0 0
12 0 512 419660 0 282352 0 0 0 0 2360 764 91 9 0 0 0
11 0 512 385236 0 282424 0 0 0 0 2318 662 91 9 0 0 0
8 0 512 374860 0 282488 0 0 0 0 2343 758 91 9 0 0 0チューニング内容の検討
CPU使用率が100%張り付き状態となっていました。チューニング内容としては、
- CPUが100%張り付きとなっている原因を解消させる
- 上限を引き上げる
のどちらかになります。
システムのキャパシティは何に依存するかという記事にも書きましたが、後者のように安直にインフラの性能をあげるのは得策ではありません。なぜCPUが100%張り付きになっているのか？という部分まで踏み込んで調べたうえで、チューニング内容の検討を行いましょう。
まとめ
この記事では、限界スループットの確認方法について解説しました。スレッド数を段階的にあげていき、スループットの伸びが鈍化するポイントを探っていきます。鈍化した付近のスループットが限界スループットとなります。
また、限界スループット付近のスレッド数で負荷をかけることで、ボトルネックの調査が可能になります。スループットが順調に伸びている地点のスレッド数ではボトルネックの発見が難しいので注意してください。
また、ボトルネックの調査は、CPUやメモリ不足といった部分だけでなく、不足の根本原因はなぜか？という部分まで深堀して調査をしていきましょう。
～～～～～～～～～～～～～～～～～～～～～
～ JMeterによる負荷テスト実施入門 ～
～～～～～～～～～～～～～～～～～～～～～
第1回：JMeterによる負荷テスト実施入門
第2回：CentOS環境へのJMeterインストールと実行コマンド
第3回：基礎データの取得方法
第4回：低負荷テストの実施方法
第5回：限界スループットの確認方法
第6回：チューニング実施と効果測定 ← 次の記事
第7回：マスタスレーブ構成を用いた負荷テストの行い方
参考サービス紹介：JMeterを使った負荷テストツール