Majordomo经纪人:处理大量连接

时间:2015-01-24 00:07:43

标签: zeromq distributed distributed-computing

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

我没有使用单个 代理 来处理请求和回复,而是启动了两个 代理 ,以便其中一个处理所有请求,另一个处理所有回复。

我做了一些测试,看看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个请求(一次性全部)时,我看到数据包丢失。并且,当客户端每次发送10,000个请求,但只有前1000个请求一次发送时,则当128个客户端并行运行时会发生丢包。

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

1 个答案:

答案 0 :(得分:1)

为什么会这样?

  

TLDR

让我引用一个奇妙而珍贵的资料来源 - 彼得·辛辛斯的书

  

代码已连接,第1卷

(绝对值得花费任何时间并逐步浏览PDF副本......关键信息在Pieter制作成300多页惊心动魄页面的文本和故事中)


高水位赛

当您可以从一个过程快速地发送消息时,您很快就会发现内存是一种宝贵的资源,并且可以轻易填满。除非您了解问题并采取预防措施,否则在进程中的某个地方延迟几秒钟可能会变成导致服务器崩溃的积压。

...

ØMQ使用 HWM (高水位线)的概念来定义其内部管道的容量。套接字或套接字中的每个连接都有自己的管道, HWM 用于发送和/或接收,具体取决于套接字类型。某些套接字( PUB PUSH )只有发送缓冲区。一些( SUB PULL REQ REP < / strong>)只有接收缓冲区。一些( DEALER ROUTER PAIR )同时拥有发送和接收缓冲区。

在ØMQv2.x中, HWM 默认为无限。很容易,但通常也是对于大批量发布商而言,这是致命的。在ØMQ v3.x中,默认情况下设置为1,000,这样更明智。如果您仍在使用ØMQv2.x,则应始终在套接字上设置HWM,为了匹配ØMQv3.x或其他数字,考虑到您的邮件大小和预期的用户表现。

当套接字到达HWM时,它将阻止或丢弃数据,具体取决于套接字类型。 PUB ROUTER 套接字会在 HWM 时删除数据 strong>,而其他套接字类型将阻止。在inproc传输中,发送方和接收方共享相同的缓冲区,因此实际HWM是双方设置的HWM的总和。

最后, HWM -s并不准确;虽然默认情况下您最多可以获得1,000条消息,但由于 libzmq 实现其队列的方式,实际缓冲区大小可能会低得多(只有一半)。


尝试调整 RCVHWM / SNDHWM 以及其他低级IO线程/ API参数,以便您的测试设置仍然存在内存占用可行,稳定且性能良好,符合您的 IO资源 - 不可压缩数据 - “液压”