Разделить работу между несколькими опросами?
Моя текущая настройка для работы на стороне сервера выглядит следующим образом - у меня есть менеджер (с поллером), который ожидает входящих запросов на выполнение работы. Как только что-то получено, он создает работника (с отдельным поллером и отдельными портами / сокетами) для работы, и в дальнейшем работник общается напрямую с клиентом.
То, что я наблюдаю, что когда какой-то рабочий имеет интенсивный трафик, он несколько отключает менеджера - ReceiveReady События происходят со значительными задержками.
Документация NetMQ гласит: "Прием сообщений с помощью poller происходит медленнее, чем прямой вызов метода Receive для сокета. При обработке тысяч сообщений в секунду или более, poller может стать узким местом". Я настолько ниже этого предела (скажем, 100 сообщений подряд), но мне интересно, не приведет ли еще большее количество опрошенных в одной программе к снижению производительности.
Я предпочитаю иметь отдельные экземпляры, потому что код чище (разделение проблем), но, может быть, я иду против принципов ZeroMQ? Вопрос в том, насколько разумно использовать несколько программ опроса в одной программе? Или наоборот - несколько ли опрашивают друг друга по замыслу?
1 ответ
Профессиональный анализ системы может даже потребовать от вас запустить несколько Poller() экземпляры:
Дизайн системы основан на фактах и требованиях, а не на прислушивании к каким-то популярным мнениям.
Внедрите показатели производительности и оцените детали фактической реализации. Сравнение фактов с порогами - это решение, основанное на фактах.
Если не искать последние несколько сотен [ns], типичный сценарий может выглядеть следующим образом:
ваша основная логика в цикле ответа на события состоит в том, чтобы обрабатывать несколько классов интегрированных входов / выходов сигнализации / сообщений ZeroMQ, причем все в принципиально неблокирующем режиме, плюс ваш дизайн должен уделять определенное количество относительного внимания каждому такому классу.
Можно принять более высокие задержки между процессами для удаленной клавиатуры (запуск CLI-интерфейса "через" сеть, в то время как ваш цикл обработки событий должен соответствовать строгому требованию не пропускать "свежие" обновления из потока QUOTE Таким образом, нужно создать легкую логику в реальном времени-SCHEDULER, которая представит один высокоприоритетный Poller() для неблокирования (нулевое ожидание) - еще один с ~ 5 мс тестом на чтение "медленных"-каналов и еще один с 15 мс тестом на чтение основного канала потока данных. Если вы профилировали свои процедуры обработки событий, чтобы они не длились более 5 мс, в худшем случае вы все равно можете обрабатывать ТАТ в 25 мс, и ваш цикл обработки событий может обрабатывать системы с требованием иметь стабильный цикл цикла управления 40 Гц.
Отсутствие набора из нескольких "специализированных" опрашивающих не позволит получить этот уровень детерминизма планирования с легко выраженной основной логикой для интеграции в такие принципиально стабильные циклы управления.
QED
Я использую аналогичную конструкцию для управления разнородными распределенными системами для торговли на рынке FOREX, основанных на внешних предикторах AI/ML, где время транзакции поддерживается на уровне ~ 70 мс (сквозное TAT, от прибытия QUOTE до AI/ML рекомендованная инструкция-заказ XTO, которая была подана) правильно из-за необходимости соответствовать ограничениям в реальном времени требований планирования цикла управления.
Эпилог:
Если в документации что-то говорится о характеристиках опроса в диапазонах, превышающих 1 кГц, но ничего не говорится о длительности процесса обработки сигнала / сообщения, это плохо сказывается на людях. Первый шаг - измерение задержек процесса, затем анализ производительности. Все инструменты ZeroMQ предназначены для масштабирования, так же как и инфраструктура приложений - так что забудьте о любых примерах в формате SLOC, узким местом является не экземпляр поллера, а плохое использование приложением доступных компонентов ZeroMQ (учитывая, что был взят известный предел производительности) во внимание) - всегда можно увеличить общую доступную вычислительную мощность, ведь с ZeroMQ мы находимся в сфере распределенных систем со дня 0, не так ли?
Таким образом, в сжато разработанных + контролируемых + адаптивно масштабируемых системах удушья не будет.