Какой хороший способ реализовать барьер с ZeroMQ?

У меня есть реализация барьера, используя соединение PAIR/PAIR .

Серверная сторона отправит JSON-сообщение клиенту, а затем дождется, когда клиент отправит сообщение. Я отправлю 40000 сообщений в одном тесте и повторю это 10 раз, чтобы вычислить среднее использованное время.

pair_Server.py :

import zmq
import random
import sys
import time

context = zmq.Context()
socket = context.socket(zmq.PAIR)
socket.bind("tcp://*:5556")

totalTime = 0
for testCount in range(10):
    isFirstSend = True
    startTime = 0
    for num in range(40000):
        socket.send_json({ 'num' : num })
        if isFirstSend:
            isFirstSend = False
            startTime = time.time()
        msg = socket.recv_json()
    totalTime += (time.time() - startTime)
    print("Finish test {}".format(testCount))

print(totalTime / 10)

pair_Client.py :

import zmq
import random
import sys
import time

context = zmq.Context()
socket = context.socket(zmq.PAIR)
socket.connect("tcp://localhost:5556")

while True:
    msg = socket.recv_json()
    socket.send_json(msg)

Время вывода составляет около 4,3 секунды. Затем я снимаю барьер. Сервер теперь будет отправлять только JSON-сообщение клиенту и не нужно ждать ответа. После 10 раундов. Среднее время нахождения составляет 0,3 секунды.

Я понимаю, что скорость станет быстрее, но разница настолько велика, и я хотел бы спросить, если я использовал неправильную реализацию. Я пробовал сокеты PUSH/PULL для аналогичной реализации и получить аналогичный результат.

Всего 1 ответ



Если кто-то никогда не работал с ZeroMQ,
здесь можно с первого взгляда взглянуть на « Принципы ZeroMQ менее чем за пять секунд »
прежде чем углубляться в детали


В : «Как правильно создать барьер с помощью ZeroMQ

Лучший способ - реализовать ни один из них - с точки зрения производительности и задержки.

Код «как есть» не реализует барьер, он заставляет процесс на локальной стороне останавливать и оставаться в неограниченном состоянии ожидания для удаленного распределенного процесса, который получает ( если когда-либо ), обрабатывает его ( если когда-либо запускался, а также мы надеемся, что закончили ) и ответим, по крайней мере, некоторым ответом (здесь, если доставка когда-либо произойдет , по крайней мере, сообщение нулевой длины будет в порядке) - раньше - оно когда-либо продвинется на один шаг вперед.

Это довольно дикие и принципиально небезопасные предположения, не так ли?

Я бы никогда не принял код (не только для программного обеспечения производственного уровня), который сознательно примет себя за то, что стал причиной такого самопожертвования в такой почти неспособной спасти мамонтовой ловушке (вы сами потеряли контроль над своим кодом). выполнение и все устройство, на котором оно работает ... дает бесполезную жертву ... в зависимости от неуверенного внешнего совпадения факторов, которые полностью находятся вне вашей области контроля - возможно, но немного неудобно - вспомните Apollo-11 посадка на Луну ... плохой и ужасный поздний момент, чтобы ждать Ага, не так ли?)

Ваш « безбарьерный » код измеряет только цикл по нажатию одной кнопки (не дожидаясь, что на самом деле начинает делать каждое такое нажатие кнопки - будь то автоматическая пушка или толчок спутниковой камеры с дистанционным зондированием) кнопка, расположенная на самом деле в нескольких метрах над поверхностью астероида Рюгу, на расстоянии нескольких десятков световых минут от того, что вы услышите вашу первую кнопку - «нажатие» ...

Таким образом, фактический распределенный ( поведенческий ) протокол решает, что может стать возможным решением, а что нет.