В ZeroMQ inproc + PAIR быстрее, чем inproc?

В руководстве для ZeroMQ есть это:

Если вы используете inproc и пары сокетов, вы создаете тесно связанное приложение, то есть такое, в котором ваши потоки структурно взаимозависимы. Делайте это, когда низкая задержка действительно жизненно важна.

Меня очень волнует задержка для моего приложения.

Вопрос:

  • Только ли «inproc-ness» делает его малой задержкой?

  • Или есть что-то особенное в "inproc + PAIR", которое работает быстрее, чем inproc + "WHATEVER"?


performance zeromq pyzmq low-latency
person Colin    schedule 28.10.2019    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Если кто-то никогда не работал с ZeroMQ,
здесь можно сначала ознакомиться с ZeroMQ Принципы менее чем за пять секунд< /a>"
прежде чем углубляться в подробности

Вопрос : только ли "inproc-есть" делает его малой задержкой?

Да, <под> . . . как bazza уже вчера сказал в целом, позвольте мне добавить несколько центов:

1) inproc://-транспортный класс — это бесстековый, не протокольный и чистый (таким образом, быстрый и почти с нулевой задержкой) Средство сопоставления областей памяти RAM
и
также(как было задано во втором вопросе)

В : Или есть что-то особенное в "inproc + PAIR", которое быстрее, чем inproc + "WHATEVER"?

2) PAIR/PAIR-Scalable-Formal-Communication-Pattern архетип не добавляет ничего лишнего, связанного с архетипом Pattern , многостороннее поведенческое-рукопожатие (по сравнению с некоторыми другими распределенными автоматами с конечными состояниями (выражающими состояния и переходы шаблона архетипа поведения между всеми распределенные одноранговые узлы - не с PAIR/PAIR эксклюзивным цифровым пожарным шлангом 1-на-1 ), поэтому здесь ничего не добавляется, кроме поточно-ориентированной механики локальных указателей с обеих сторон плюс некоторая сигнализация Context() экземпляра - кстати . возможно, вы заметили, что для приложения с чистым inproc://-транспортным классом вы можете создать экземпляр Context( 0 ) с нулевыми потоками ввода-вывода, как в этих случаях Context()-сигнализация вообще не нуждается в них, так как она просто управляет трюками с указателями над областями памяти в локальной ОЗУ — так мило, не правда ли? )

person user3666197    schedule 29.10.2019

arrow_upward
0
arrow_downward

Незавершенность, безусловно, будет большой частью этого. Я предполагаю, что для транспорта inproc существует минимум взаимодействия с операционной системой; таким образом, с минимальными накладными расходами ОС (передача сообщений, вероятно, немного больше, чем у memcpy, и, возможно, один или два семафора или что-то подобное) это так быстро, как может быть.

По сравнению с другими транспортами, ipc, tcp и т. д.; все они проникают в части ОС, над которыми проделана большая работа. Например, ipc (каналы) включает копирование из исходного буфера в буфер ОС, а затем обратное копирование из него в буфер назначения, а также все переходы от пользователя к контексту выполнения ОС, и их больше, если сообщения > 4 КБ (или любой размер системной страницы). С транспортом inproc переходов нет (может быть, один или два для семафоров) и, возможно, на один memcpy меньше. Точно так же изучение стека tcp требует большой вариативности.

PAIR также имеет минимальную сложность и накладные расходы для шаблона распределения. Строго один в один, не более. Так что это тоже мало накладных расходов. Это мое прочтение этого раздела Руководства, которые вы уже встречали. В PUB/SUB и т. д. происходит больше, чем необходимо для связи один-два-один.

Минимум взаимодействия с ОС и сложность в сочетании с минимальными задержками. Минимальное взаимодействие с ОС также на некоторых платформах поможет поддерживать постоянную задержку.

Я не очень хорошо разбираюсь во внутренностях ZeroMQ, но есть большая вероятность, что inproc+PAIR поверх ОС реального времени дает очень хорошую согласованность в задержке. Часто постоянство задержки имеет такое же значение, как и ее краткость.

person bazza    schedule 28.10.2019