Как использовать ZeroMQ для нескольких пар сервер-клиент?

Я реализую высокопроизводительный двусторонний протокол на C ++ 14, использующий многопоточность, и в настоящее время использую ZeroMQ в качестве сетевого уровня.

Приложение имеет следующую простую архитектуру:

  • Одна основная роль сервера,
  • Один главный клиент-роль,
  • И сервер, и клиент порождают фиксированное количество n потоков.
  • Все n параллельные параллельные пары потоков выполняют некоторую производительность и интенсивный обмен по взаимному, но исключительному протоколу, т.е. они выполняются n фиксированными парами и не должны смешивать / обмениваться какими-либо данными, кроме попарного фиксированного оппонента .

В моем текущем проекте используется один экземпляр ZeroMQ Context() как для server, так и для client, который используется всеми n-локальными потоками, и каждая соответствующая пара потоков _8 _ / _ 9_ создает _10 _ socket (я просто увеличиваю номер порта) в локальном общем контексте для связи.

Мой вопрос

Есть ли более разумный или более эффективный способ сделать это?

то есть: есть ли естественный способ использования ROUTERS и DEALERS, который может повысить производительность?

У меня нет большого опыта программирования сокетов, и при моем подходе количество сокетов масштабируется напрямую с помощью n (количество пар потоков клиент-сервер). Это может пойти на пару тысяч, и я не уверен, проблема это или нет.

Я контролирую как серверные, так и клиентские машины и исходный код, и у меня нет внешних ограничений, о которых мне нужно беспокоиться. Все, что меня волнует, - это производительность.

Я просмотрел все шаблоны здесь, но я не могу найти никого, который соответствовал бы случаю, когда пары клиент-сервер фиксированы, т.е. я не могу использовать балансировку нагрузки и тому подобное.


c++ performance zeromq low-latency c++14
person Fulnir    schedule 30.05.2016    source источник
comment
Некоторые вопросы: 1) Есть ли требования к задержке? 2) Можете ли вы гарантировать, что у вас есть тысячи смежных свободных портов? (или, другими словами, насколько вы контролируете машины, на которых это работает?) 3) Как вы узнаете, когда вам нужно создать больше потоков, это решение во время выполнения?   -  person David    schedule 30.05.2016
comment
Привет, Дэвид, спасибо за интерес. 1) Я не понимаю, что именно вы имеете в виду, но задержка определенно является приоритетом. 2) Да, я могу гарантировать, что 3) Да, это зависит от ввода в программу, сколько потоков порождено   -  person Fulnir    schedule 31.05.2016

Ответы (1)


arrow_upward
2
arrow_downward

Счастливый человек!

ZeroMQ - прекрасный и мощный инструмент для хорошо масштабируемого, с низкими накладными расходами, формального общения (поведенческого, да, имитирующего какое-то взаимное поведение сверстников: «Один спрашивает, другой отвечает» и др.) Узоры.

Ваш шаблон довольно прост, неограничен в поведении и ZMQ_PAIR может хорошо служить для этого.

Представление

Следует подробнее рассказать о количественной природе этого атрибута.

  • задержка между процессами [us]
  • след памяти тестируемой системы (SuT) [MB]
  • пиковый объем потока данных, который SuT может обработать [MB/s]

Советы по эффективности (если они количественно подтверждены наблюдаемыми данными о производительности)

  • может повысить производительность ввода-вывода за счет увеличения Context( nIOthreads ) при создании экземпляра

  • может точно настроить производительность ввода-вывода путем жесткого сопоставления отдельных thread# -> Context.IO-thread#, что полезно как для распределенной рабочей нагрузки, так и позволяет сохранять "отдельные" локальные хосты IOthread свободными / готовыми к более высокому уровню -приоритетная сигнализация и др. подобные нужды.

  • должен настроить ToS для конкретного приложения маркировку приоритетных типов трафика, чтобы разрешить расширенную обработку на сетевом уровне рядом с сегментами маршрута между client и server

  • если не хватает памяти (ZeroMQ - это не Zero-copy обработки TCP-протокола на уровне ядра операционной системы), можно попытаться перейти к младшей сестре ZeroMQ - автор Мартин СУСТРИК, соучредитель ZeroMQ - POSIX-совместимого nanomsg с аналогичной мотивацией и привлекательными показателями производительности. По крайней мере, об этом стоит знать.

Может ли ROUTER или DEALER повысить общую производительность?

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

Пока ваше официальное общение остается таким, как определено, никаких дополнительных наворотов не требуется.

Можно отметить один момент в ZMQ_PAIR архетипе, некоторые источники указывают, что это скорее экспериментальный архетип. Если ваше внутреннее чутье не делает вас, помимо наблюдений за SuT-тестированием, счастливым жить с этим, не возражайте против небольшого шага реинжиниринга, который сохранит вам всю свободу не- пре -подписавшееся поведение формального шаблона связи, имея под капотом «неэкспериментальные каналы» - просто замените соло ZMQ_PAIR парой ZMQ_PUSH + ZMQ_PULL и используйте сообщения только с билетом в один конец. Имея заявленный полный контроль над SuT -проектированием и реализацией, все это будет в вашей компетенции.

Как быстро я смогу ехать?

Опубликованы некоторые протоколы тестов производительности для ZeroMQ или nanomsg производительности / задержки для незагруженного сетевого транспорта через сегменты маршрута без трафика (конечно).

Если ваш SuT-дизайн стремится работать еще быстрее - скажем, при сквозных 800 нс, есть другие средства для достижения этого, но ваш дизайн должен будет следовать другой стратегии распределенных вычислений, чем обмен данными на основе сообщений, и бюджет вашего проекта должен быть скорректирован с учетом дополнительных расходов на необходимую инфраструктуру оборудования со сверхмалой задержкой.

Это может удивить, но определенно выполнимо и довольно привлекательно для систем, где сотни наносекунд являются обязательной целью в центре обработки данных Colocation.

person user3666197    schedule 30.05.2016
comment
Спасибо за развернутый ответ! В итоге, следуя вашим рекомендациям, я перешел к паттерну Pull / Push. Хотя никакой разницы в моих сроках. Но приятно знать, что я не пропустил ничего очевидного - person Fulnir; 01.06.2016