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

Question

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

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

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

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

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

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

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

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

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

Прокси-сервер с открытым кодом, and here is the project source code.

Answer 1

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

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

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

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

Answer 2

Какова причина иметь прокси на одной машине, просто любопытным?

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

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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

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

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

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

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

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