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

Question

В руководстве по ZeroMQ есть следующее:

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

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

Вопрос:

• Является ли это "inproc -ness" одним, что делает его с низкой задержкой?

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

Answer 1

_{В случае, если кто-то никогда не работал с ZeroMQ,
здесь можно сначала посмотреть на "ZeroMQ Принципы менее чем за Пять секунд "
, прежде чем углубляться в подробности}

Q : это" inproc -ness ", что делает его малым временем ожидания?

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

1) inproc:// - транспортный класс - это не требующий стека, не требующий протоколов и чистый (таким образом, быстрый и почти нулевой) механизм отображения областей памяти RAM
и
также _{(как было задано во втором вопросе)}

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

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

Answer 2

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

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

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

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

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