代码说明:
我的代码很简单,它从日志库(使用pyzmq)启动一个ZeroMQHandler(基于套接字的消息传递)。记录器(日志)在整个应用程序中运行。最后,处理程序关闭端口。这里有.push().pop_application()方法,而不是
with handler.applicationbound():和缩进。
目的:
我正在测试这个基于队列的消息传递,看看它是否是一个低影响的异步日志记录解决方案。我需要每秒记录15000条消息。我更喜欢使用Python,但我的回退是用C++编写记录器,并将其句柄暴露给Python。
问题是:
问题是,如果我在打开处理程序(socket)后不等待四分之一秒或更长时间,程序将在没有任何消息通过的情况下执行(测试程序执行时间不到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内核中运行(对于测试,将输出给stdout):
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()

最佳答案

ZeroMQ本身确实花了一些时间来创建一个Context()-实例,然后要求O/S分配内存绑定资源,生成I/O线程,这也需要一些额外的时间。接下来,每个实例化都会消耗一些附加的开销时间。
在本机API文档和教育资源中都有很好的记录,异步信令/消息传递框架确实需要花费一些时间,才能在“本地”和“远程”实例中实际处理任何API请求,并最终标记为对ZeroMQ的某些“远程”端可读的可交付结果可伸缩的正式通信原型。
这就是说,毫不奇怪,使用ZeroMQ工具(由另一个抽象级别重新包装,编码到Socket()类中)进行更多的重新包装,只会增加额外的Context()设置和操作开销,因此服务的已知异步性只会增加。
如果您的应用程序需要在两端的任何一对之间相互确认它们已达到准备运行状态(RTO状态),最好是引入某种智能调节策略,而不是盲目地相信,依靠足够长的时间希望事情有足够的时间安定下来并进入实时操作系统。
distributed-system中,总有更好的明确,而不是保持乐观的希望。
后记:
考虑到您的持续吞吐量应该安全地低于并保持在每个发送的消息的预期阈值logbook.queue.ZeroMQSubscriber, logbook.queue.ZeroMQHandler以下,让我也提出一个适当的{参数化的兴趣,以便在实际的硬件和系统范围的资源规划下确实顺利地承载您所需的工作负载。
默认值不是一锤定音,也不应该成为一个值得依赖的点。

09-18 20:07