以前、R4インスタンスが使えるようになったときにmysqlslapで性能テストをしたので、今回、同じ条件で再度R4インスタンスだけmysqlslapしてみました。
- Amazon AuroraでR4インスタンスを試してみる ※2017/10/30～31に実施
mysqlslapの内容
前回と同じです。
mysqlslap
$ mysqlslap --auto-generate-sql --auto-generate-sql-guid-primary --engine=innodb --number-int-cols=20 --number-char-cols=20 --concurrency=150 --auto-generate-sql-write-number=2000 --auto-generate-sql-execute-number=2000 --auto-generate-sql-load-type=mixed -u 【ユーザ名】 -h 【クラスタエンドポイント】 -p
結果
結構、衝撃的です…。
なお、暗号化の有無での性能差はわずかしかありませんでしたので、今回は暗号化ありの結果のみ掲示しておきます。
また、参考として、今回はr4.2xlargeインスタンスの結果も加えておきます。
| 実施時期 | r4.large・バイナリログなし | r4.large・バイナリログあり | r4.xlarge・バイナリログなし | r4.xlarge・バイナリログあり | r4.2xlarge・バイナリログなし | r4.2xlarge・バイナリログあり |
|---|---|---|---|---|---|---|
| 前回(2017/10/末・Ver.1.15) | 48.860 | 57.737 | 33.133 | 37.857 | - | - |
| 今回(2018/01/上・Ver.1.16) | 74.779 | 91.679 | 45.433 | 54.413 | 34.180 | 39.621 |
| 性能比 | 65.3% | 63.0% | 72.9% | 69.6% | - | - |
※単位は秒。すべて暗号化ありの結果。
ちょうどインスタンスタイプ1段階分ぐらい遅くなっています。
もしかして前回インスタンスタイプの指定を1段階間違えたか？と思って請求情報を見たら、間違っていませんでした。
もちろん、クライアント側に問題がないか確認するためにクライアント側のEC2インスタンスもタイプを色々変えて試しましたが、結果は誤差の範囲でした（AZも一致していることを確認）。
ただ、実際のワークロードはmysqlslapとは違うので、プロダクト環境でどうなるかは実際の環境で確認・検証してください。
※明日から私もプロダクト環境と同等のステージング環境で性能テストです…つらいことになる予感。
