我正在使用pyzmq从DEALER向ROUTER发送20000条消息。
当我在每条消息之间暂停 0.0001 秒时，它们都会到达，但如果我通过每条消息暂停 0.00001 来加快发送速度 10 倍，则只有大约一半的消息到达。
是什么导致了问题？
【问题讨论】：
ZMQ IO 线程的默认设置 - 负责操作模式。
我敢说这是一个问题，如果您投入时间并深入研究出色的 ZMQ 概念和架构，就会越多。
自 ZMQ 库的早期版本以来，有一些重要的参数可以帮助核心杰作（IO 线程）保持稳定和可扩展和从而为您提供这个强大的框架。
零共享/零复制/（几乎）零延迟是不以零成本出现的格言。
ZMQ.Context 实例具有相当丰富的内部参数化，可以通过 API 方法进行修改。
让我引用一个奇妙而珍贵的来源——Pieter HINTJENS 的书，Code Connected, Volume 1。
( 绝对值得花时间仔细阅读 PDF 副本。C 语言代码 sn-ps 不会伤害任何人的 Python 心态，因为关键信息在 Pieter 精心制作的 300 多个文本和故事中激动人心的页面）。
高水位线
当您可以在进程之间快速发送消息时，您很快就会发现内存是一种宝贵的资源，而且可以很容易地被填满。除非您了解问题并采取预防措施，否则流程中某处的几秒钟延迟可能会导致积压导致服务器崩溃。
...
ØMQ 使用
HWM（高水位线）的概念来定义其内部管道的容量。每个从套接字出来或进入套接字的连接都有自己的管道，以及用于发送和/或接收的 HWM，具体取决于套接字类型。一些套接字（PUB、PUSH）只有发送缓冲区。有些（SUB、PULL、REQ、REP）只有接收缓冲区。一些（DEALER、ROUTER、PAIR）同时具有发送和接收缓冲区。在 ØMQ v2.x 中，
HWM默认是无限的。这很容易，但对于大容量出版商来说通常也是致命的。在 ØMQ v3.x 中，它默认设置为 1,000，这更明智。 如果您仍在使用 ØMQ v2.x，您应该始终在您的套接字上设置一个HWM，就这样吧1,000 以匹配 ØMQ v3.x 或考虑到您的消息大小和预期订阅者性能的其他数字。当您的套接字达到其 HWM 时，它将阻塞或丢弃数据，具体取决于套接字类型。
PUB和ROUTER套接字在到达HWM时将丢弃数据，而其他套接字类型将阻塞。在inproc传输上，发送方和接收方共享同一个缓冲区，所以真正的HWM是双方设置的HWM之和。最后，
HWM-s 不准确；虽然默认情况下您可能会收到多达 1,000 条消息，但由于libzmq实现其队列的方式，实际缓冲区大小可能要小得多（只有一半）。
【讨论】：
zmq.Stopwatch()。只需检查这个出色的测试和性能测量工具即可。
ROUTER 行为的描述已从 ØMQ -- version 2.2 更改。显然，只有PUB 会下降，所有其他人都会在到达HWM 时阻止。