Redis Benchmark 的常见陷阱

结果的波动

  5 次结果: ['116k', '122k', '111k', '109k', '119k']  最大/最小 = 1.12

同一个命令连续 5 次:116k、122k、111k、109k、119k,最大/最小 1.12。差别小于这个范围的对比都可能只是噪声。

key 空间

  默认(同一个 key):122k/s,跑完后 DBSIZE = 1,used_memory 1.0 MB
  -r 1000000:      122k/s,跑完后 DBSIZE = 950275,used_memory 60.3 MB

默认情况下 redis-benchmark 的所有请求打同一个 key(key:__rand_int__ 在没有 -r 时是同一个),跑完 100 万次 SET 库里只有 1 个 key、1.0 MB。-r 1000000 才会用随机 key(跑完 950275 个、60 MB)。本机这个无管道的负载里两者吞吐一样,但依赖数据量的现象(命中率、淘汰、fork、RDB/AOF)在「一个 key」的测试里根本不会出现。

value 大小

  -d      3:    124k 条/秒  ≈       0 MB/s 负载
  -d    100:    121k 条/秒  ≈      12 MB/s 负载
  -d   1024:    112k 条/秒  ≈     115 MB/s 负载
  -d  10240:     96k 条/秒  ≈     987 MB/s 负载
  -d 102400:     35k 条/秒  ≈    3550 MB/s 负载

3、100、1024 字节的 value 吞吐几乎一样(124k、121k、112k),10 KB 降到 96k,100 KB 只有 35k。默认 3 字节 value 测不到大 value 下的行为。(我第一次把这组和 -r 100000 一起跑,结果是 100 KB × 10 万个 key = 近 10 GB,把机器压进了交换,实验被我中止后重做;这也是一个「压测会把机器压垮」的真实例子。)

连接数与管道

  P=1  c=1   :      42k 条/秒
  P=1  c=10  :     119k 条/秒
  P=1  c=50  :     112k 条/秒
  P=1  c=500 :     103k 条/秒
  P=16 c=1   :     430k 条/秒
  P=16 c=10  :     968k 条/秒
  P=16 c=50  :     968k 条/秒
  P=16 c=500 :     940k 条/秒

无管道时 1 个连接受往返限制(42k),10 个连接以上到平台(119k);管道 16 后平台是 968k,再多连接(500)略降到 940k。选哪一种要看你的业务真实是什么样:一个连接同步请求的业务和大批量导入的业务,数字差一个数量级。

压测机的位置

这篇的所有数字都是同一台机器、回环网络、压测程序与 Redis 抢 CPU。它们只能用来比较配置,不能当作容量规划的依据;容量规划要用独立的压测机、真实网络,并且用接近真实的命令组合与 key/value 分布(第 121 篇)。

分步演示:五个陷阱