Как эффективно отправлять отдельные сообщения с использованием ZMQ как в Python, так и в Stack Overflow
В настоящее время у меня есть функция PHP:
function sendLocalSocket($message, $port){
$context = new ZMQContext();
$socket = $context->getSocket(ZMQ::SOCKET_PUSH);
$socket->connect("tcp://127.0.0.1:$port");
$socket->send($message);
}
и функция Python:
def create_local_socket(port, pull=False):
context = zmq.Context()
if pull:
# for receiving socket messages
socket = context.socket(zmq.PULL)
socket.bind("tcp://127.0.0.1:%d" % port)
else:
# for sending socket messages
socket = context.socket(zmq.PUSH)
socket.connect("tcp://127.0.0.1:%d" % port)
return socket
который затем отправляет сообщение с create_local_socket(port).send_json()
К сожалению, любая из этих двух функций, вызываемых в быстрой последовательности, начинает резко зависать и замедлять работу остальной части моей системы.
Я думал о том, как сохранить сокеты открытыми для никогда не завершающегося скрипта Python, но, к сожалению, для PHP это вызывается после загрузки файла.
Проблема заключается в том, что эти функции вызываются произвольно — скрипт php использует один и тот же порт при каждой загрузке, но скрипт python использует разные порты (хотя есть повторное использование).
Я знаю, что php зависает, потому что слушатель Python ZMQ регистрирует current time - the time the file was uploaded что занимает все больше и больше времени, пока отставание загрузок не исчезнет. Я также знаю, что скрипт слушателя не зависает и занимает 0,2 секунды после регистрации получения файла. (но это фактически бэк-лог!)
Я чувствую, что ответ заключается в сохранении этих связей.
Попытка: $context = new ZMQContext(1, true); не помогло.
Решение
При каждом вызове одного из фрагментов кода генерируется другой Context()-Например, это скорее анти-паттерн для разумного использования ресурсов.
Небольшое прочтение о Zen-of-Zero скоро покажет основные причины, почему создание (полу) постоянного уровня сигнализации / обмена сообщениями — это путь, так как распределение / освобождение ресурсов всегда дорого, плюс остается так много незавершенных экземпляры скоро истощат любое количество доступных ресурсов.
Инструменты ZeroMQ далеко не используются как одноразовые. Эффективность идет рука об руку с минимизированными накладными расходами, связанными с ресурсами, поэтому, действительно, лучше всего перепроектировать специальное создание никогда не освобождаемых пулов ресурсов и вместо этого подготовить все необходимые инструменты, прежде чем они должны быть уже активными и готовыми для обслуживания дополнительных ресурсов. Специальный запрос.
Должна быть проведена надлежащая перефакторинг Продукта.
В то время как отчеты по документации Некоторым настойчивым способностям modus-operandi следует внимательно изучить его затраты / выгоды, прежде чем идти в этом направлении, поскольку Zen-of-Zero на самом деле рассматривает любой вид обмена довольно анти-паттерном для распределенная система Плюс предупреждает о методах проектирования:
Заметка
Важно помнить, что небрежное использование постоянных сокетов может исчерпать Доступные файлы-дескрипторы на машине.
function sendLocalSocket( $message, // IS to be get delivered
$port // WAS reported to be
){ // all the time the same
$context = new ZMQContext( 2, true ); // MAY try persistent CTX
$socket = $context->getSocket( ZMQ::SOCKET_PUSH,
"persistLoggerID" // MAY use persistent SOCK
);
$socket->connect( "tcp://127.0.0.1:$port" ); // MAY use less expensive TC
$socket->send( $message,
ZMQ::MODE_NOBLOCK // USE non-blocking mode
);
$socket->disconnect( "tcp://127.0.0.1:$port" ); // USE .disconnect()
}
Конечная нота
Качество, надежность и производительность любого приложения зависят от того, насколько хорошо язык и привязка ZeroMQ для конкретного языка могут уважать собственный API и отражать лучшие практики, разработанные для использования собственных DLL-сервисов. Любые «абстрагирующие» и / или «автоматизированные» шаги, которые уменьшают контроль дизайнера над областью действия и упорядочивают другие должные шаги на уровне нативного API, могут выглядеть удобными, но они также уменьшают возможности для разработки надежных и высокопроизводительных развертываний поскольку некоторые параметры настройки нативного API не должны быть принципиально доступны на уровне пользовательского приложения, после того как они были затенены абстракциями привязки ZeroMQ для конкретного языка.
Другие решения
Других решений пока нет …