Как интервал монитора может влиять на сетевой трафик ~ .1 [ГБ / с] в ZeroMQ? - PullRequest
Новая
       13

Как интервал монитора может влиять на сетевой трафик ~ .1 [ГБ / с] в ZeroMQ?

0 голосов
/ 16 мая 2018

Итак, у меня есть процесс, который управляет группой работников, использующих шаблон REQ/REP и PUB/SUB для каждой рабочей пчелы. Я установил интервал монитора на 250 [ms] и все работало нормально.

Когда я внедряю на сервер Windows и запускаю монитор ресурсов, объем сетевого трафика (записанных байтов) этим процессом узла превышает 64-100 [MB/s], и это не включает никаких реальных транзакций приложений пока нет, потому что трафик есть, независимо от того, запускаю я детей или нет, и он не уменьшается, когда дети выходят в сеть.

Подозревая настройку интервала, я играл с увеличением значения и замечал, что более высокие значения интервала (реже) приводят к уменьшению трафика, но стоимость этого заключается в том, что для обнаружения событий подключения / отключения требуется много времени .

Сейчас я еще не пытался сузить его до того, является ли это на самом деле паттерном REQ/REP или паттерном PUB/SUB, но я Любопытно, какую часть документации я пропустил, чтобы объяснить это поведение.

Вероятно, мы собираемся обменять ZeroMQ на пользу или GRPC в следующем выпуске, но у меня есть вопросы, на которые нужно ответить.

Мне кажется, я отметил все, что имеет отношение к операционной среде.

1 Ответ

0 голосов
/ 16 мая 2018

При развертывании на сервере Windows и запуске монитора ресурсов объем сетевого трафика (записанных байтов) этим процессом узла превышает 64-100 [МБ / с]

Полагаю, вы уже хорошо понимаете, как низкоуровневые инструменты нативного API ZeroMQ на самом деле работают там, под капотом.Если нет, можете прочитать, как собственная реализация API в соответствии с вызовами zmq_socekt_monitor() сама устанавливает другой уровень трубопроводов и трубопроводов ZeroMQ, чтобы иметь возможность контролировать свои собственные действия (events et al)и выясните, насколько хорошо Windows (нативная или виртуализированная платформа) справляется с использованием настройки inproc:// -каналов среди пула Context() -instance (-ов).(s) и упомянутая группа пчел.Попробуйте настроить количество потоков ввода-вывода и, возможно, лучше сопоставить ZMQ_AFFINITY другим способом, чтобы разделить рабочие нагрузки " background "

...
Каждый вызов этого метода создает сокет ZMQ_PAIR и связывает его с указанной конечной точкой inproc://.Чтобы собрать события сокета, вы должны создать свой собственный сокет ZMQ_PAIR и подключить его к конечной точке.

Аргумент events является битовой маской событий сокета, которые вы хотите отслеживать, см. Поддерживаемые события ниже.Для отслеживания всех событий используйте значение события ZMQ_EVENT_ALL.

Каждое событие отправляется в виде двух кадров.Первый кадр содержит номер события (16 бит) и значение события (32 бита), который предоставляет дополнительные данные в соответствии с номером события.Второй кадр содержит строку, которая указывает затронутую TCP или IPC конечную точку.

Это мой подозреваемый #1 для корня-причины наблюдения ~ 100[MB/s] трафика @ 250 [ms] частоты вращения педалей, как сообщалось выше (без MCVE, как вы объяснили выше).

Включение всех возможных событий (встадо) может действительно генерировать некоторый объем трафика, поскольку каждое событие FSA сообщает о цветном состоянии с момента его запуска, независимо от предполагаемого состояния PUB/SUB + REQ/REP масштабируемых шаблонов формальных коммуникационных архетипов, охватывающего весь предполагаемый жизненный цикл подключения инфраструктуры ZeroMQ, распространяя каждый такой настроенныйотслеживаемое событие во время любой из { setup | operations | termination | release} -фаз: 

{ ZMQ_EVENT_CONNECTED,
  ZMQ_EVENT_CONNECT_DELAYED,
  ZMQ_EVENT_CONNECT_RETRIED,
  ZMQ_EVENT_LISTENING,
  ZMQ_EVENT_BIND_FAILED,
  ZMQ_EVENT_ACCEPTED,
  ZMQ_EVENT_ACCEPT_FAILED,
  ZMQ_EVENT_CLOSED,
  ZMQ_EVENT_CLOSE_FAILED,
  ZMQ_EVENT_DISCONNECTED,
  ZMQ_EVENT_MONITOR_STOPPED
  }

, поэтому поток данных еще до появления первой намеченной инфраструктуры ZeroMQ .connect().

Эпилог:

В случае, если на сетевых уровнях L3 + также сообщается о потоках [GB/s], эксперты SIGINT могут лучшеискать должной осмотрительности и разъяснений от поставщика (ов) платформы, что стояло за практикой самоотчетности такой платформы (если даже не секретный класс), которая может объяснить, конечно - лучше прекратить, такие замечательные данные о выходе сети -потоки. Кто-то осмелился сказать, что платформа могла быть взломана? Ну, надеюсь, это не так.

...