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

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

1 голос
/ 23 марта 2020

У меня есть барьерная реализация, использующая соединение 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 Ответ

1 голос
/ 23 марта 2020

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

Q : " Что такое хороший способ реализовать барьер с ZeroMQ ? "

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

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

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

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

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

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

...