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毫秒等待状态）：

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是明智之举。无论如何，请记住，平均延迟对系统的性能并不重要（即，您还应该考虑延迟分布，高百分位等等。）

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

1 个答案: