ZMQ Pub-Sub 延迟峰值

Question

我正在使用 ZMQ pub-sub 将消息从 C++ 程序传递到 Python 脚本。

我每秒传递大约 5000 条消息，它们的重量从 100 到 4500 字节不等，平均每条约 300 字节。 平均而言，我通过这个套接字每秒发送大约 2.5 兆字节的数据。

我的监控脚本是这样工作的：

• 将 C++ 程序绑定到套接字并使其运行。
• 为 C++ 程序发出的每条消息添加一个时间戳。
• 启动 python 脚本，连接到套接字，接收消息，获取时间戳并减去 output 时间戳，获取延迟测量值。
• 跟踪滚动 x 条消息的平均延迟。

我的问题：当我启动脚本时，套接字延迟徘徊在 200 微秒左右。 这在我的预料之内，而且似乎是正确的。 但是，1 分钟后平均延迟约为 1.5 毫秒，4 分钟后约为 10-15 毫秒，10 分钟后稳定在 50 毫秒左右。 如果我重新启动我的 Python 脚本，延迟会回到 200 微秒。 我不认为问题是消息积压，因为如果是这种情况，延迟会不断增加，偶尔也会减少，而不是以可预测的方式线性增加到某个阈值。

可能是什么问题？ 有没有办法更改 ZMQ 设置以尝试改进它，或者查看它是否有一些内部积压问题？

Answer 1

当您提到 50ms 时，我立即想到了 Nagle 算法。

但是，正如您所说的那样，您在双方都使用 ZMQ 并且默认情况下禁用 Nagle，那么我有点退缩了。

以下是调试的一些想法：

1. 使用strace <binary> args在 strace 下启动 C++ 进程并查看日志，尤其是在套接字创建之后的日志。 检查套接字上是否设置了TCP_NODELAY 。

2. 以管理员身份启动 wireshark 并在您发布的界面上进行捕获。 按照给定的 TCP stream并尝试检查明显的错误（例如重传）和模式。