【问题标题】:Trying to understand Redis ping latency test vs Ping command Latency Test试图了解 Redis ping 延迟测试与 Ping 命令延迟测试
【发布时间】:2018-09-19 20:06:22
【问题描述】:

我试图了解延迟与最大数量或每秒可以服务的请求数。

我所理解的 RTT 是消息到达目的地并确认返回源所花费的时间。所以我假设服务器每秒只能处理最大请求数,不应该超过一秒内平均往返的总和。我的本地 ping 测试显示为

> ping 127.0.0.1 
rtt min/avg/max/mdev = 0.089/0.098/0.120/0.012 ms

仅网络往返平均需要 0.098 毫秒,这意味着 10 ping req/ms。所以我假设按顺序,客户端最多只能执行 10_000 req/sec。事实证明我错了。 redis-benchmark 工具显示了一些不同的东西。

> redis-benchmark -t set -c 1 -h 127.0.0.1
====== SET ======
  100000 requests completed in 2.53 seconds
  1 parallel clients
  3 bytes payload
  keep alive: 1

100.00% <= 1 milliseconds
39588.28 requests per second

单个客户端能够执行 39 个请求/毫秒,而我预计最大值为 10 个请求/毫秒。

谁能帮我在哪里出错或误解?

【问题讨论】:

    标签: redis ping latency


    【解决方案1】:

    即使使用单个逻辑客户端线程,命令也可以流水线化,这意味着:您可以在第一个响应返回之前发送 很多 个请求。响应总是按请求顺序返回(除非您使用 pub/sub),因此流水线客户端只需保留尚未看到响应的已发送消息队列,并在请求到达时将响应与请求配对。

    所以:您不受延迟的严格限制,尽管这仍然是一个有用的数字。原始吞吐量数(受带宽和服务器容量限制)有意义,因为您经常需要发出多个命令。

    【讨论】:

    • 管道是有意义的,但根据 redis 文档,默认情况下没有启用管道。所以结果仍然不能令人信服。我还缺少什么吗?
    • @cJ_ 很公平;由于环回快捷方式等原因,ping 在与 127.0.0.1 通话时可能根本不可靠?
    猜你喜欢
    • 1970-01-01
    • 2019-09-16
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-03-27
    • 2011-02-01
    • 2014-12-22
    相关资源
    最近更新 更多