第5回：限界スループットの確認方法では、限界スループットとボトルネックの確認を行いました。
この記事では、ボトルネックに対してチューニングを行っていきます。また、チューニング後のスループットを計測し、効果測定を行います。最後に、ボトルネック以外の部分についてチューニングを実施した場合の効果測定についてもしてみようと思います。
チューニング実施
チューニングはボトルネックに対して実施する必要があります。前回の記事で、ボトルネックはサーバのCPU使用率にあることがわかりました。EC-CUBE側の修正ができれば望ましいですが、今回はサーバのスケールアップでチューニングを行っていきます。
サーバーはAWSの「t3.small」で動作させています。t3シリーズのスペックを確認したところ、次のような違いがありました。
表．t3シリーズ の抜粋
| インスタンス | vCPU | メモリ | 備考 |
|---|---|---|---|
| t3.small | 2 | 2.0 | |
| t3.medium | 2 | 4.0 | CPU変わらず |
| t3.large | 2 | 8.0 | CPU変わらず |
| t3.xlarge | 4 | 16.0 | CPUが2倍 |
CPUがボトルネックとなっているので、vCPUが倍になる「t3.xlarge」へスケールアップさせてみます。
チューニングの効果測定
性能測定は、限界スループットの確認と同様のことを行っていきます。
「t3.small」のスペックを、vCPUが2倍になる「t3.xlarge」に変更したときのテスト結果は次のようになりました。
表．テスト結果
| スレッド数 | スループット(tps) | 理想スループット | 平均応答速度(s) |
|---|---|---|---|
| 1 | 0.39 | 0.39 | 359 |
| 2 | 0.74 | 0.78 | 341 |
| 4 | 1.43 | 1.56 | 315 |
| 8 | 2.91 | 3.12 | 304 |
| 16 | 5.66 | 6.24 | 292 |
| 24 | 8.05 | 9.36 | 297 |
| 32 | 10.61 | 12.48 | 344 |
| 48 | 14.6 | 18.72 | 470 |
| 64 | 18.29 | 24.96 | 1218 |
| 96 | 19.22 | 37.44 | 3246 |
グラフにしたものは次の通りです。
チューニング後のスループット推移
スレッド数「64」くらいで性能が落ちているように見えます。限界のスループットは「20」あたりです。
効果測定
「t3.small」を「t3.xlarge」へスケールアップしました。チューニング後のスループットの測定ができたので、チューニング効果を比較していきます。
平均応答速度の比較
下のグラフは、チューニング前後の「平均応答速度」を比較したものになります。
平均応答速度の性能比較
平均応答速度は、スレッド数「16」くらいまではほぼ同一です。「24」になるとチューニング前は応答速度の劣化が始まり、チューニング後は「64」を超えたあたりから劣化が始まっていることがわかります。
スループットの比較
下のグラフは、チューニング前後の「スループット」を比較したものになります。
スループットの性能比較
限界スループットについても、チューニング前は「10」あたりで頭打ちしていたのに対して、チューニング後は「20」で頭打ちしているのがわかります。
チューニングの効果測定結果
以上のことから、今回のチューニングでほぼ倍の性能向上をすることができました。チューニングでは、CPUを2vCPUから4vCPUに増強しました。この増強分がそのまま性能向上に反映されていることがわかります。
効果のないチューニング例
効果的なチューニングを行うことで、性能向上につなげられることがわかったかと思います。ここでもし、CPU性能が同一でメモリが2倍の「t3.medium」にスケールアップした場合にどのような結果になるかについても確認してみます。
表．t3シリーズ の抜粋
| インスタンス | vCPU | メモリ | 備考 |
|---|---|---|---|
| t3.small | 2 | 2.0 | |
| t3.medium | 2 | 4.0 | CPU変わらず。このスペックへスケールアップ |
| t3.xlarge | 4 | 16.0 | CPUが2倍 |
「スループット」および「平均応答速度」の比較結果は次の通りです。
平均応答速度の比較
下のグラフは、チューニング前後の「平均応答速度」を比較したものになります。
CPU性能が同一のインスタンスへスケールアップした場合の平均応答速度比較
「t3.small」と「t3.medium」ともに、スレッド数「24」あたりで応答速度が劣化しているのがわかります。
スループットの比較
下のグラフは、チューニング前後の「スループット」を比較したものになります。
CPU性能が同一のインスタンスへスケールアップした場合のスループット比較
平均応答速度と同様に、「t3.small」と「t3.medium」は同じょうな推移をしています。
チューニングの効果測定結果
「t3.small」と「t3.medium」は、スレッド数「24」あたりで劣化がはじまっており、近しい結果となりました。結果が近しい、ということは、チューニング効果が薄いということです。ボトルネックとは関係ない、メモリの増強のチューニングをしても、効果が薄いことがわかりました。
まとめ
CPU使用率がボトルネックのシステムに対して、vCPUを2倍にするチューニングを施しました。結果として、約2倍のスループット向上が確認できました。
今回のようにインフラのスケールアップではほぼ等倍の性能向上が期待できます。
システムのキャパシティは何に依存するかにもまとめた通り、アプリケーション側のボトルネックを改修できると、数十倍のチューニング効果を得ることも可能になるので、可能な限りアプリケーション側のチューニングを検討していけるといいでしょう。
また、チューニングは、ボトルネックに対して適切に行う必要があります。見当違いのチューニングを施すと、「t3.medium」へスケールアップしたときのように、性能向上を得ることができません。適切にボトルネックを特定し、チューニングできるようになりましょう。
参考：
チューニング事例にチューニング前後の性能比較を載せているので参考にしてみてください。
～～～～～～～～～～～～～～～～～～～～～
～ JMeterによる負荷テスト実施入門 ～
～～～～～～～～～～～～～～～～～～～～～
第1回：JMeterによる負荷テスト実施入門
第2回：CentOS環境へのJMeterインストールと実行コマンド
第3回：基礎データの取得方法
第4回：低負荷テストの実施方法
第5回：限界スループットの確認方法
第6回：チューニング実施と効果測定
第7回：マスタスレーブ構成を用いた負荷テストの行い方 ← 次の記事
参考サービス紹介：JMeterを使った負荷テストツール