概要
前回のAMI作成方法に引き続き、移行前のチェックとして簡単なパフォーマンスチェックをします。
環境
負荷試験環境
インスタンスタイプ
サーバ | インスタンスタイプ |
---|---|
攻撃ツール | c5.2xlarge |
C4テスト | c4.large |
C5テスト | c5.large |
攻撃サーバでCPUリソースが足りないということにならないよう、充分なスペックにします。
その他設定
単純なWebフレームワークを用いた負荷検証をします。
項目 | 設定 |
---|---|
攻撃ツール | ApacheBench |
AZ | 全て同一 |
ミドルウェア | Nginx |
Webフレームワーク | github.com/gin-gonic/gin |
DBアクセス | なし |
外部リクエスト | なし |
Webアプリケーション
github.com/gin-gonic/ginを使った一番シンプルなAPIを用意します。
package main import "github.com/gin-gonic/gin" func main() { r := gin.Default() r.GET("/alive", func(c *gin.Context) { c.JSON(200, gin.H{ "message": "pong", }) }) r.Run(":3000") }
検証
実行
以下のコマンドを実行します。
$ ab -n 100000 -c 500 http://private_id/alive
カーネルパラメータによっては捌けないこともあるので以下の記事を参考にしてください。
実行中は変なボトルネックがないか、dstatで各種リソース状況を監視します。
結果
c4、c5どちらもCPU100%の状態でしたが、大体1.5倍くらいのスループットがでました。
インスタンス | Requests per second [#/sec] (mean) | Transfer rate [Kbytes/sec] |
---|---|---|
c4.large | 8192.00 | 1400.00 |
c5.large | 13392.51 | 2288.76 |
C5ではENAが有効で、C4はvifのままだったのでその影響が大きいのかもしれません。
まとめ
今回の検証ではディスクI/Oが無いのでそこはまだ不明ですが、C5系にすることでコストだけでなくパフォーマンスも向上することが分かりました。
追記
以下のサイトで各種ベンチマークが記載されていたのでこちらもご参考ください。
AWS EC2 の新世代インスタンス c5 のマイクロベンチマーキング | Cry for the Moon