Ты смотришь на мир сквозь дырку. Действительный тест различий в задержке на разных скоростях будет между двумя идентичными сетевыми картами, соединенными кросс-кабелем Установите скорость подключения сетевых карт 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) вы можете увидеть начальные задержки / пропускную способность соединения намного ниже / выше, чем при передаче большой страницы или полной страницы. Если часть вашей страницы в потоковом режиме, вы можете увидеть резко отличную производительность между страницей и потоком.