在ZMQ Streamer设备上控制流的最佳实践?

时间:2019-07-16 19:00:59

标签: zeromq pyzmq

想象一下,我有一个波纹管模板中的流媒体设备。

Architechture

来自here的图片

def worker(backend_port):
    context = zmq.Context()
    socket = context.socket(zmq.PULL)
    socket.connect("tcp://127.0.0.1:%d" % backend_port)
    while True:
        task = socket.recv()
        # do something

def streamer(frontend_port):# it's called streamer because streams files from hdfs
    context = zmq.Context()
    socket = context.socket(zmq.PUSH)
    socket.connect("tcp://127.0.0.1:%d" % frontend_port)
    while True:
        #  get the file
        #  prepare it
        socket.send(msg, copy=False)

number_of_workers = 16
number_streamers = 10

frontend_port = 7559
backend_port = 7560

streamerdevice  = ProcessDevice(zmq.STREAMER, zmq.PULL, zmq.PUSH)
streamerdevice.bind_in("tcp://127.0.0.1:%d" % frontend_port )
streamerdevice.bind_out("tcp://127.0.0.1:%d" % backend_port)
streamerdevice.setsockopt_in(zmq.IDENTITY, b'PULL')
streamerdevice.setsockopt_out(zmq.IDENTITY, b'PUSH')
streamerdevice.start()

for i in range(number_of_workers):
    p = Process(target=yolo, args=(backend_port,))
    p.start()

for i in range(number_streamers):
    s = Process(target=streamer, args=(frontend_port,))
    s.start()

要提供更多信息,消息是图像,因此尺寸较大。我正在使用零副本。在我的案例中,性能是最重要的一点,因为我的规模很大。

  • 是否可以对streamerdevice进行多线程处理?

  • 如何控制流量?有没有办法知道有多少邮件正在等待处理?

  • 主要目标之一是使工作人员的接收时间尽可能快。有什么建议吗?

  • zmq.Context(nIoTHREADs)端启动nIoTHREADs> 1的worker有帮助吗?


1 个答案:

答案 0 :(得分:0)

  

如何运行多线程ZMQ设备?

运行多线程ZeroMQ服务的最简单方法是为zmq.Context( nIoTHREADs )实例化相应的 nIoTHREADs > 1 。有更多的性能调整配置选项可扩展性能。查看pyzmq包装器,此ZeroMQ工具如何应用于实际的pyzmq包装器代码,并询问维护者,它们的设置和/或配置是否保持不变或就此而言尚未发布。 ZeroMQ足够灵活,可以提供实现此目的的方法。

  

...设备(这是一种单向队列)随着您增加输入连接数而无法扩展

嗯,设备既不是单向队列,也不是可伸缩的。恰恰相反。

  

是否可以多线程方式运行它?

可以。

  

扩展它的最佳方法是什么?

这在很大程度上取决于系统设计应满足的确切消息传递和信令要求。高容量,超低延迟,几乎线性缩放,自适应连接处理,应用程序域用户定义的协议只是其中一些要考虑的属性。

  

是因为队列变大了,所以才变慢了吗?

该帖子包含零条信息,既没有关于大小的信息,也没有关于速度观察和/或期望的信息。在其他有文档记录的测试设置中,如果使用零拷贝和其他基于性能的方法,那么ZeroMQ在缓冲区管理方面非常可爱,因此没有人可以提供更详细的帮助。

  

有没有办法随时知道队列有多大?

不,没有这样的“内置”功能,这将花费时间和资源进行计数。如果您的系统中需要这种附加功能,则可以随意添加这种附加功能,而不必使其他用例仅用一些此类用例的附加代码,在这些用例中,消息计数和队列大小报告是没有意义的。

  

没有REQ-REP模式的设备是否有任何负载平衡策略?

是的,有很多现成的可扩展形式化通信原型模式,还有一些可能超出现成的双边分布式行为原型基元的场景,这些场景允许构建自定义的,按要求进行控制,自己的愿望和品味的负载均衡器。