简介


使用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