在各场景下检测 Graviton2 R6g 与 R5 的运算性能

发布于: Aug 19, 2022

今天我们将在各种环境下检测 Graviton2 R6g 与 R5 的运算性能，并做出对比。以下是整个测试的过程。

1 只读测试

注意：只读测试，我们只演示测试 redis-benchmark 工具。

测试 R5.2xlarge 机型的只读测试命令如下（压测 200 万次，并发 1000，随机 key 和 value，大小 1k，不使用管道）

redis-benchmark -n 2000000 -c 1000 -t get -d 1024 -p 6379 -h r5-2xlarge-elasticache-for-redis-cluster-endpoint --csv

测试 R6g.2xlarge 机型的只读测试命令如下（压测 200 万次，并发 1000，随机 key 和 value，大小 1k，不使用管道）

redis-benchmark -n 2000000 -c 1000 -t get -d 1024 -p 6379 -h r6g-2xlarge-elasticache-for-redis-cluster-endpoint --csv

结果如下（此处截图仅供参考，不参与后面的性能统计）：

2 只写测试

注意：只写测试，我们只演示测试 redis-benchmark 工具。
测试 R5.2xlarge 机型的只写测试命令如下（压测 200 万次，并发 1000，随机 key 和 value，大小 1k，不使用管道）

redis-benchmark -n 2000000 -c 1000 -t set,hset -d 1024 -p 6379 -h r5-2xlarge-elasticache-for-redis-cluster-endpoint --csv

测试 R6g.2xlarge 机型的只写测试命令如下（压测 200 万次，并发 1000，随机 key 和 value，大小 1k，不使用管道）

redis-benchmark -n 2000000 -c 1000 -t set,hset -d 1024 -p 6379 -h r6g-2xlarge-elasticache-for-redis-cluster-endpoint --csv

结果如下（此处截图仅供参考，不参与后面的性能统计）：

3 混合测试

3.1 通过 redis-benchmark 测试

此处我们设定四个场景，分别是如下两种并发和键值（key/value）大小的组合：

500 并发，1k 大小和 4k 大小；
1000 并发，1k 大小和 4k 大小；

如下为对应的测试命令（包括常用的命令 SET 和 GET，以及在实际业务中比较常用的 HSET）。

测试场景 1-1：500 并发，1k 大小，200 万次请求

redis-benchmark -n 2000000 -c 500 -t set,get,hset -d 1024 -p 6379 -h r5-2xlarge-elasticache-for-redis-cluster-endpoint --csv

和

redis-benchmark -n 2000000 -c 500 -t set,get,hset -d 1024 -p 6379 -h r6g-2xlarge-elasticache-for-redis-cluster-endpoint --csv

测试场景 1-2：500 并发，4k 大小，200 万次请求

redis-benchmark -n 2000000 -c 500 -t set,get,hset -d 4096 -p 6379 -h r5-2xlarge-elasticache-for-redis-cluster-endpoint --csv

和

redis-benchmark -n 2000000 -c 500 -t set,get,hset -d 4096 -p 6379 -h r6g-2xlarge-elasticache-for-redis-cluster-endpoint --csv

测试场景 1-3：1000 并发，1k 大小，200 万次请求

redis-benchmark -n 2000000 -c 1000 -t set,get,hset -d 1024 -p 6379 -h r5-2xlarge-elasticache-for-redis-cluster-endpoint --csv

和

redis-benchmark -n 2000000 -c 1000 -t set,get,hset -d 1024 -p 6379 -h r6g-2xlarge-elasticache-for-redis-cluster-endpoint --csv

测试场景 1-4：1000 并发，4k 大小，200 万次请求

redis-benchmark -n 2000000 -c 1000 -t set,get,hset -d 4096 -p 6379 -h r5-2xlarge-elasticache-for-redis-cluster-endpoint --csv

和

redis-benchmark -n 2000000 -c 1000 -t set,get,hset -d 4096 -p 6379 -h r6g-2xlarge-elasticache-for-redis-cluster-endpoint --csv

每种场景测试 5 次以上，然后取如下图所示的 SET、GET 和 HSET 的值并计算均值作为结果（因为 redis-benchmark 的单进程特性，在并发和模拟实际客户端场景层面难以完全覆盖，我们测试发现请求数在约 10 万/秒左右即达到上限，即使修改并发和数据大小也无法突破，所以这部分留给读者自己去做操作和测试验证，本文测试数据收集不考虑此工具，防止数据出现偏差）。

3.2 通过 memtier_benchmark 测试

此处我们同样设定四个场景，为如下条件的组合：

随机测试：分别测试 500 和 1000 并发，键值 1k 到 4k 大小随机，测试时间 180 秒，SET 和 GET 的比例为 1：4；
正态分布（高斯分布）测试：分别测试 500 和 1000 并发，键值 1k 到 4k 大小随机，测试时间 180 秒，SET 和 GET 的比例为 1：4；

我们没有设置更高的并发或更大的键值测试，因为在测试的过程中，我们发现系统运行比较稳定，调高并发或键值会导致本文的测试客户端 m5.8xlarge 的带宽使用率直接打满 10G（如果要测试集群的极限，建议采用多客户端的分布式测试方式，本文暂不涉及），我们的测试命令只包括 SET 和 GET，且为了更好的模拟实际生产环境中的读写比例，所以此处读写比例设置为 1：4（模拟 20% 写）。

测试场景 2-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 -s r5-2xlarge-elasticache-for-redis-cluster-endpoint

和

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 r6g-2xlarge-elasticache-for-redis-cluster-endpoint

测试场景 2-2：随机测试，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 --ratio=1:4 -p 6379 -s r5-2xlarge-elasticache-for-redis-cluster-endpoint

和

memtier_benchmark -R --data-size-range=1024-4096 --data-size-pattern=S --test-time 180 -t 20 -c 50 --cluster-mode --ratio=1:4 -p 6379 -s r6g-2xlarge-elasticache-for-redis-cluster-endpoint

测试场景 2-3：正态分布（高斯分布）测试，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 --key-pattern=G:G -p 6379 -s r5-2xlarge-elasticache-for-redis-cluster-endpoint

和

memtier_benchmark -R --data-size-range=1024-4096 --data-size-pattern=S --test-time 180 -t 10 -c 50 --cluster-mode --key-pattern=G:G -p 6379 -s r6g-2xlarge-elasticache-for-redis-cluster-endpoint

测试场景 2-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 -p 6379 -s r5-2xlarge-elasticache-for-redis-cluster-endpoint

和

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 -p 6379 -s r6g-2xlarge-elasticache-for-redis-cluster-endpoint

在测试过程中，我们发现系统运行非常稳定，所以每种场景测试了 6 次，然后取如下图所示的 Sets、Gets 和 Waits 的 p99 均值（其中 1000 并发我们没有取 p99 的均值，而是取了总体的均值，因为我们发现在 R5 机型的集群中，1000 并发的情况下，p99 均值的波动和方差太大，而 R6g 的机型没有这个问题，为了方便对比，就没有取并发 1000 的延时 p99 均值）。