多个轮询器之间的拆分工作？

Question

我目前在服务器端工作的设置是这样的 - 我有一个经理（带有轮询器）等待传入的工作请求。收到某些内容后，它会为作业创建工作者（具有单独的轮询器和单独的端口/套接字），并且工作人员可以直接与客户端进行通信。

我观察到，当任何工作人员出现密集交通时，它会稍微禁用经理 - ReceiveReady事件会因严重延误而被解雇。

NetMQ documentation状态＆＃34;使用轮询器接收消息比直接调用套接字上的Receive方法要慢。当处理数千条消息时，第二个或更多消息可能成为瓶颈。＆＃34;我远远低于这个限制（连续说100条消息），但我想知道在单个程序中有多个轮询器是否会进一步削减性能。

我更喜欢单独的实例，因为代码更清晰（关注点分离），但是我可能违反了ZeroMQ的原则？ 问题是 - 在单个程序性能方面使用多个轮询器吗？或者相反 - 多个投影机是否通过设计相互挨饿？

Answer 1

专业系统分析甚至可能要求您运行多个Poller()实例：

基于事实和要求的设计系统，而不是倾听一些普及的意见。

实施性能基准并测量有关实际实施的详细信息。比较事实与阈值是a.k.a.a Fact-Based-Decision。

如果不追求最后几百[ns]，典型情况可能会这样：

事件响应循环中的核心逻辑是处理几类ZeroMQ集成的signallin /消息传递输入/输出，所有这些都处于主要非阻塞模式，而且你的设计必须花费特定数量的相对注意力来处理每个这样的类。

远程键盘可以接受一些更高的进程间延迟（在网络上运行CLI接口，而您的事件循环必须满足严格要求，不要错过任何“新”更新QUOTE-stream。所以必须创建一个轻量级的Real-Time-SCHEDULER逻辑，它将为非阻塞（零等待）引入一个高优先级Poller()，另一个用~5 ms测试读取“慢”通道和另一个通过15 ms测试读取主数据流管道。如果你已经描述了事件处理例程，最坏情况不超过5毫秒，你仍然可以处理25毫秒的TAT并且您的事件循环可以处理需要具有40 Hz的稳定控制循环周期的系统。

不使用一组几个“专用”轮询器将不允许人们通过易于表达的核心逻辑来获得这种级别的调度确定性，以便集成在这种主要稳定的控制循环中。

Q.E.D。

_{我使用类似的设计，以便基于外部AI / ML预测器驱动异构分布式系统进行外汇交易，其中交易时间保持在约70毫秒（端到端TAT，来自报价单）由于需要匹配控制环调度要求的实时约束，所以到达AI / ML建议XTO订单指令正在提交。}

尾声：

如果文档中提到了关于轮询器性能的信息，在1 kHz以上的信号传输范围内，但没有提及信号/消息处理过程的持续时间，那么它对公众的服务很差。 要采取的第一步是测量过程延迟，然后分析性能包络。所有ZeroMQ工具都是为扩展而设计的，因此应用程序基础架构也是如此 - 所以忘记任何SLOC大小的示例，瓶颈不是轮询器实例，而是可用ZeroMQ组件的应用程序使用不当（假设已知性能包络）考虑到 - 一个人可以随时增加可用的整体处理能力，ZeroMQ我们从第0天开始就处于分布式系统领域，不是吗？

因此，在简洁设计+监控+自适应缩放系统中不会出现窒息。