Вопрос по performance, sockets, windows, named-pipes – Насколько медленны сокеты TCP по сравнению с именованными каналами в Windows для локального IPC?

36

Я разрабатываю TCP Proxy, который будет размещен перед службой TCP, которая должна обрабатывать от 500 до 1000 активных подключений из дикого Интернета.

Прокси-сервер работает на той же машине, что и служба, и в основном прозрачен. Служба по большей части не знает о прокси, единственным исключением является уведомление о реальном удаленном IP-адресе клиентов.

Это означает, что для каждого входящего открытого сокета TCP на сервере есть еще два сокета: второй из пары в прокси и один в реальной службе за прокси.

Размеры окон send и recv на двух прокси-сокетах установлены в 1024 байта.

Как это влияет на производительность? Насколько медленна эта конфигурация? Должен ли я приложить некоторые усилия для изменения службы на использование именованных каналов (или другого механизма IPC), или сокет localhost TCP по большей части является эффективным IPC?

Слияние двух приложений не вариант. Прямо сейчас мы застряли в конфигурации двух процессов.

EDIT: Причиной наличия двух отдельных процессов на одном оборудовании является 100% экономия. У нас только один сервер, и мы не планируем получать больше (без денег).

Служба TCP является устаревшим программным обеспечением в Visual Basic 6, которое превзошло все наши ожидания. Прокси С ++. У нас нет ни времени, ни денег, ни рабочей силы, чтобы переписать и перенести код VB6 в современную среду программирования.

Прокси-сервер - это наша попытка уменьшить конкретную проблему с производительностью службы.DDoS-атака мы получаем время от времени.

Прокси с открытым исходным кодом,и вот исходный код проекта.

TCP-соединение в хосте будет реализовано настолько эффективно, насколько это возможно (читай: как двунаправленный локальный канал или что-то подобное этому) в любом современном сетевом стеке, который стоит его соли, поэтому я буду удивлен (и немного разочарован). в Microsoft), если была заметная разница в производительности между TCP и Named Pipes для этого варианта использования. Jeremy Friesner
@ JeremyFriesner Я согласен с вами, я хотел бы предположить, что это относится к «Windows Server 2008». vz0

Ваш Ответ

6   ответов
26

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

Для разрабатываемой нами утилиты у нас есть сетевой класс, который может использовать именованные каналы или TCP с одинаковыми вызовами.

Вот типичная обратная передача файлов в нашей тестовой системе:

Время передачи по TCP / IP: 2,5 секунды
Именованные каналы Время передачи: 3.1 секунды

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

Время передачи по TCP / IP: 12 секунд
Named Pipes Время передачи: 2,5 минуты (да!)

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

Как насчет обмена транзакциями с высокой степенью транзакции, например удаленных вызовов процедур? Трубы имеют заподлицо, а розетки - нет. Поэтому я предполагаю, что NP на порядок лучше на локальной машине.
Где находится указание на то, что «Именованные каналы на самом деле являются однотипными объектами, реализованными ядром через разделяемую память».
какой был размер файла? насколько большие, где пакеты? какие трубы / розетки? IOCP?
Комментарии к удаленным именованным каналам - красная сельдь для вопроса, который был о том же машинном сценарии. Именованные каналы на самом деле являются однотипными объектами, реализованными ядром через разделяемую память. Удаленные именованные каналы действительно являются "настоящими именованными каналами". + SMB + собственный протокол для отображения связи с конечными точками имен каналов через SMB. В этих дополнительных деталях могут происходить самые разные вещи, которые могут повлиять на производительность, которые не имеют ничего общего с «реальным». производительность именованной трубы.
1

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

Предполагается, что если загрузка процессора вашим сервером обычно ниже 50% или около того (с установленным прокси-сервером), не стоит беспокоиться о минимизации накладных расходов, связанных с локальными TCP-соединениями.

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

2

что эта тема очень старая, но она все еще актуальна для меня, и, возможно, другие будут смотреть на это и в будущем.

Я реализовал IPC между Excel (VBA) и другим процессом на одном компьютере, как через TCP-соединение, так и через Named Pipes.

В быстром тесте производительности я отправил сообщение, состоящее из 26 байтов, от клиента (Excel) на сервер (не в Excel) и ждал ответного сообщения от другого процесса (который в примере состоял из 12 байтов). Я выполнял это множество раз в цикле и измерял среднее время выполнения.

С TCP на локальном хосте (Windows 7, без fastpath), один "разговор" (запрос + ответ) заняло около 300-350 микросекунд. Особенно отправка данных была довольно медленной (отправка 26 байтов заняла около 200 микросекунд через TCP). При использовании Named Pipes один разговор занимал в среднем около 60 микросекунд - так намного быстрее.

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

TL: DR: В моем случае Named Pipes были примерно в 5-6 раз быстрее, чем TCP для небольших пакетов (еще не тестировали с более крупными)

... если вам действительно нужна наилучшая производительность, вам, вероятно, все равно следует использовать общую память. :-)
@HarryJohnston Действительно; в моем случае синхронный ввод / вывод (я думаю, что асинхронность не помогла бы в моем конкретном случае, не может использовать это в VBA). Например. Только 200 микросекунд было потрачено на вызов WinSock 's send' quot; функция. Что касается разделяемой памяти - согласитесь, я тоже пытался, но пока не смог сделать это правильно, пробовал с небольшими буферами, но имел некоторые странные эффекты, не уверен, что из-за отсутствия возможности энергозависимого чтения VBA ... но может вернись и попробуй это позже
Интересно, +1, но когда вы отправляете много маленьких пакетов, таких как эта, издержки (например, переходы ядра), вероятно, будут доминирующими - поэтому результат будет во многом зависеть от того, какие функции API вы используете, будь то Вы выбрали асинхронный или синхронный ввод-вывод и, возможно, внешние факторы, такие как то, какое антивирусное программное обеспечение установлено и установлено ли смягчение последствий Meltdown. Я думаю, суть в том, что каждый должен профилировать свой собственный сценарий.
0

Тем не мение:

Существует несколько методов IPC, TCP / IP, названные Pipes сопоставимы по скорости и сложности. Если вы действительно хотите что-то, что хорошо масштабируется и почти не имеет накладных расходов: используйте общую память. Лучше всего использовать в сочетании с алгоритмом без блокировки для продвижения указателей (или использовать один буфер для каждого считывателя (прокси / службы) и писателя (службы / прокси)).

Именованные каналы реализованыusing разделяемая память (MMF) в Windows, так что дело не в этом :)
Отредактированный вопрос. vz0
@ vz0: это цифры .. хорошо. Что говорит Дэн: если вы используете TCP / IP для IPC, вы также можете пересекать границы машин позже, когда это необходимо; в противном случае общий доступ к памяти является самым быстрым.
@STATUS_ACCESS_DENIED: Нет, это не так! У вас все еще есть накладные расходы на управление буфером памяти, переход к ядру и обратно для обоих процессов и используемой синхронизации. При использовании собственного буфера вы можете увеличиваться быстрее, особенно при использовании довольно маленьких сообщений (например, 100 байт и менее).
У нас только один сервер, мы не можем запускать программы на разных машинах. vz0
33

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

@ vz0: по моему опыту, брандмауэр Windows никогда не фильтрует пакеты, идущие на локальный хост. Например, вы можете запустить веб-сервер и использовать его на локальном компьютере без необходимости изменения правил брандмауэра.
Уверены в этом? У вас есть какие-либо ссылки? Я предполагаю, что петлевые соединения должны проходить через сетевой интерфейс и проходить через сетевой стек. Таким образом, они могут быть предметом правил фильтрации брандмауэра. Т.е., "если пакет SYN приходит с locahost на localhost через порт XYZ, отбросьте пакет". В Windows есть некоторый (скрытый) брандмауэр. vz0
@JeffTucker Вы все еще чувствуете, что Sockets - это путь? У меня возникли некоторые проблемы и буду признателен за ваши мысли. Посмотри пожалуйстаstackoverflow.com/questions/26653624/…
@JeffTucker Как ты думаешьthe socket loopback fast path влияет на производительность по сравнению с именованными каналами?
Мои ссылки на это то, что я работал на Microsoft в сети Windows. Тем не менее, межсетевой экран работает на уровне IP и выше, и я говорю о том, что winsock замыкает накоротко все, что ниже этого уровня. Нет никаких причин, по которым вы не могли бы применить правила брандмауэра к петле (кроме очевидного "зачем вам это надо?"). Вещи в петле все еще проходят через сетевой стек, но не весь сетевой стек, а оставшиеся издержки настолько незначительны, что они незначительны, если вы не выполняете это одновременно десятки тысяч раз.
2

http://msdn.microsoft.com/en-us/library/aa178138(v=sql.80).aspx

Позвольте мне подвести итог для вас. Если вы беспокоитесь о производительности, используйте TCP / IP. Но если у вас очень быстрая сеть, и вы не беспокоитесь о производительности, то Named Pipes будут "аккуратными". в том, что это может сэкономить вам некоторый код.

Не говоря уже о том, что если вы будете придерживаться протокола TCP, у вас будет что-то, что можно масштабировать и даже сбалансировать нагрузку, когда придет время.

Ура,

@ Дан, разве IPC не должен быть быстрее, чем TCP?
Благодарю. Тем не менее, в этой статье говорится о сокетах и именованных каналах по сети для IPC на разных компьютерах. Мои программы никогда не будут работать и не общаться друг с другом на отдельном оборудовании. vz0
Более подходящее обобщение связанной статьи MSDN выделило бы этот раздел: & quot; Если серверное приложение выполняется локально на компьютере, на котором запущен экземпляр Microsoft & # xAE; SQL Server & # x2122; 2000, локальный протокол именованных каналов является опцией. Локальные именованные каналы работают в режиме ядра и работают очень быстро. Именованные каналы работают быстрее, чем TCP / IP для IPC на той же машине.
Отредактированный вопрос. vz0
Может быть сейчас .. но, конечно, не было в случае с более ранними версиями Windows. Например, Vista, которая была моим основным источником информации.

Похожие вопросы