sockets - ZeroMQ 如何排队和发送排队的消息？

Question

我是一个 R 包 ( clustermq 0) 的作者，它使用 ZeroMQ 绑定(bind) ( rzmq ) 在 HPC 调度程序上分发函数调用。我使用了 REQ 的简单组合/REP套接字，工作人员首先请求所有任务的公共(public)数据(要调用的函数和常量参数)，然后是他们应该从主服务器评估的每个调用的数据。到目前为止，这运行良好，因为运行计算通常比发送和接收数据慢一个数量级。

然而，一个问题是公共(public)数据可能有数百 MB 大小，而迭代数据通常很小。因此，master 可能会忙于发送大量公共(public)数据而无法同时发送迭代数据。因此，启动分布式计算时会有明显的延迟。

但是，这可能不是由实际发送引起的，而是由准备消息引起的。 documentation状态:

ZeroMQ does not send the message (single or multipart) right away, but at some indeterminate later time.

所以我想知道:

ZeroMQ 是否发送了我们放入队列中的数据 send()一个接一个或并行？1 这会产生影响还是可能可以忽略不计？有没有办法影响这个？

据我了解，从 REP 切换至ROUTER这里不会改变任何东西。2 这是正确的吗？

如果它是串行的，我可能想将数据分成慢速和快速套接字

主要延迟是否可能是由之前发生的事情引起的，即复制大块内存来创建消息对象？3(我已经 serialize 只有一次)

在这种情况下，我想与 ZeroMQ message objects without copying 进行交互。

请注意，我正在从 ZeroMQ 的设计原理中寻找答案，而不是我可以进行基准测试的评论。

下面的一些说明:

0 这并不意味着以理论上最有效的方式实现，而是使用 rzmq 的函数。提供。目标是改进将所有内容存储在 NAS 上并从那里检索它的软件包(这是一个相当低的标准)。这是一个附带项目，我不是系统工程师(而且我不精通低级 ZeroMQ)。我正在对开销和真实世界(也就是我的实际工作)示例进行基准测试，但这还没有进入文档。

1 假设情况(TCP):一个 REP主人和 n REQ客户；一个 ROUTER主人和 n REQ客户； PUSH/ PULL作为替代方法。除了使用不同的套接字之外，还有其他方法可以与之交互(可能不是来自高级绑定(bind)，如 rzmq，但将我指向相关的低级文档也会有所帮助；我在用户指南中没有找到此信息)

2 我的意思是，如果我连接 REQ客户到 ROUTER主人，我自己管理信封(并且必须手动发送 id 和空帧)，但这不会改变 ZeroMQ 在后台使用的代码来发送消息。或者是吗？这是在哪里记录的？ (我在用户指南中找不到它)

3 对此的一个有效答案是，瓶颈是内存复制，用于在主线程中初始化消息，然后在单独的线程中将消息一个接一个地发送给一个客户端，而不是阻塞主线程(如果是这种情况，或者其他什么实际上发生在消息上)

Answer 1

1)显示零代码意味着任何答案可能只是在非常高的水平

尾注:

Note that I'm looking for an answer from the design rationale of ZeroMQ and not a comment that I can benchmark.

也没有帮助。

所以，让我们一点一点地开始:

ZeroMQ 是否发送... 一个接一个还是并行？

零MQ Context -instance 是回答这个问题的大师。这取决于您的代码如何实例化数据泵引擎。发布零代码后，没有人可以告诉您。

这会有所作为还是 它可能可以忽略不计吗？

确保它有所作为，一个很大的。

有没有办法影响这个？

是的，有几种方法可以影响这一点。取决于你的代码。取决于您宣传的 HPC/集群项目端到端架构。就我的经验而言，没有万能的万能法或任何便宜(或免费)的魔杖。最好为您的项目使用有关实时系统调度的深入知识库(以及基准测试、基准测试、基准测试——如果您想拒绝 Git 发布的关于卓越性能的 promise ，这个包应该在测试中实现并维持在实际部署中展示)。

切换来自 REP to ROUTER 这里不会改变任何东西。

这是一个混合部分。我一再主张避免在任何专业等级系统中天真地使用 REQ/REP , 因为它不可避免地陷入一个无法挽回的相互僵局的内在亲和力(可以阅读其他我的 posts, where this warning is quite often presented and explained in colourful details s )

它是否正确？

没有人会在不发布您的架构、实现原理和代码本身的情况下告诉您。 42正确与否？ 谁知道？!？ (当然，除了老鼠，也许还有马文。(所有相关的事实和细节都可以在 搭便车指南 中找到——这个想法是从那里借来的))

是主 延迟可能是由 之前发生的事情造成的，即复制大块内存来创建消息对象？ (我已经 serialize 只有一次)

答案(即使使用概率 View )100% 隐藏在您的代码中。零MQ Context ，如果配置得当，它本身不会增加任何明显的延迟。 ZeroMQ API 文档中详细记录了该过程，因此如果尝试编码 1kB、1 MB 或 “数百 MB” BLOB 到 .send() -方法，一个人应该很清楚以他/她自己的方式这样做的原因。

在这种情况下 我想与 ZeroMQ 交互消息对象 无需复制

好吧，这始终是如何在 ZeroMQ 中调度数据的首选方式。另请注意，零拷贝准则不包括操作系统内核 数据缓冲区操作，因此一个严肃的项目计划应该考虑到实际操作(量子纠缠作为零时间无限距离的无质量即时信号或隐形传态在我们当前的 O/S 内核中不起作用，所以宁愿忍受注意当前已知的硅和硬件原理)