Redis 性能问题的记录

最近线上使用redis, 查询的情况不甚理想, 这个查询操作是个 lua 脚本, 包含如下操作

开发机 redis, 没有其他干扰, 插入的 zset 有 5000 member 左右, 使用的 redis 客户端是 spring-data, 底层 jedis 实现, 另外自己封装了一层, 单线程单客户端测试

1. zrange key 0 0 withscores

2. expire key

3. zadd key score member

A. 结果测试10w次发现平均每次拿到数据的时间需要 2800 us (2.8 ms). 也就是说 qps 只能达到 350 左右

B. 于是在本地在此进行测试, 结果是每次调用花费 300 us (0.3 ms), 差了 10 倍左右

而在本地和开发机上直接用 redis benchmark 测试 zadd, 使用单客户端测试性能 , 测试命令如下

A. 本机测试

redis-benchmark -n  -c  -r  zadd testzset  __rand_int__
====== zadd testzset  __rand_int__ ======
   requests completed in 3.37 seconds
   parallel clients
   bytes payload
  keep alive: 

100.00% <=  milliseconds
29647.20 requests per second

约合 34 us / command

B. dev 机器测试

redis-benchmark -h l-remote1.com -p  -n  -c  -r  zadd testzset  __rand_int__
====== zadd testzset  __rand_int__ ======
   requests completed in 10.53 seconds
   parallel clients
   bytes payload
  keep alive: 

47.43% <=  milliseconds
99.75% <=  milliseconds
99.90% <=  milliseconds
99.97% <=  milliseconds
99.99% <=  milliseconds
100.00% <=  milliseconds
949.58 requests per second

约合 1053 us / command

下面是使用 java redis 客户端详细的测试数据

单位 us

Local Test 10W Zrange

No test on borrow
.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

Test on borrow
.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

Local Test 10W Lua

No test

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

Test on borrow

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

Dev Redis 10W Zrange

No borrow test

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

Test on borrow

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

Dev Redis 10W Lua

No borrow test

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

test on borrow

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

.
elapsed :  count :  avg :
Mon elapsed :  count :  avg : 

可以发现实际上 java 客户端的性能并没有差多少, 使用 zrange 查询远端客户端在没有 test on borrow 的情况下也在 1 ms 左右, 加上 test on borrow 马上翻倍, 这就是 RTT 的效果, 按照 netty 的工作线程数为 8 个, 这个线程数根本还无法将 RTT 的影响达到最低, 据我测试起码需要大于 10 个并行客户端的数量才可以消除

并发客户端的数量对 benchmark 的测试的影响是非常大的, 由于 RTT (routnd trip time) 的存在, 本地网卡的网络延时可能不明显, 但是如果是非本地环境, RTT 就会显得非常严重了, 例如只用单客户端进行测试, 如下

本地测试单客户端

edis-benchmark -n  -c  zrange dp.
====== zrange dp.   ======
   requests completed in 3.31 seconds
   parallel clients
   bytes payload
  keep alive: 

100.00% <=  milliseconds
30229.75 requests per second

本地测试多客户端

redis-benchmark -n  -c  zrange dp.
====== zrange dp.   ======
   requests completed in 1.38 seconds
   parallel clients
   bytes payload
  keep alive: 

100.00% <=  milliseconds
72516.32 requests per second

远程测试单客户端, 发现连 1000 qps 都到不了

redis-benchmark -h l-remote1.com -p  -n  -c  zrange dp.
====== zrange dp.   ======
   requests completed in 10.18 seconds
   parallel clients
   bytes payload
  keep alive: 

73.23% <=  milliseconds
99.93% <=  milliseconds
99.99% <=  milliseconds
100.00% <=  milliseconds
982.80 requests per second

远程 10 客户端

redis-benchmark -h l-remote1.com -p  -n  -c  zrange dp.
====== zrange dp.   ======
   requests completed in 10.56 seconds
   parallel clients
   bytes payload
  keep alive: 

52.75% <=  milliseconds
99.81% <=  milliseconds
99.99% <=  milliseconds
100.00% <=  milliseconds
9468.80 requests per second

远程 50 客户端

redis-benchmark -h l-remote1.com -p  -n  -c  zrange dp.
====== zrange dp.   ======
   requests completed in 4.86 seconds
   parallel clients
   bytes payload
  keep alive: 

1.19% <=  milliseconds
26.45% <=  milliseconds
98.55% <=  milliseconds
99.87% <=  milliseconds
99.94% <=  milliseconds
99.95% <=  milliseconds
99.96% <=  milliseconds
99.97% <=  milliseconds
99.99% <=  milliseconds
100.00% <=  milliseconds
20580.37 requests per second

可以发现多客户端情况下 qps 不在一个级别

回到上面的测试

我们单线程的 java 客户端执行 zrange 也就 1000 qps 到不了, 算上现在 3 台机器 + 每台机器 8 个工作线程, 撑死达到 1000 * 3 * 8 = 24000 的 qps, 而且机器上还有很多别的任务, redis 操作也不止一个 zrange, 能到 10000 qps 已经很不错了我相信. 所以最终还不能这么搞, 能解决问题办法我初步考虑应该是

1. 异步 redis 客户端, 别阻塞工作线程

2. 增加 redis 客户端执行任务线程数 (目前这种同步情况下就是 netty 的工作线程)