#zeromq #distributed-computing #low-latency
#zeromq #распределенные вычисления #низкая задержка
Вопрос:
У меня есть ROUTER
сокет в приложении, к которому подключаются несколько DEALER
сокетов в разных приложениях. Я бы хотел ROUTER
, чтобы он был как можно более надежным.
Вот конкретный сценарий, с которым я хотел бы хорошо справиться на ROUTER
:
- 1000
DEALER
подключений подключаются кROUTER
- Каждый
DEALER
отправляет запрос наROUTER
than, что приведет кROUTER
отправке большого ответа обратно наDEALER
- Вместо того, чтобы читать ответ,
DEALER
-ы немедленно повторяют второй шаг
Поведение, которое я вижу на ROUTER
: он создает тонну очень больших сообщений ZeroMQ для ответов, затем zmq отправляет обратно DEALER
. ZeroMQ становится ответственным за освобождение сообщений при их фактической отправке. Поскольку DEALER
-s никогда не вызываются recv()
, ZeroMQ хранит сообщение вечно, и память медленно «утекает», пока O / S не завершит процесс, когда у него закончится память.
Некоторые опции, которые я использовал, помогают :
ZMQ_SNDHWM
: ограничивает нас только хранением N-сообщений в нашей исходящей очереди для каждого DEALER
, хотя и не идеально, потому что a ROUTER
отбрасывает исходящие сообщения, когда очередь заполнена
ZMQ_SNDTIMEO
: ZeroMQ отбросит сообщение через N миллисекунд без успешной отправки
При указанных параметрах все еще возможно сбой ROUTER
, если открыты 1000 DEALER
подключений, поскольку для каждого клиента применяется максимальная отметка.
Есть ли какие-либо другие варианты, которые я мог бы использовать для защиты от сбоев клиентских запросов?
Ответ №1:
Вопрос: «Есть ли какие-либо другие варианты, которые я мог бы использовать для защиты от сбоев в клиентских запросах?»
Хотя настройка выходит за рамки моего воображения, зачем перемещать миллиарды байтов, чтобы никогда .recv()
их не использовать, позвольте мне предложить вам один трюк, чтобы уменьшить выделение памяти до рабочего минимума :
Мы можем использовать .setsockopt( zmq.CONFLATE )
трюк (используя диалект Python), чтобы не буферизировать что-либо еще, кроме одного, самого последнего входящего сообщения.