Majordomo 经纪人：处理大量连接

Question

我正在以下列方式使用在此处 (https://github.com/zeromq/majordomo) 找到的 majordomo 代码：

我没有使用单个 broker 来处理请求和回复，而是启动了两个 brokers，这样其中一个处理所有请求，另一个处理所有回复。

我做了一些测试，看看 majordomo broker 可以处理多少个连接：

num of reqs per client     num of requests handled without pkt loss

          1                         614 (614 clients)
         10                        6000 (600 clients)
        100                       35500 (355 clients)
       1000                      300000 (300 clients)
       5000                      750000
      10000                      600000
      15000                      450000
      20000                      420000
      25000                      375000
      30000                      360000

我无法正确理解结果。

为什么代理只能处理 614 个客户端，而每个客户端只发送一个请求？

我在一台机器上运行了这个测试，但 614 似乎仍然很低。

谁能告诉我可能出了什么问题？

---

所以我将 HWM 设置如下：

Broker’s HWM on send/receive is set to  40 k.
TCP send/receive buffer      is set to  10 MB.
Worker’s HWM on send/receive is set to 100 k.
Client’s HWM on send         is set to 100,
         and on receive      is set to 100 k.
All the clients run on the same machine.
All the workers (10 workers running the echo service),
and the two broker instances run on a single ec2 instance.

Client program simply sends all the requests in a blast (all at once).

我对 HWM on send 的理解是，当到达 HWM 时，socket 会阻塞。这就是为什么我将客户端的 send HWM 设置为 100 条消息，希望这会给我某种流量控制。

现在，当我有 10 个客户端发送 10,000 个请求（一次完成）时，我看到数据包丢失。并且，当客户端每个发送 10,000 个请求，但一次只发送前 1000 个请求时，当 128 个客户端并行运行时会发生丢包。

当我将代理的 HWM 设置为 40k 时，为什么当爆炸大小小于 40,000 时它会丢弃数据包（就像我上面使用的那样）？我知道 zmq 指南说管道的分配容量约为我们设置的容量的 60%，但 10,000 只是我设置的容量 (40,000) 的 25%。同理，1000 只占 10%。所以我不明白是什么导致代理丢失数据包。 HWM 应该是每个对等连接，不是吗？请帮助我理解这种行为。

Answer 1

为什么会这样？

TLDR

让我引用一个奇妙而珍贵的资料——Pieter HINTJENS 的书

“代码连接，第 1 卷”

（绝对值得花任何时间阅读 PDF 副本...关键信息在 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 实现其队列的方式。

---

解决方案

尝试调整您的 RCVHWM / SNDHWM 和其他低级 IO 线程 / API 参数，以便您的测试设置保持内存占用根据您的IO-resources-incompressible-data-"hydraulics"

，可行、稳定且性能良好