浅谈Redis延迟测试方法

简介

使用Redis的小伙伴们都希望能够获取最大的性能收获，不管什么操作，越快越好。

然而，在实际的使用中，却发现有些指令的执行并不像想象中的那样flash。

怎么办？我觉得首先需要回答下面这个问题：

到底是Redis本身慢了，还是业务逻辑性能出了问题？

本文主要针对第一种情况，来进行一下Redis延迟的基准性能测试。

如果基准测试没有问题，那么Redis自身大概是没有什么问题的，就要检查一下业务逻辑或者使用的指令是否是慢指令了。

基本延迟

下面的测试都是使用 redis-cli 客户端进行，基础命令如下：

redis-cli -h 192.168.1.66 -p 6379

直接使用该客户端可以避免其他因素对测试结果的影响。

理论上，如果是在本机测试，结果就是Redis自身延迟。如果不是本机，则多了一次网络传输的延迟（这个需要自行评估）。

基础的延迟测试命令如下：

redis-cli -h 127.0.0.1 -p 6379 --latency

该命令会统计三个延迟指标：最小值（min），最大值（max）和平均值（avg），单位是ms。

通过 ctrl + c 结束命令。

说明：

该指令统计的是 PING 指令的耗时
其中不包括连接建立时间
连接的是本地Redis服务，也不包含网络传输时间

示例结果如下：

% redis-cli -h 127.0.0.1 -p 6379 --latency
min: 0, max: 1, avg: 0.16 (3054 samples)

可见平均延迟为0.16ms，即160us，共统计了3054个样本数据。

在不同的服务器上安装的Redis，性能会有不同。

比如我同样在虚拟机上跑了一下：

min: 0, max: 1, avg: 0.23 (3123 samples)

结果要比物理机上差一些。

也可以使用以下命令测试：

redis-cli -h 127.0.0.1 -p 6379 --latency-history -i 10

该命令可以按间隔打印结果，间隔时间由-i参数指定，默认15s。

物理机上测试如下：

% redis-cli --latency-history  -i 10
min: 0, max: 1, avg: 0.16 (974 samples) -- 10.01 seconds range
min: 0, max: 1, avg: 0.18 (972 samples) -- 10.00 seconds range
min: 0, max: 1, avg: 0.18 (972 samples) -- 10.01 seconds range
min: 0, max: 1, avg: 0.17 (973 samples) -- 10.01 seconds range
min: 0, max: 1, avg: 0.16 (972 samples) -- 10.01 seconds range

虚拟机测试结果：

# redis-cli -p 7000 --latency-history  -i 10
min: 0, max: 1, avg: 0.24 (969 samples) -- 10.01 seconds range
min: 0, max: 1, avg: 0.23 (967 samples) -- 10.01 seconds range
min: 0, max: 1, avg: 0.23 (967 samples) -- 10.01 seconds range
min: 0, max: 1, avg: 0.22 (967 samples) -- 10.01 seconds range
min: 0, max: 1, avg: 0.23 (966 samples) -- 10.00 seconds range

固有延迟

Redis还提供了测试固有延迟基准的方法：

redis-cli --intrinsic-latency 100

注意：

100指的是测试时长为100s，可以任意指定
该指令测试的是操作系统内核调用进程的最大延迟
该延迟是固有的，业务延迟不可能比它还小。可以把它作为延迟的最低基准
该指令需要在运行Redis服务的机器上运行
该指令并不会真正连接Redis服务
在不同的系统上，或者在同一系统的不同时间段测试时，都可能得到不同的结果
系统负载大小对测试结果有较大影响

物理机上测试结果：

% redis-cli --intrinsic-latency 100
Max latency so far: 1 microseconds.
Max latency so far: 6 microseconds.
Max latency so far: 9 microseconds.
Max latency so far: 10 microseconds.
Max latency so far: 11 microseconds.
Max latency so far: 153 microseconds.
Max latency so far: 155 microseconds.
Max latency so far: 156 microseconds.
Max latency so far: 176 microseconds.
Max latency so far: 177 microseconds.
Max latency so far: 178 microseconds.1838554810 total runs (avg latency: 0.0544 microseconds / 54.39 nanoseconds per run).
Worst run took 3273x longer than the average latency.

虚拟机上测试结果：

# redis-cli --intrinsic-latency 100
Max latency so far: 1 microseconds.
Max latency so far: 13 microseconds.
Max latency so far: 17 microseconds.
Max latency so far: 18 microseconds.
Max latency so far: 23 microseconds.
Max latency so far: 30 microseconds.
Max latency so far: 39 microseconds.
Max latency so far: 65 microseconds.
Max latency so far: 74 microseconds.
Max latency so far: 138 microseconds.
Max latency so far: 144 microseconds.
Max latency so far: 160 microseconds.
Max latency so far: 188 microseconds.
Max latency so far: 190 microseconds.
Max latency so far: 243 microseconds.
Max latency so far: 364 microseconds.829284793 total runs (avg latency: 0.1206 microseconds / 120.59 nanoseconds per run).
Worst run took 3019x longer than the average latency.

定位延迟

如果发现延迟较大，有一些方法可以定位延迟出现的情况：

确保没有执行慢指令（慢指令会导致Redis服务阻塞），可以使用 slowlog 查看，具体：https://redis.io/commands/slowlog
关闭内核Transparent huge pages：echo never > /sys/kernel/mm/transparent_hugepage/enabled（需要重启Redis服务）
测试固有延迟（如果固有延迟已经较大，可能是操作系统负载较高或性能不佳）
使用Redis的Latency Monitoring功能监测延迟情况，具体：https://redis.io/topics/latency-monitor

小结

有了各种客户端的支持，Redis是极容易使用的。

但是要把Redis的优势完全地发挥利用出来，还是需要好好研究一番的。

Redis也不是完美的，所以有必要了解避免踩坑的方法。

避其缺陷，扬其优势，方能为项目所用。

关于延迟分析的更多内容，可参考：https://redis.io/topics/latency