我目前在服务器端的工作设置是这样的——我有一个经理（带有轮询器）等待传入的工作请求。一旦收到某些内容，它就会为该作业创建工作人员（具有单独的轮询器和单独的端口/套接字），然后工作人员直接与客户端通信。
我观察到，当任何工作人员的流量过大时，它会在一定程度上禁用管理器 -- ReceiveReady 事件会被触发，并有很大的延迟。
NetMQ documentation 声明“使用轮询器接收消息比直接在套接字上调用 Receive 方法要慢。当每秒处理数千条或更多消息时，轮询器可能成为瓶颈。”我远远低于这个限制（比如连续 100 条消息），但我想知道在单个程序中拥有多个轮询器是否不会进一步降低性能。
我更喜欢单独的实例，因为代码更简洁（关注点分离），但也许我违背了 ZeroMQ 的原则？ 问题是——在单个程序性能中使用多个轮询器是否明智？或者反过来——多个轮询器是否故意让彼此挨饿？
【问题讨论】：
Poller() 实例：根据事实和需求设计系统，而不是听取一些流行的意见。
实施性能基准并衡量有关实际实施的详细信息。将事实与阈值进行比较是一种基于事实的决策。
您在事件响应循环中的核心逻辑是处理几类 ZeroMQ 集成信号/消息输入/输出，所有这些都在主要是非阻塞模式下，而且您的设计必须花费特定数量的相对注意力到每一个这样的类。
对于远程键盘，可能会接受更高的进程间延迟（“跨”网络运行 CLI 接口，而您的事件循环必须满足严格要求，不能错过任何来自QUOTE-stream。所以必须创建一个轻量级的 Real-Time-SCHEDULER 逻辑，这将引入一个高优先级 Poller() 用于非阻塞（零等待），另一个具有约 5 毫秒的读取测试“慢”通道和另一个在读取主数据流管道时进行 15 毫秒测试的通道。如果您已将事件处理例程配置为在最坏情况下不超过 5 毫秒，您仍然可以处理 25 毫秒的 TAT 和您的事件循环可以处理需要稳定控制循环周期为 40 Hz 的系统。
不使用一组“专门的”轮询器将无法获得这种级别的调度确定性，并通过易于表达的核心逻辑集成到这种主要稳定的控制回路中。
我使用类似的设计来驱动基于外部 AI/ML 预测器的异构分布式系统进行外汇交易，其中交易时间保持在 ~ 70 毫秒（端到端 TAT，来自 QUOTE由于需要匹配控制回路调度要求的实时约束，到达 AI/ML 建议 XTO 订单指令正在提交。
如果文档说明了在 1 kHz 以上信号传递范围内的轮询器性能，但没有提及信号/消息处理过程的持续时间，那么它对公众的服务就很差。 第一步是测量进程延迟，然后分析性能包络。所有的 ZeroMQ 工具都是为扩展而设计的，应用程序基础设施也是如此——所以忘记任何 SLOC 大小的示例吧，瓶颈不是轮询器实例，而是应用程序对可用 ZeroMQ 组件的不良使用（给定一个已知的性能范围）考虑到）——人们总是可以增加可用的整体处理能力，使用 ZeroMQ，我们从第 0 天开始就处于分布式系统领域，不是吗？
因此，在设计简洁 + 监控 + 自适应缩放的系统中不会出现窒息现象。
【讨论】：