3

代码描述：
我的代码很简单，它ZeroMQHandler从 Logbook 库（使用 pyzmq）启动一个（基于套接字的消息传递）。Logger（日志）在整个应用程序中运行。最后，处理程序关闭端口。.push()and.pop_application()方法代替了and
with handler.applicationbound():缩进。

目的：
我正在测试这个基于队列的消息传递，看看它是否可以成为低影响的异步日志记录解决方案。我需要每秒记录大约 15 000 条消息。我更喜欢使用 Python，但我的后备是用 C++ 编写记录器并将其句柄暴露给 python。

问题：
问题是，如果我在打开处理程序（套接字）后不等待四分之一秒或更长时间，程序将在没有任何消息通过的情况下执行（测试程序执行时间不到 0.25 秒）。我将此解释为 ZeroMQ 套接字或类似的东西所需的设置时间。所以我想看看是否有人有类似的经历，也许这在任何地方都有记录，但我自己似乎无法弄清楚。我想知道为什么需要这样做。感谢您的任何意见。

我的工作代码看起来像这样：

from logbook.queues import ZeroMQHandler
from logbook import Logger
import time

addr='tcp://127.0.0.1:5053'
handler = ZeroMQHandler(addr)
time.sleep(0.25) ################################################# THIS ! ####

log = Logger("myLogbook")
handler.push_application()

log.info("start of program")
foo()
log.info("end of program")

handler.close()
handler.pop_application()

接收器，在不同的 python 内核中运行（用于测试，向标准输出提供输出）：

from logbook.queues import ZeroMQSubscriber
from logbook import Logger, StreamHandler
import sys
import time
addr='tcp://127.0.0.1:5053'
print("ZeroMQSubscriber begin with address {}".format(addr))
subscriber = ZeroMQSubscriber(addr)
handler = StreamHandler(sys.stdout)

log = Logger("A receiver")
handler.push_application()


try:
    i=0
    while True:
        i += 1
        record = subscriber.recv(2)
        if not record:
            pass # timeout
        else:
            print("got message!")
            log.handle(record)
except KeyboardInterrupt:
    print("C-C caught, program end after {} iterations".format(i))    
handler.pop_application()
4

1 回答 1

1

ZeroMQ 确实花了一些时间来创建一个Context()实例本身，然后它要求 O/S 分配内存绑定资源，以产生 I/O 线程，这也需要一些额外的时间。接下来，每个Socket()实例化都会消耗一些附加开销时间。

在本机 API 文档和教育资源中都有很好的记录，异步信号/消息传递框架确实要花费一些时间，然后才能在“本地”和“远程”Context()实例中实际处理任何 API 请求并最终标记作为一些 ZeroMQ Scalable Formal Communication Archetype 的“远程”端可读的交付物。

这就是说，毫无疑问，对 ZeroMQ 工具进行更多重新包装的使用（由另一个抽象级别重新包装，编码到 logbook.queue.ZeroMQSubscriber, logbook.queue.ZeroMQHandler类中）只会增加额外的{设置和操作}开销，因此已知的异步性的服务只会增长。

如果您的应用程序需要任何两端之间的任何类型的相互重新确认它们已达到准备就绪状态（RTO-状态），那么最好的办法是引入某种智能协调策略，与其保持盲目的信念，不如依靠足够长的时间希望事情得到足够的时间安定下来并进入RTO。.sleep()

在中，总是最好是明确的，而不是保持乐观的希望。

结语：

鉴于您的持续吞吐量应该安全地低于并保持在每条消息发送的预期阈值之下<= 66 [us/message]，让我也对适当的Context()参数化感兴趣，以便在现实的硬件和系统范围的资源下确实顺利地承载您所需的工作负载规划。

默认值不是一成不变的，也不应该是一个值得依赖的点。

于 2018-03-28T13:15:41.077 回答