Redis on ElastiCache で、AOFをeverysecでどの程度性能差が発生するのかの把握
| サーバー | 配置 | Redisバージョン | OS | インスタンスタイプ | Slave 有無 |
|---|---|---|---|---|---|
| Client | Private VPC内部 | - | Amazon Linux | m2.4xlarge | - |
| EC2 Redis | Private VPC内部 | Redis 2.6.12 | Amazon Linux | m2.4xlarge | なし |
| ElasticCacheRedis | Private VPC内部 | Redis 2.6.13 | ElastiCache (Amazon Linux) | m2.4xlarge | 1 |
| サーバー | 接続先IP | VPC内部接続かどうか |
|---|---|---|
| EC2 Redis | 10.0.3.252 | VPC内部での接続 |
| ElasticCache Redis | 10.0.3.234 (Node EndPoint 指定のリダイレクト) | VPC 内部での接続 |
※メモリ読み込み量 400MB (RDB)
| パラメータ | ec2設定 | ElastiCache設定 |
|---|---|---|
| AOF | everysec | everysec |
| save | "" | あり (しかない) |
| max memory | 0 (上限なし) | 0 (上限なし) |
| max client | 0 (上限なし) | 0 (上限なし) |
| tcp-keepalive | 0 | 0 |
| timeout | 0 | 0 |
ElastiCache はできないため省略
| パラメータ | 設定値 |
|---|---|
| net.ipv4.ip_local_port_range | 1024 65000 |
| net.core.somaxconn | 1024 |
| net.ipv4.tcp_syn_retries | 1 |
| net.ipv4.tcp_fin_timeout | 10 |
| net.ipv4.tcp_tw_recycle | 1 |
| net.core.somaxconn | 30720 |
| net.core.netdev_max_backlog | 30720 |
| net.ipv4.tcp_max_syn_backlog | 30720 |
パラメータをいじらない ベンチマークを基準として、 大きく 4つのベンチ測定要素で計測 (pipeline は常に有効)
- Request 数を増やして、リクエストが増加した時の応答の違い
- DataSize を増やして、送信サイズが大きい場合の応答の違い
- KeySize を増やした場合の応答の違い
- Concurrency を増やして、同時接続数が増加した時の応答の違い
各種5回実施してaverageで計測
AOFの有無で全般的に 大きな差はつかず。(96%前後 - 103%前後 の 範囲内)
96 - 103% というのは、Redis自体がベンチマーク結果にぶれを起こすことはご存知の通りで、おおよそ誤差範囲内と見なせます。RDBのsave環境と同等の性能を発揮できる環境とみなしてもよいでしょう。
また、テストホストにsomaxconn, backlogを設定することで、性能の向上があることも特筆できます。(32000/seq => 38000/req)
対照試験から、1.5GB程度のメモリでは、載せてものせなくともそこまで大きくは性能に影響がでませんでした。(ある程度の劣化は免れませんでしたが)
