На загруженном † сервере Debian Lenny я рассматриваю возможность отключения Масштабирование окна TCP. Зачем?
Поэтому я спрашиваю себя "Действительно ли приставке требуется масштабирование окна TCP?" Прежде чем я даже попытаюсь поэкспериментировать и протестировать тесты, мне кажется разумным запросить настройки ServerFault.
Некоторые важные детали:
† = 3 Гбит / с сетевых адаптеров LACP + сотни миллионов HTTP-запросов + десятки терабайт трафика в месяц
"Действительно ли приставке нужно масштабирование окна TCP?"
Ну, вы действительно не сказали, что за коробка делает, так что на самом деле сложно сказать. А вообще, Масштабирование окна TCP имеет решающее значение для хорошей производительности конечных пользователей в современных соединениях WAN / Internet.. Это меньше требуется в локальной сети.
Снижается производительность сети? Задержки меня не беспокоят, а вот пропускная способность.
Это зависит от сетевых подключений ваших пользователей. Но если некоторые из ваших пользователей
... то без масштабирования окна эти пользователи смогут использовать лишь небольшую часть своей скорости соединения при загрузке от вас. Вот хорошее руководство по продукту с задержкой полосы пропускания и размерам окон - в комплекте с красивыми мультфильмами.
"Обеспечение высокопроизводительной передачи данных"- классический документ о масштабировании окна TCP. В нем правильно упоминается, что если вы используете последнее ядро Linux из серии 2.6, то обычно вам не нужно настраивать параметры TCP, потому что Linux теперь имеет агрессивную автонастройку эти. Здесь не упоминается, что Windows 2008+ также автоматически настраивает параметры TCP, используя составной TCP..
Обновить:
большие файлы отправляются с регулируемой скоростью передачи данных (~ 2 Мбит / с), клиенты находятся в Интернете и 90% в пределах 250 км
С этой обновленной информацией становится все сложнее. Поскольку вы ограничиваете максимальную скорость, возможно, окна TCP не являются ограничением в вашем случае. Посмотрите, какие соединения используют ваши конечные пользователи, и посчитайте. Вам не нужно запускать тесты производительности, вы можете рассчитать требуемый размер окна и сравнить его с фактическим размером окна передачи по умолчанию на вашем сервере.
Во многих случаях автоматическое регулирование TCP означает, что данная передача ограничена:
BW = windowsize / RTT
поскольку старые стандарты TCP ограничивали максимальный размер окна до 64 КБ, вы могли легко получить «длинную толстую сеть» (LFN, или «слоновую»), если бы эта цифра была ниже физической полосы пропускания. На помощь приходит масштабирование окон!
Чтобы проверить, нужно ли вам это, сделайте захват пакетов и проанализируйте RTT (не слишком полагайтесь на время пинга, у WireShark есть инструмент для этого на образце реального трафика). Средняя пропускная способность, которую пользователь увидит, если вы ее выключите, будет 64KB/RTT (в байтах / сек).
Снижается производительность сети?
Да, но только для передачи файлов размером больше RTTxBW. Но когда вы начинаете перемещать большие файлы по длинной толстой сети, производительность падает очень быстро.
Так что повлияет ли это на вас, будет зависеть от того, что вы обслуживаете (вы не сказали).