zeromq - Majordomo 经纪人 : handling large number of connections

Question

我按以下方式使用此处找到的主管代码 ( https://github.com/zeromq/majordomo ):

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

我做了一些测试，看看主管经纪人可以处理多少个连接:

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的理解是，当达到HWM时，套接字将阻塞。这就是为什么我将客户端的发送 HWM 设置为 100 条消息，希望这能给我某种流量控制。

现在，当我有 10 个客户端发送 10,000 个请求(全部一次性)时，我会看到数据包丢失。并且，当客户端每个发送10000个请求，但一次只发送前1000个请求时，128个客户端并行运行时就会出现丢包。

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

Answer 1

为什么会发生这种情况？

TLDR

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

"Code Connected, Volume 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-资源-不可压缩-数据-“液压”