Насколько медленны сокеты TCP по сравнению с именованными каналами в Windows для localhost IPC?

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

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

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

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

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

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

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

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

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

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

Ответ 1

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

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

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

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

Приветствия,

Ответ 4

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

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

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

Ответ 5

В чем причина наличия прокси на SAME машине, просто любопытно?

В любом случае:

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