У меня есть веб-сервер с текущим подключением на 100 Мбит, и мой провайдер предлагает обновление до 1 Гбит. Я понимаю, что это относится к пропускной способности, но чем больше пакеты, тем быстрее они могут быть переданы, поэтому я ожидал небольшого уменьшения времени отклика (например, ping). Кто-нибудь когда-нибудь тестировал это?
Пример (сервер от 100 до 100 Мбит) с загрузкой 30 байт:
> ping server -i0.05 -c200 -s30
[...]
200 packets transmitted, 200 received, 0% packet loss, time 9948ms
rtt min/avg/max/mdev = 0.093/0.164/0.960/0.093 ms
Пример (сервер от 100 до 100 Мбит) с загрузкой 300 байт (что меньше MTU):
> ping server -i0.05 -c200 -s300
[...]
200 packets transmitted, 200 received, 0% packet loss, time 10037ms
rtt min/avg/max/mdev = 0.235/0.395/0.841/0.078 ms
Так от 30 до 300 средн. латентность увеличивается с 0,164 до 0,395 - я ожидал, что это будет более медленное увеличение для соединения с 1 ГБ до 1 ГБ. Я даже ожидал бы, что от 100 Мбит до 1 Гбит будет быстрее, если соединение будет через коммутатор, который сначала ждет, пока не получит весь пакет.
Обновить: Внимательно прочтите комментарии к ответам! Соединение не насыщено, и я не думаю, что это увеличение скорости будет иметь значение для человека для одного запроса, но это касается многих запросов, которые складываются (Redis, Database и т. Д.).
Что касается ответа от @LatinSuD:
> ping server -i0.05 -c200 -s1400
200 packets transmitted, 200 received, 0% packet loss, time 9958ms
rtt min/avg/max/mdev = 0.662/0.866/1.557/0.110 ms
Единственный способ значительно снизить задержку - это если текущий канал 100 Мбит / с будет переполнен. Если он не насыщен, вы, скорее всего, не заметите никаких изменений.
Кроме того, ваше предположение о том, что канал 1 Гбит сможет поддерживать пакеты большего размера, неверно. Максимальный размер пакета определяется MTU различных устройств на пути, по которому идет пакет - начиная с сетевой карты на вашем сервере и заканчивая MTU на компьютере вашего клиента. Во внутренних приложениях локальной сети (когда у вас есть контроль над всеми устройствами на пути) иногда возможно увеличить MTU, но в этой ситуации вы в значительной степени застряли со значением MTU по умолчанию, равным 1500. Если вы отправляете пакеты размером более что в конечном итоге они будут фрагментированы, что фактически снизит производительность.
ДА Гбит имеет меньшую задержку, поскольку:
НО улучшение только заметный если пакет (ы) имеют определенный размер:
Итак, если у вас есть приложение, очень чувствителен к задержке (4 мс против 0,8 мс, двусторонний переход для 20 Кбайт) и требует передачи пакетов большего размера, чем переключение со 100 Мбит на Гбит может дать вам сокращение задержки, даже если вы используете в среднем намного меньше 100 Мбит / с (= ссылка не насыщается постоянно).
Сервер (100 Мбит) -> Коммутатор (Гбит) -> Сервер (100 Мбит):
size: 56 :: rtt min/avg/max/mdev = 0.124/0.176/0.627/0.052 ms
size: 100 :: rtt min/avg/max/mdev = 0.131/0.380/1.165/0.073 ms
size: 300 :: rtt min/avg/max/mdev = 0.311/0.463/2.387/0.115 ms
size: 800 :: rtt min/avg/max/mdev = 0.511/0.665/1.012/0.055 ms
size: 1000 :: rtt min/avg/max/mdev = 0.560/0.747/1.393/0.058 ms
size: 1200 :: rtt min/avg/max/mdev = 0.640/0.830/2.478/0.104 ms
size: 1492 :: rtt min/avg/max/mdev = 0.717/0.782/1.514/0.055 ms
size: 1800 :: rtt min/avg/max/mdev = 0.831/0.953/1.363/0.055 ms
size: 5000 :: rtt min/avg/max/mdev = 1.352/1.458/2.269/0.073 ms
size: 20000 :: rtt min/avg/max/mdev = 3.856/3.974/5.058/0.123 ms
Сервер (Гбит) -> Коммутатор (Гбит) -> Сервер (Гбит):
size: 56 :: rtt min/avg/max/mdev = 0.073/0.144/0.267/0.038 ms
size: 100 :: rtt min/avg/max/mdev = 0.129/0.501/0.630/0.074 ms
size: 300 :: rtt min/avg/max/mdev = 0.185/0.514/0.650/0.072 ms
size: 800 :: rtt min/avg/max/mdev = 0.201/0.583/0.792/0.079 ms
size: 1000 :: rtt min/avg/max/mdev = 0.204/0.609/0.748/0.078 ms
size: 1200 :: rtt min/avg/max/mdev = 0.220/0.621/0.746/0.080 ms
size: 1492 :: rtt min/avg/max/mdev = 0.256/0.343/0.487/0.043 ms
size: 1800 :: rtt min/avg/max/mdev = 0.311/0.672/0.815/0.079 ms
size: 5000 :: rtt min/avg/max/mdev = 0.347/0.556/0.803/0.048 ms
size: 20000 :: rtt min/avg/max/mdev = 0.620/0.813/1.222/0.122 ms
знак равно в среднем по нескольким серверам снижение задержки на 80% для пинга 20 КБ
(Если только одна из ссылок является гигабитной, у вас все равно будет снижение задержки на 5% для пинга на 20 КБ.)
Я думаю, у вас есть фундаментальное заблуждение о задержке и "скорости" полосы пропускания. Скорость - это функция пропускной способности и задержки. Например, рассмотрим доставку данных на DVD-дисках через всю страну за 3 дня. Сравните это с отправкой данных через Интернет. Интернет имеет соединение с гораздо меньшей задержкой, но для того, чтобы соответствовать «скорости» соединения с отправкой, вам нужно будет получать со скоростью 9,6 МБ в секунду (справочный пример из этого источника).
В вашем случае переход на более высокую пропускную способность позволит вам обслуживать больше одновременных пользователей, но не улучшит задержку для отдельного пользователя.
Вы смотрите на мир через дырочку. Действительный тест различий в задержке на разных скоростях будет между двумя идентичными сетевыми адаптерами, соединенными кабелем кросс-коммутации. Установите скорость вычисления сетевых адаптеров 10 МБ, 100 МБ и 1000 МБ. Это покажет, что практически нет разницы в задержке на разных скоростях. Все пакеты передаются с одинаковой скоростью передачи данных независимо от используемой максимальной пропускной способности. Как только вы добавите переключатели с сохранением и пересылкой кеширования, все изменится. Проверка задержки через коммутатор должна выполняться только с двумя подключениями к коммутатору. Любой другой трафик может повлиять на задержку вашего теста. Даже в этом случае коммутатор может выполнять пролистывание журналов, настраивать счетчики типов пакетов, обновлять внутренние часы и т. Д. Все может повлиять на задержку.
Да, переключение со 100 МБ на 1 ГБ может быть быстрее (меньшая задержка) из-за изменений оборудования, другого сетевого адаптера, другого коммутатора, другого драйвера. Я видел более значительные изменения задержки пинга из-за различий в драйверах, чем любые другие изменения; пропускная способность, переключатели, разгрузка сетевых карт и т. д.
Следующим по величине изменением станет коммутатор, в котором сквозное переключение будет значительно быстрее, чем при одноразовой передаче. Однако хорошо спроектированный переключатель накопления и перемотки вперед может обогнать сквозной переключатель по общим характеристикам при высокой нагрузке. На заре гигабитных коммутаторов я видел высокопроизводительные коммутаторы на объединительной плате 10 МБ с меньшей задержкой, чем дешевые гигабитные коммутаторы.
Ping-тесты практически не имеют отношения к анализу производительности при использовании Интернета. Это быстрые тесты, позволяющие получить приблизительное представление о том, что происходит на транспорте в момент теста. Производственное тестирование производительности намного сложнее, чем просто пинг. Высокопроизводительные коммутаторы относятся к компьютерам и при высокой нагрузке ведут себя иначе - изменяются задержки.
Наличие более медленного сетевого адаптера или сетевого адаптера, настроенного на более низкую скорость, на самом деле может помочь серверу с одновременными пакетами, регулируя ввод на сервер с помощью кеша коммутаторов. Одна повторная передача может свести на нет любое уменьшение задержки. Обычно важны уровни трафика от средней до высокой, а не отдельные тесты ping. например Старый медленный Sun Ultrasparc (более высокая задержка для одного пинга) превосходит новый дешевый гигабитный настольный компьютер, используемый в качестве сервера разработки, при нагрузке на полосу пропускания менее 70% 100 МБ. Настольный компьютер имеет более быструю сетевую карту gb, более быстрое соединение gb-gb, более быструю память, больше памяти, более быстрый диск и более быстрый процессор, но он не работает так хорошо, как настроенное оборудование / программное обеспечение серверного класса. Это не означает, что текущий настроенный сервер, на котором работает gb-gb, не быстрее старого оборудования и даже способен обрабатывать большие нагрузки с пропускной способностью. Просто вопрос «более высокой производительности» сложнее, чем вы, кажется, задаете.
Узнайте, использует ли ваш провайдер разные переключатели для соединений 100 МБ и 1 ГБ. Если они используют одну и ту же объединительную плату коммутатора, я бы заплатил только за увеличение, если уровни трафика превысили нижнюю полосу пропускания. В противном случае вы можете обнаружить, что через короткое время многие другие пользователи переключатся на гигабит, а несколько пользователей, оставшихся на старом коммутаторе, теперь имеют более высокую производительность - меньшую задержку при высоких нагрузках на коммутатор (общая нагрузка коммутатора, а не только на ваши серверы ).
Пример яблок и апельсинов: местный интернет-провайдер предоставил новый коммутатор для пакетных услуг, DSL и телефона. Изначально пользователи заметили повышение производительности. Система была перепродана. Теперь пользователи, которые остаются на старом коммутаторе, имеют более стабильную производительность. Поздней ночью пользователи новой системы работают быстрее. Вечером при высокой нагрузке старые клиенты коммутатора явно превосходят новую перегруженную систему.
Более низкая задержка не всегда коррелирует с более быстрой доставкой. Вы упоминаете MySQl в 20 запросах на обслуживание одной страницы. Этот трафик не должен находиться на том же сетевом адаптере, что и запросы страницы. Перемещение всего внутреннего трафика во внутреннюю сеть уменьшит количество коллизий и общее количество пакетов на исходящей сетевой карте и обеспечит больший выигрыш, чем выигрыш в задержке 0,04 мс для одного пакета. Уменьшите количество запросов на страницу, чтобы уменьшить задержку загрузки страницы. Сжимайте страницы, html, css, javascript, изображения, чтобы уменьшить время загрузки страницы. Эти три изменения дадут больший общий выигрыш, чем оплата неиспользуемой полосы пропускания для уменьшения задержки на 0,04 мс. Пинг должен длиться 24 часа и быть усредненным, чтобы увидеть реальное изменение задержки. Интеллектуальные коммутаторы теперь выполняют адаптивное регулирование типа RTSP с небольшим начальным увеличением полосы пропускания и регулированием больших передач. В зависимости от размеров вашей страницы (графика, большой html / css / javascript) вы можете увидеть начальные задержки / пропускную способность соединения намного ниже / выше, чем передача большой страницы или полных страниц. Если часть вашей страницы транслируется, вы можете увидеть резко разную производительность между страницей и потоком.
Предположим, 300-байтовые пакеты (если вы используете -s 300 на самом деле он был бы больше из-за заголовков).
300 bytes = 2400 bits
2400 bits / 100Mbit/sec = 0.024ms
0,024 мс - это приблизительно фактическое время, необходимое для отправки кадра (без учета времени доступа к среде и заголовков).
В последовательности пинг-понга потребуется вдвое больше времени (0,048 мс), плюс время, необходимое ОС для обработки запроса.
Для меня это означает, что ваша задержка на 90% вызвана несколькими накладными расходами. Я не уверен, заметите ли вы большую разницу с Gb. Вероятно, разница менее 1 мс не будет заметна на веб-сервере.
В любом случае, не могли бы вы попробовать с действительно большим пакетом, например 1400 байт?
Это зависит от типа коммутатора, к которому вы подключаетесь. У некоторых поставщиков (таких как Crisco ... я имею в виду Cisco) пакеты ICMP будут возвращаться в ЦП (кляп).
Вы можете найти лучший тест - выполнить тест хост-хост с использованием канала 100 Мбит / с и 1 Гбит / с (т. Е. Не тест-хост-коммутатор или хост-маршрутизатор).
В конце концов, задержка будет сводиться к скорости пересылки на коммутаторе и особенностям архитектуры коммутатора (где ASIC размещены на плате, как осуществляется блокировка между линейными картами и т. Д.). Удачи в тестировании.