缘由
之前笔者写过一篇Aurora的Graviton 2测试文章，确认在Aurora下Graviton 2的迁移，并不会带来性能的提升。近期AWS中国区又开始了一系列的Graviton 2邮件推送及session，正好也想到了我们目前生产环境中的ElastiCache for Redis的RI即将过期。
目前我们使用的是三节点的r5.2x，到期也可以更换为r6g.2x，通过邮件了解到关于Redis，也有一篇国内的测试文章，重装上阵-Graviton2提升ElastiCache for Redis的性价比，看标题是于之前的Aurora测试是同一个系列，其链接如下https://aws.amazon.com/cn/blogs/china/graviton2-enhances-performance-and-cost-optimization-of-elasticache-for-redis/
内容有点多，只摘录一下结论：
同样条件下的性能测试和延时，R6g机型（基于Graviton 第2代的ARM架构）均大幅领先原有基于通用CPU的R5机型。通过测试我们可以清楚地看到，无论是何种工作负载和并发条件，R6g实例比之同等资源配置的R5实例性能均有显著的提升，而每小时单价却有下降，因而R6g实例对客户来说，有更好的性价比。
经历了上次Aurora测试的教训，我对此还是持怀疑态度的，所以就有了本文。
一些你可能不知道的参数：Graviton 2 使用的是DDR4 3200MT/S的内存，对比的采用第一代Intel Xeon Platinum 8000处理器的c5, r5, m5则使用的是DDR4 2666MT/S的内存，采用第二代的Xeon Platinum 8000处理器的c5使用的是2933MT/S的内存。由此可以得知，就内存性能上，Graviton 2是有提升的。
准备
测试客户端
测试服务端
客户端，以及服务端每个shard的主节点都在cn-northwest-1b可用区，这样保证了不会因为延迟影响测试结果。创建ElastiCache集群，Endpoint如下
同时我们初始化客户端
$ yum install gcc git autoconf automake gcc-c++openssl-devel libevent-devel -y
$ curl -OL https://github.com/RedisLabs/memtier_benchmark/archive/refs/heads/master.zip
$ unzip master.zip && cd memtier_benchmark-master
$ autoreconf -ivf && ./configure && make
$ sudo make install
$ memtier_benchmark --version
memtier_benchmark 1.3.0
Copyright (C) 2011-2020 Redis Labs Ltd.
This is free software. You may redistribute copies of it under the terms of
the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
There is NO WARRANTY, to the extent permitted by law测试的相关命令及解释，见原文。
测试
需要注意的是，当我使用m5.8x发起测试时，有如下测试结果
$ memtier_benchmark -R --data-size-range=1024-4096 --data-size-pattern=S --test-time 180 -t 10 -c 50 --cluster-mode --ratio=1:4 -p 6379 -s r5-2x-redis.xxxxxx.clustercfg.cnw1.cache.amazonaws.com.cn可以看到吞吐量达到了10Gbps上限，可以确认原文中使用的M5.8x带宽已经不够用了，这样会影响最终测试结果，所以我们停机升级到M5.16x，以拥有20Gbps带宽上限。
重新进行测试，我们主要测试两个场景：
1.随机测试：测试500并发，键值1k到4k大小随机，测试时间180秒，SET和GET的比例为1:4；
2.正态分布（高斯分布）测试：测试1000并发，键值1k到4k大小随机，测试时间180秒，SET和GET的比例为1:4；
测试场景1
随机测试，500并发，键值1k-4k随机大小，测试时间180秒，SET和GET比例为1:4
memtier_benchmark -R --data-size-range=1024-4096 --data-size-pattern=S --test-time 180 -t 10 -c 50 --cluster-mode --ratio=1:4 -p 6379 -sALL STATS
======================================================================================================================================================
Type Ops/sec Hits/sec Misses/sec MOVED/sec ASK/sec Avg. Latency p50 Latency p99 Latency p99.9 Latency KB/sec
------------------------------------------------------------------------------------------------------------------------------------------------------
Sets 112325.26 --- --- 0.00 0.00 2.67095 2.65500 5.18300 6.20700 285477.30
Gets 449295.38 444408.42 4886.96 0.00 0.00 2.66990 2.65500 5.18300 6.30300 1127564.62
Waits 0.00 --- --- --- --- --- --- --- --- ---
Totals 561620.64 444408.42 4886.96 0.00 0.00 2.67011 2.65500 5.18300 6.27100 1413041.92
ALL STATS
======================================================================================================================================================
Type Ops/sec Hits/sec Misses/sec MOVED/sec ASK/sec Avg. Latency p50 Latency p99 Latency p99.9 Latency KB/sec
------------------------------------------------------------------------------------------------------------------------------------------------------
Sets 109147.88 --- --- 0.00 0.00 2.74878 2.86300 5.18300 5.79100 277403.41
Gets 436586.56 431977.02 4609.53 0.00 0.00 2.74750 2.86300 5.18300 5.85500 1095972.25
Waits 0.00 --- --- --- --- --- --- --- --- ---
Totals 545734.43 431977.02 4609.53 0.00 0.00 2.74776 2.86300 5.18300 5.85500 1373375.66
以上结果R5在前，R6g在后。
测试场景2
（即文中的2-4，需要注意原文的2-4给出的命令缺少了1:4的条件）正态分布（高斯分布）测试，1000并发，键值1k-4k随机大小，测试时间180秒，SET和GET比例为1:4
memtier_benchmark -R --data-size-range=1024-4096 --data-size-pattern=S --test-time 180 -t 20 -c 50 --cluster-mode --key-pattern=G:G --ratio=1:4 -p 6379 -sALL STATS
======================================================================================================================================================
Type Ops/sec Hits/sec Misses/sec MOVED/sec ASK/sec Avg. Latency p50 Latency p99 Latency p99.9 Latency KB/sec
------------------------------------------------------------------------------------------------------------------------------------------------------
Sets 128693.56 --- --- 0.00 0.00 4.65447 4.70300 7.51900 32.25500 327888.84
Gets 514763.40 511036.38 3727.02 0.00 0.00 4.66178 4.73500 7.51900 32.25500 1299658.56
Waits 0.00 --- --- --- --- --- --- --- --- ---
Totals 643456.95 511036.38 3727.02 0.00 0.00 4.66032 4.73500 7.51900 32.25500 1627547.40
ALL STATS
======================================================================================================================================================
Type Ops/sec Hits/sec Misses/sec MOVED/sec ASK/sec Avg. Latency p50 Latency p99 Latency p99.9 Latency KB/sec
------------------------------------------------------------------------------------------------------------------------------------------------------
Sets 125999.78 --- --- 0.00 0.00 4.72115 4.63900 7.58300 34.04700 321028.51
Gets 503988.11 500792.38 3195.74 0.00 0.00 4.76959 4.67100 7.64700 35.07100 1273558.64
Waits 0.00 --- --- --- --- --- --- --- --- ---
Totals 629987.90 500792.38 3195.74 0.00 0.00 4.75990 4.67100 7.61500 34.81500 1594587.15以上结果R5在前，R6g在后。
结论
整理一下结果写入性能
读取性能
延迟表现 取P99
从数据可以看出，同样条件下吞吐量，r6g相较于r5存在2%左右的劣势，延迟表现则两者相同或者r6g略优于r5，这于文中的结果完全不同。然而我们仍然注意到，r6g在价格上是存在5%的优势的，所以你仍然可以基于成本考虑完成这个迁移。
同时在查询资料的过程中，发现AWS Global Blog已经有类似的测试了，只是没有详细的步骤，我把那篇文章的结果也摘录下来。https://aws.amazon.com/cn/blogs/database/migrate-amazon-elasticache-to-graviton2-processors/
可以看出，随着实例类型的变大，Graviton 2的吞吐量其实是没有变化的，这导致了在2x以上规模时，Graviton 2和x86的性能差异已经非常小了。