我们看到ZeroMQ在 Windows 7 上发现奇怪且无法解释的现象，通过TCP发送消息。（或者 inproc ，因为ZeroMQ在Windows内部使用TCP进行信号传输。
现象是前500条消息越来越慢，延迟越来越慢。然后延迟下降并且消息一直快速到达，除了CPU /网络争用引起的峰值。
此处描述了此问题：https://github.com/zeromq/libzmq/issues/1608
始终是500条消息。如果我们发送没有延迟，那么消息被批处理，所以我们看到这个现象延伸了几千个发送。如果我们在发送之间延迟，我们会更清楚地看到图表。即使在发送之间延迟多达50-100毫秒也不会改变事情。
邮件大小也无关紧要。我已经测试了10字节消息和10K消息，结果相同。
最大延迟总是2毫秒（2,000 usec）。
在Linux机上我们没有看到这种现象。
我们想要做的是消除这条初始曲线，因此消息与正常的低延迟（大约20-100 usec）保持新的连接。
更新：此问题未在Windows 10和8上显示。在Windows 7 上似乎只发生 。
答案 0 :(得分：2)
我们找到了原因和解决方法。这是Windows 7上的所有TCP活动（至少）在接收器端缓冲引起的一般问题。您可以在“TCP慢启动”下找到一些提示。
在新连接上，或者如果连接空闲（我认为）150毫秒或更长时间，接收器缓冲传入的数据包，不将这些数据提供给应用程序，直到接收缓冲区为完全和/或一些超时到期（目前还不清楚）。
我们在ZeroMQ中使用TCP套接字进行线程间信令的工作方法是在新信号对上发送一个虚拟数据块。这会强制TCP堆栈“正常”工作，然后我们会看到大约100-150 usec的持续延迟。
我不确定这一般是否有用;对于大多数应用程序来说，等待一点接收是有利可图的，因此TCP堆栈可以为调用应用程序提供更多功能。
但是，对于发送许多小消息的应用，此解决方法可能会有所帮助。
请注意，如果连接处于空闲状态，则会再次发生慢启动，因此如果这很重要，连接应该每100毫秒左右心跳一次。