Скорость IPC и сравнить

Question

Я пытаюсь реализовать приложение в реальном времени, которое использует IPC для разных модулей. Модули выполняют некоторую интенсивную обработку данных. Я использую очередь сообщений в качестве основы (Activemq) для IPC в прототипе, что легко (учитывая, что я новичок в IPC), но очень и очень медленно.

Вот моя ситуация:

• Я выделил часть IPC, чтобы я мог изменить ее в будущем.
• У меня есть 3 недели, чтобы реализовать другую более быструю версию. ;-(
• IPC должен быть быстрым, но сравнительно легко подобрать

Я изучал различные подходы IPC: сокет, канал, разделяемая память. Тем не менее, у меня нет опыта работы с IPC, и я определенно не смогу провалить эту демонстрацию через 3 недели ... С какого IPC можно начать безопаснее?

Спасибо. Лилия

Answer 1

Сам сталкивался с подобным вопросом.

Мне показались полезными следующие страницы - Производительность IPC: Named Pipe против Socket (в частности) и Sockets против именованных каналов для локального IPC в Windows? .

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

Answer 2

Вы можете проверить это сообщение в блоге https://publicwork.wordpress.com/2016/07/17/endurox-vs-zeromq/

По сути, он сравнивает Enduro / X, который построен на очередях POSIX (очереди ядра IPC), с ZeroMQ, который может доставлять сообщения одновременно на несколько разных транспортных классов, в том числе tcp:// (сетевые сокеты), ipc://, inproc://, pgm:// и epgm:// для многоадресной рассылки.

Из графиков вы можете видеть, что в какой-то момент при больших пакетах данных Enduro / X, работающий в очередях, побеждает сокеты.

Обе системы работают нормально с ~ 400 000 сообщений в секунду, но с сообщениями 5 КБ, очереди ядра работают лучше.

(источник изображения: https://publicwork.wordpress.com/2016/07/17/endurox-vs-zeromq/)

---

UPDATE: Еще одно обновление в качестве ответа на приведенный ниже комментарий. Я снова запустил тест для запуска ZeroMQ на ipc://, см. Рисунок:

Как мы видим, ZeroMQ ipc:// лучше, но снова в некотором диапазоне Enduro / X показывает лучшие результаты, а затем снова ZeroMQ вступает во владение.

Таким образом, я могу сказать, что выбор IPC зависит от работы, которую вы планируете делать.

Обратите внимание, что ZeroMQ IPC работает на каналах POSIX. Пока Enduro / x работает в очередях POSIX.

Answer 3

В Windows вы можете использовать WM_COPYDATA, особый вид IPC на основе общей памяти. Это старый, но простой метод: «Процесс A» отправляет сообщение, которое содержит указатель на некоторые данные в его памяти, и ожидает, пока «Процесс B» обработает (извините) сообщение, например создает локальную копию данных. Этот метод довольно быстрый и работает и в Windows 8 Developer Preview (см. Мой тест ). Любые виды данных можно транспортировать таким образом, сериализовав их на отправителе и десериализовав их на стороне получателя. Также легко реализовать очереди сообщений отправителя и получателя, чтобы сделать связь асинхронной.

Answer 4

Наилучшие результаты вы получите с Shared Memory решением.

Недавно я встречался с тем же тестом IPC . И я думаю, что мои результаты будут полезны для всех, кто хочет сравнить производительность IPC.

Трубный эталон:

Message size:       128
Message count:      1000000
Total duration:     27367.454 ms
Average duration:   27.319 us
Minimum duration:   5.888 us
Maximum duration:   15763.712 us
Standard deviation: 26.664 us
Message rate:       36539 msg/s

Эталон FIFO (именованные каналы):

Message size:       128
Message count:      1000000
Total duration:     38100.093 ms
Average duration:   38.025 us
Minimum duration:   6.656 us
Maximum duration:   27415.040 us
Standard deviation: 91.614 us
Message rate:       26246 msg/s

Тест очереди сообщений:

Message size:       128
Message count:      1000000
Total duration:     14723.159 ms
Average duration:   14.675 us
Minimum duration:   3.840 us
Maximum duration:   17437.184 us
Standard deviation: 53.615 us
Message rate:       67920 msg/s

Тест общей памяти:

Message size:       128
Message count:      1000000
Total duration:     261.650 ms
Average duration:   0.238 us
Minimum duration:   0.000 us
Maximum duration:   10092.032 us
Standard deviation: 22.095 us
Message rate:       3821893 msg/s

Тест TCP-сокетов:

Message size:       128
Message count:      1000000
Total duration:     44477.257 ms
Average duration:   44.391 us
Minimum duration:   11.520 us
Maximum duration:   15863.296 us
Standard deviation: 44.905 us
Message rate:       22483 msg/s

Тест доменных сокетов Unix:

Message size:       128
Message count:      1000000
Total duration:     24579.846 ms
Average duration:   24.531 us
Minimum duration:   2.560 us
Maximum duration:   15932.928 us
Standard deviation: 37.854 us
Message rate:       40683 msg/s

Тест ZeroMQ:

Message size:       128
Message count:      1000000
Total duration:     64872.327 ms
Average duration:   64.808 us
Minimum duration:   23.552 us
Maximum duration:   16443.392 us
Standard deviation: 133.483 us
Message rate:       15414 msg/s