Измерения средней производительности для локального IPC

Question

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

Отдельная допустимая опция - полностью исключить IPC (путем инкапсуляции функций одного из процессов в .NET DLL ииспользование другой), но это вариант, который мы действительно хотели бы избежать, так как эти две части программного обеспечения разрабатываются двумя отдельными компаниями, и мы считаем очень важным поддерживать хорошие «заборы», которые создают хороших соседей.

Наши тесты состояли в передаче сообщений (которые содержат BLOB-объекты различного размера) через границы процесса с использованием каждого метода.Вот цифры, которые мы получаем (диапазон производительности коррелирует с диапазоном размера сообщения):

• Веб-служба (SOAP через HTTP):
  • 25-30 МБ / с когда двоичные данные кодируются как Base64 (по умолчанию)
  • 70-100 МБ / с при использовании MTOM
• .NET Remoting (BinaryFormatterчерез TCP): 100-115 МБ / с
• Группа управления - вызов метода DLL + копия копии: 800-1000 МБ / с

Теперь мы искали повсюду некоторые средние показатели производительности для этих (и других) методов IPC, включая производительность необработанных петлевых сокетов TCP, но не смогли их найти.Эти цифры выглядят вменяемыми?Почему производительность этих локальных методов IPC как минимум в 10 раз ниже, чем при копировании памяти?Я не мог добиться лучших результатов, даже когда использовал необработанные сокеты - так велика нагрузка на TCP?

Answer 1

Общая память самая быстрая.

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

Answer 2

• Некоторые части нашей системы были переработаны, так что нам не нужно передавать 30 МБ сообщений, а скорее 3 МБ. Это позволило нам выбрать .NET Remoting с BinaryFormatter по именованным каналам (IpcChannel), что дает удовлетворительные результаты.

• Наш план действий на случай непредвиденных обстоятельств (на случай, если нам когда-нибудь понадобится передавать сообщения размером 30 МБ), заключается в том, чтобы вручную передавать сериализованные сообщения protobuf через именованные каналы. Мы определили, что это также обеспечивает удовлетворительные результаты.

Answer 3

Файлы с отображением в памяти + объекты синхронизации - правильный путь (почти такой же, как общая память, но с большим контролем) Сокеты слишком медленные для локальной связи. Особенно иногда случается, что сетевые драйверы медленнее с локальным хостом, чем по сети.