如何理解redis-cli的结果与redis-benchmark的结果

Question

首先,我是Redis的新手.

所以,我测量延迟redis-cli:

$ redis-cli --latency
min: 0, max: 31, avg: 0.55 (5216 samples)^C

好的,平均而言我在0.55毫秒内得到了响应.由此我假设在1秒内只使用一个连接,我可以得到:1000ms/0.55ms =每秒1800个请求.

然后在同一台计算机上,我只redis-benchmark使用一个连接运行,每秒获得超过6000个请求:

$ redis-benchmark -q -n 100000 -c 1 -P 1
PING_INLINE: 5953.80 requests per second
PING_BULK: 6189.65 requests per second

因此,测量延迟时,我预计每秒最多可获得2000个请求.但是我每秒得到6000个请求.我找不到解释.我计算时是否正确:1000毫秒/ 0.55毫秒=每秒1800个请求？

Answer 1

是的,你的数学是正确的.

IMO,差异来自调度工件(即操作系统调度程序或网络环回的行为).

redis-cli延迟由一个循环实现,该循环仅在等待10 ms之前发送PING命令.让我们尝试一下实验,并将redis-cli --latency的结果与10 ms的等待状态进行比较.

为了准确起见,我们首先确保客户端和服务器始终在确定性CPU核心上进行调度.注意:在NUMA盒子上进行基准测试通常是个好主意.此外,请确保CPU的频率被阻止到给定值(即没有电源模式管理).

# Starting Redis
numactl -C 2 src/redis-server redis.conf
# Running benchmark
numactl -C 4 src/redis-benchmark -n 100000 -c 1 -q -P 1 -t PING
PING_INLINE: 26336.58 requests per second
PING_BULK: 27166.53 requests per second

现在让我们看一下延迟(10 ms等待状态):

numactl -C 4 src/redis-cli --latency
min: 0, max: 1, avg: 0.17761 (2376 samples)

与redis-benchmark的吞吐量结果相比,这似乎太高了.

然后,我们更改redis-cli.c的源代码以删除等待状态,然后重新编译.代码也被修改为显示更准确的数字(但不常见,因为不再有等待状态).

Here is the diff against redis 3.0.5:
1123,1128c1123
<             avg = ((double) tot)/((double)count);
<         }
<         if ( count % 1024 == 0 ) {
<             printf("\x1b[0G\x1b[2Kmin: %lld, max: %lld, avg: %.5f (%lld samples)",
<                 min, max, avg, count);
<             fflush(stdout);
---
>             avg = (double) tot/count;
1129a1125,1127
>         printf("\x1b[0G\x1b[2Kmin: %lld, max: %lld, avg: %.2f (%lld samples)",
>             min, max, avg, count);
>         fflush(stdout);
1135a1134
>         usleep(LATENCY_SAMPLE_RATE * 1000);

请注意,此补丁不应用于实际系统,因为它会使redis-client --latency功能昂贵且侵入服务器的性能.其目的只是为了说明我对当前讨论的观​​点.

再来一次:

numactl -C 4 src/redis-cli --latency
min: 0, max: 1, avg: 0.03605 (745280 samples)

惊喜!现在平均延迟要低得多.此外,1000/0.03605 = 27739.25,这与redis-benchmark的结果完全一致.

道德:操作系统调度的客户端循环越多,平均延迟就越低.如果您的Redis客户端足够活跃,那么信任redis-benchmark和redis-cli -latency是明智之举.无论如何,请记住平均延迟对系统性能没有太大影响(即您还应该考虑延迟分布,高百分位等等.)