У меня есть веб-сервер с текущим подключением 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 различных устройств по пути, по которому проходит пакет - начиная с NIC на вашем сервере, вплоть до MTU компьютера вашего клиента. Во внутренних приложениях локальной сети (когда вы контролируете все устройства вдоль пути) иногда можно увеличить MTU, но в этой ситуации вы в значительной степени застряли с MTU по умолчанию, равным 1500. Если вы отправляете пакеты, размер которых превышает что в конечном итоге они будут фрагментированы, что приведет к снижению производительности.
источник
ДА Гбит имеет меньшую задержку, так как:
НО улучшение возможно только в том случае, если пакет (ы) имеют определенный размер:
Таким образом, если у вас есть приложение, которое очень чувствительно к задержке (4 мс против 0,8 мс, в оба конца для 20 КБ) и требует передачи больших пакетов, переключение с 100 Мбит на Гбит может дать вам снижение задержки, даже если вы используете намного меньше, чем в среднем 100 Мбит / с (= ссылка не насыщена постоянно).
Сервер (100 Мбит) -> Коммутатор (Гбит) -> Сервер (100 Мбит):
Сервер (Гбит) -> Коммутатор (Гбит) -> Сервер (Гбит):
= в среднем по нескольким серверам снижение задержки на 80% при пинге 20 КБ
(Если только одна из ссылок является gbit, у вас все равно будет 5% снижение задержки для пинга 20 КБ.)
источник
Я думаю, что у вас есть фундаментальное неправильное представление о задержке пропускной способности и «скорости». Скорость зависит от пропускной способности и задержки. Например, рассмотрим отправку данных на DVD, отправленных по всей стране, за 3 дня до прибытия. Сравните это с отправкой данных через Интернет. Интернет имеет гораздо более низкую задержку соединения, но для соответствия «скорости» соединения с грузом вам нужно будет получить скорость 9,6 МБ в секунду ( справочный пример из этого источника ).
В вашем случае обновление до более высокой пропускной способности позволит вам обслуживать более параллельных пользователей, но не увеличит задержку для любого отдельного пользователя.
источник
Ты смотришь на мир сквозь дырку. Действительный тест различий в задержке на разных скоростях будет между двумя идентичными сетевыми картами, соединенными кросс-кабелем Установите скорость подключения сетевых карт 10 МБ, 100 МБ и 1000 МБ. Это покажет, что практически нет разницы в задержке на разных скоростях. Все пакеты передаются с одинаковой скоростью передачи данных независимо от используемой максимальной пропускной способности. Как только вы добавляете ключи с сохранением и прямым кэшированием, все меняется. Проверка задержки через коммутатор должна выполняться только с двумя подключениями к коммутатору. Любой другой трафик может повлиять на задержку вашего теста. Даже тогда коммутатор может пролонгировать журналы, настроить счетчики типов пакетов, обновить внутренние часы и т. Д. Все может повлиять на задержку.
Да, переключение с 100 МБ на 1 ГБ может происходить быстрее (с меньшей задержкой) из-за аппаратных изменений, разной сетевой карты, другого коммутатора, другого драйвера. Я видел большие изменения в задержке ping из-за различий в драйверах, чем любые другие изменения; пропускная способность, коммутаторы, разгрузка сетевых карт и т. д.
Следующим большим изменением будет переключение с сквозным проходом, значительно более быстрым, чем сохранение и пересылка для тестов с одной передачей. Тем не менее, хорошо спроектированный переключатель хранения и пересылки может обогнать сквозной переключатель по общей производительности при высокой нагрузке. В первые дни гигабита я видел высокопроизводительные коммутаторы на задней панели 10 Мб с более низкой задержкой, чем дешевые гигабитные коммутаторы.
Пинг-тесты практически не имеют отношения к анализу производительности при использовании Интернета. Это быстрые тесты, чтобы получить представление о том, что происходит на транспорте в момент теста. Тестирование производительности производства гораздо сложнее, чем просто пинг. Высокопроизводительные коммутаторы являются компьютерами и при высокой нагрузке ведут себя по-разному - меняются задержки.
Более медленный NIC или NIC, настроенный на более медленную скорость, может фактически помочь серверу с одновременными пакетами, дросселируя входные данные для сервера, используя кэш коммутаторов. Одна повторная передача может свести на нет любое уменьшение задержки. Обычно важны средние и высокие уровни трафика, а не тесты с одним пингом. Например, старый медленный 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их, будут на самом деле больше из-за заголовков).0,024 мс - это приблизительно фактическое время, необходимое для отправки кадра (без учета времени доступа к среде или заголовков).
В последовательности пинг-понга это заняло бы вдвое больше времени (0,048 мс) плюс время, необходимое операционной системе для обработки запроса.
Для меня это означает, что ваша задержка вызвана 90% из нескольких факторов накладных расходов. Я не уверен, увидите ли вы большую разницу с Гб. Вероятно, разница менее 1 мс не будет заметна на веб-сервере.
В любом случае, не могли бы вы попробовать действительно большой пакет, например, 1400 байт?
источник
Это зависит от типа коммутатора, к которому вы подключаетесь. На некоторых вендорах (таких как Crisco ... я имею в виду Cisco) ICMP-пакеты будут возвращаться обратно в CPU ( gag ).
Может оказаться, что лучшим тестом будет выполнение теста хост-хост с использованием канала 100 Мбит / с и 1 Гбит / с (т. Е. Не тест хост-коммутатор или хост-маршрутизатор).
В конце дня задержка снизится до скорости пересылки на коммутаторе и особенностей архитектуры коммутатора (где ASIC размещены на плате, как обрабатывается блокировка между линейными картами и т. Д.). Удачи в тестировании.
источник