Как можно настроить TCP для высокопроизводительной односторонней передачи? - PullRequest
2 голосов
/ 01 марта 2011

мой (сетевой) клиент отправляет пакеты данных размером от 50 до 100 КБ каждые 200 мс на мой сервер. там до 300 клиентов. Сервер ничего не отправляет клиенту. Сервер (выделенный) и клиенты находятся в локальной сети. Как я могу настроить конфигурацию TCP для лучшей производительности? Сервер на Windows Server 2003 или 2008, клиенты на Windows 2000 и выше.

например. Размер окна TCP. Помогает ли изменение этого параметра? что-нибудь еще? какие-либо специальные опции сокета?

[РЕДАКТИРОВАТЬ]: на самом деле в разных режимах пакеты могут быть до 5 МБ

Ответы [ 3 ]

5 голосов
/ 01 марта 2011

Я провел исследование по этому вопросу пару лет назад с 1700 точками данных. Был сделан вывод, что единственное лучшее, что вы можете сделать, - это настроить огромный приемный буфер сокета (например, 512 КБ) на приемнике. Сделайте это с прослушивающим сокетом, чтобы он был унаследован принятыми сокетами, так что он уже будет установлен, пока они выполняют рукопожатие. Это, в свою очередь, позволяет согласовывать масштабирование окна TCP во время рукопожатия, что позволяет клиенту знать о размере окна> 64 КБ. Огромный размер окна, в основном, позволяет клиенту передавать данные с максимально возможной скоростью, при условии, что они будут предотвращать перегрузку, а не закрывать окна приема.

1 голос
/ 01 марта 2011

Поскольку все клиенты находятся в локальной сети, вы можете попытаться включить «jumbo frames» (для этого нужно выполнить команду netsh, для точной команды нужно будет зайти в Google, но есть множество инструкций).

На прикладном уровне вы можете использовать TransmitFile, который является эквивалентом sendfile для Windows и который очень хорошо работает под Windows Server 2003 (он искусственно ограничен по скорости в «non server», но это не будет проблемой для вы). Обратите внимание, что вы можете использовать отображенный в память файл, если генерируете данные на лету.

Что касается параметров настройки, увеличение буфера отправки, скорее всего, не принесет вам никакой пользы, хотя увеличение буфера receive может в некоторых случаях помочь, поскольку снижает вероятность потери пакетов, если приложение-получатель делает это. не обрабатывать поступающие данные достаточно быстро. Может помочь более крупный размер окна TCP (параметр реестра), поскольку это позволяет отправителю отправлять больше данных, прежде чем они будут заблокированы до получения ACK.

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

1 голос
/ 01 марта 2011

Какая ОС?IPv4 или v6?Почему такая большая свалка;почему он не может быть разбит на части?

При условии стабильной, стабильной и низкой пропускной способности: запаздывание, вы можете настроить такие параметры, как размеры в полете, начальный размер окна, mtu (в зависимости от данных, версии IP иmode [tcp / udp].

Вы также можете округлить входные данные robin или балансировки, чтобы у вас было меньше времени прерывания от nic. Привязка также возможна ..

5MB / пакет/? Это довольно плохой дизайн. Я думаю, что это приведет к большому количеству ретрансляций сегментов и большому количеству записей ядра / стека, используемых при реконструкции / ретрансляции последовательностей (время ожидания и т. Д.) ..

(Это вообще возможно?)

...