Затримка в мережі: 100 Мбіт проти 1 Гбіт


11

У мене є веб-сервер із поточним підключенням 100Mbit, і мій провайдер пропонує оновлення до 1Gbit. Я розумію, що це стосується пропускної здатності, але чим більше пакетів, тим швидше вони також можуть передаватися, тому я б очікував невеликого скорочення часу відгуку (наприклад, 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

Також є різні кодування (10b / 12b?) З новими картками та кабелями gther Ethernet, так що це може мати% 25 більшу продуктивність на вершині 10x (при насиченні) проти 100Mbit, можливо?
huseyin tugrul buyukisik

Відповіді:


15

Єдиний спосіб затримки помітно знизиться, якщо поточна 100 Мбітна ланка насичена. Якщо він не насичений, ви, швидше за все, не помітите жодних змін.

Крім того, ваше припущення, що 1Gbit-посилання зможе підтримувати більші пакети, невірно. Максимальний розмір пакета визначається MTU різних пристроїв по шляху, який проходить пакет - починаючи з NIC на вашому сервері, аж до MTU комп'ютера вашого клієнта. У внутрішніх програмах LAN (коли у вас є контроль над усіма пристроями на шляху), іноді можливо збільшити MTU, але в цій ситуації ви досить сильно застрягли з MTU за замовчуванням 1500. Якщо ви надсилаєте пакети більше що, в кінцевому рахунку, вони будуть роздробленими, тим самим фактично знизивши продуктивність.


2
"Помітно" тут є ключовим словом. Я щойно перевірив два сервери з однаковим обладнанням та низьким навантаженням на мережу, але з різною швидкістю Ethernet. Середній час пінгу (локальний, з джерелом пінг-сигналу в одній підмережі) знизився з 0,21 мілісекунди до 0,17 мілісекунд. Пінгнінг тих же серверів з дому, кожен мав час у 53 мілісекунди. Існує занадто багато факторів, що не підлягають контролю вашого постачальника, щоб зробити це гідним оновленням.
Майк Ренфро

1
+1 З технічної точки зору є різниця, однак вона є абсолютно неприйнятною, якщо конкретна програма не є надзвичайно чутливою до затримок.
Chris S

Дякую за тест! Від 0,21 до 0,17 - це поліпшення на 20%, що чудово. Мене не хвилює пінг з дому (50 мс), але час, коли запит залишається у постачальника. Ми підкоригували всю обробку (ЦП) і непривідний IO (ОЗУ / кеш / тощо) до максимуму, тому тепер я сумніваюся, наскільки швидкість мережі між серверами додає до всієї затримки як загальної. Наприклад, ми робимо ~ 20 повторних запитів для одного запиту веб-сервера. @MikeRenfro: чи можна зробити те ж тест із більшим навантаженням? Звичайний ping - 30 байт, сер. Redis близько 250. Я б очікував, що різниця зросте.
Андреас Ріхтер

2
@Andreas; Я думаю, ви повністю пропустили суть цих коментарів. Це поліпшення 40 наносекунд. Сума, яка абсолютно непомітна для людини . І це не сукупне число, це не так, як кожен запит займає на 40 наносекунд більше; це просто перше буде набагато швидше, тож друге буде вишикуватися прямо за ним у будь-якому випадку.
Кріс С

1
@ChrisS: питання не було про сприйнятливість - це питання, якщо хтось коли-небудь перевіряв це, а Майк це робив. Це також не 40 наносекунд, це мікросекунди , тому ви пропускаєте крапку в коефіцієнті 1000 ... кудо. Повірте, що я знаю, що роблю ... 20% вистачило б для виправдання додаткових витрат.
Андреас Ріхтер

12

ТАК gbit має меншу затримку, оскільки:

  • однакову кількість байтів можна перенести за швидший час

АЛЕ поліпшення помітне лише в тому випадку, якщо пакет (и) мають певний розмір:

  • 56-байтний пакет => практично не швидша передача
  • 1000-байтний пакет => 20% швидша передача
  • 20000 байт пакет (и) => 80% швидше передача

Тож якщо у вас є програма, яка дуже чутлива до затримки (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

Сервер (gbit) -> Комутатор (gbit) -> Сервер (gbit):

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 кбіт пінг

(Якщо лише одна з посилань - gbit, у вас все одно буде 5% скорочення затримки для 20kb ping.)


1
У більшості мережевих передач, які зберігаються та передаються, пакет повинен бути повністю отриманий комутатором / маршрутизатором до його передачі. Швидше з'єднання скорочує цей час, що також зменшує затримку (доти, коли з'єднання не набере швидкість від декількох паралельних ліній).
Брайан

1
Завдяки поясненню ця відповідь на сьогоднішній день найкраща. Інші, здається, хочуть пояснити цей факт, припустивши особливий випадок - продуктивність мережі на великій відстані / багато комутаторів. Це важливо враховувати, особливо з огляду на стурбованість ОП (веб-сервер), але ця відповідь також показує, скільки різниці швидкості комутації можуть скласти за один скачок.
Тайлер

3

Я думаю, у вас є принципова помилка щодо затримки пропускної здатності та "швидкості". Швидкість - це функція пропускної здатності та затримки. Наприклад, розгляньте можливість перевезення даних про DVD-диски, що постачаються по всій країні, і триватиме 3 дні. Порівняйте це з надсиланням даних через Інтернет. Інтернет має набагато нижчу затримку зв'язку, але для того, щоб відповідати "швидкості" з'єднання з вантажем, вам доведеться отримати 9,6 МБ в секунду ( довідковий приклад з цього джерела ).

У вашому випадку оновлення до більшої пропускної здатності дозволить вам обслуговувати більше одночасних користувачів, але не покращить затримки для будь-якого окремого користувача.


Це невірно - просто порівняйте ping з різною корисною навантаженням, що знаходиться нижче поточного MTU: ping-сервер -i0.05 -c200 -s30 проти сервера ping -i0.05 -c200 -s300 ... Або кажучи у вашому прикладі: вантажівка з 1-мільйонними DVD-дисками їхатиме повільніше, оскільки вона важча, ніж та, що має 1 DVD.
Андреас Ріхтер

2
@andreas ping time - це не вся історія - тому давайте взяти для себе аргумент, що пакети нижче MTU надходять швидше, ніж пакети на повній MTU. різниця у вас немає всіх даних про те, що 1 пакет має повний mtu за той самий проміжок часу, який потрібен 2 пакетам. Затримка - це час, необхідний для надходження всіх даних. щоб повернутися до аналогії вантажівки, навіть якщо для того, щоб вантажівка з 1 кд приїхала за половину часу, як вантажівка, що перевозила 500 к.с., вона все одно потребує 500 вантажних поїздок для передачі даних (750 днів проти 3).
Jim B

@JimB: так, як згадувалося, моє запитання стосувалося не величини вантажу, а швидкості: для повного вантажівки потрібно перевірити митницю 10 годин, маленькій - лише 1 годину. 100mbit / s також означає, що для 100-бітового пакету необхідний теоретичний мінімум 0,000954ms, а 1000-бітовий пакет - теоретичний мінімум 0,00954ms. Звичайно час обробки / тощо. на мережевій карті / комутаторі / тощо. зробіть більш високий шматок усієї затримки, але я б також очікував, що вони будуть швидшими в 1 Гбіт комутаторі і т. д. Будь ласка, дивіться коментар @MikeRenfro, він насправді перевірив це і досяг 20% збільшення.
Андреас Ріхтер

@andreas - 20% у тій самій підмережі, що не має значення для вашого питання
Jim B

1
@andreas 20% підомільсекундного пінгу все ще є субмілісекундним пінг. Навіть 150% субмілісекундного пінгу, як у вашому тестуванні, не матиме значення в реальному світі. Чи дійсно у вас є програма, де важливо, чи отримали ваші дані за 0,0003 секунди замість 0,0002 секунди ?
Шейн Мадден

2

Ти дивишся на світ крізь щілину. Дійсний тест різниці затримок при різних швидкостях буде між двома однаковими NIC, з'єднаними з перехресним кабелем. Встановіть швидкість поєднання NIC в 10 Мб, 100 Мб і 1000 Мб. Це покаже, що різниці в затримці практично при різній швидкості практично немає. Усі пакети рухаються з однаковою швидкістю дроту незалежно від використовуваної максимальної пропускної здатності. Після того, як ви додасте перемикачі з кешуванням магазину та вперед, все змінюється. Перевірка затримки через вимикач повинна виконуватися лише з двома підключеннями до вимикача. Будь-який інший трафік може вплинути на затримку вашого тесту. Навіть тоді комутатор може перевертати журнали, налаштовувати лічильники типів пакетів, оновлювати внутрішній годинник тощо. Все може вплинути на затримку.

Так, перехід від 100 Мб до 1 Гбіт може бути швидшим (менша затримка) через зміни обладнання, різного NIC, іншого комутатора, різного драйвера. Я помітив більші зміни в затримці пінг-файлу від різниць драйверів, ніж будь-які інші зміни; пропускну здатність, комутатори, вивантаження NIC та ін.

Перемикач був би наступною найбільшою зміною із прорізанням значно швидше, ніж зберігання та пересилання для одночасних тестів передачі. Однак добре розроблений магазин і перемикач вперед можуть перегнати перемикач прорізу в загальній продуктивності при великому навантаженні. У перші дні гігабіту я бачив 10-мільйонні високоефективні комутатори на задній площині з меншою затримкою, ніж дешеві гігабітні комутатори.

Тести Ping практично не мають значення для аналізу продуктивності при користуванні Інтернетом. Вони проходять швидкі тести, щоб отримати уявлення про те, що відбувається на транспорті на момент випробування. Тестування продуктивності виробництва набагато складніше, ніж просто пінг. Високопродуктивні комутатори - це комп’ютери і під високим навантаженням поводяться по-різному - зміна затримки.

Маючи повільніший NIC або встановлений NIC з меншою швидкістю, насправді може допомогти серверу з одночасними сплесками, заглушивши вхід на сервер за допомогою кешу комутаторів. Одноразова повторна передача може заперечувати будь-яке зниження затримки. Зазвичай важливі рівні середнього та високого завантаження, а не одиночні тести ping. Наприклад, старий повільний Sun Ultrasparc (більша затримка на один пінг) перевершує новий дешевий гігабітний робочий стіл, який використовується як сервер розробників, коли пропускна здатність пропускної здатності становить менше 70%. Настільний ПК має швидший NIC gb, швидше підключення gb-gb, більш швидку пам'ять, більше пам’яті, швидший диск та швидший процесор, але він не працює так добре, як налаштоване обладнання та програмне забезпечення серверного класу. Це не означає, що поточний налаштований сервер, на якому працює gb-gb, не швидший, ніж старе обладнання, навіть здатний обробляти великі навантаження пропускної здатності. Щодо питання про "

Дізнайтеся, чи використовує ваш провайдер різні комутатори для з'єднань 100mb проти 1Гб. Якщо вони використовують ту саму задню площину комутаторів, ніж я б заплатив за збільшення, лише якщо рівень трафіку перевищив нижню пропускну здатність. В іншому випадку ви можете виявити, що за короткий час багато інших користувачів перейдуть на гігабіт, і небагато користувачів, які залишилися на старому комутаторі, тепер мають більш високу продуктивність - меншу затримку під час великих навантажень на комутатор (загальне навантаження комутатора, а не лише на ваші сервери ).

Приклад яблук та апельсинів: Місцевий Інтернет-провайдер запропонував новий комутатор для пакетних послуг, DSL та телефону. Спочатку користувачі бачили підвищення продуктивності. Система була перепродана. Тепер користувачі, які залишаються на старому комутаторі, мають більш високу стабільну продуктивність. Під час пізньої ночі користувачі в новій системі швидше. Увечері під великим навантаженням старі клієнти комутаторів явно перевершують нову перевантажену систему.

Нижня затримка не завжди корелює з швидшою доставкою. Ви згадуєте MySQl у 20 запитах на обслуговування однієї сторінки. Цей трафік не повинен бути в тому самому NIC, який вимагає сторінка. Переміщення всього внутрішнього трафіку до внутрішньої мережі зменшить зіткнення та загальний підрахунок пакетів у вихідному NIC та забезпечить більший приріст, ніж посилення затримки в .04ms одного пакету. Зменшіть кількість запитів на сторінку, щоб зменшити затримку завантаження сторінки. Стисніть сторінки, html, css, javascript, зображення, щоб зменшити час завантаження сторінки. Ці три зміни дадуть більший загальний прибуток, ніж плата за пропускну здатність, що не використовується для зменшення затримки на 0,04 мс. Пінг повинен працювати 24 години і усереднюватися, щоб побачити реальну затримку. Інтелектуальні комутатори тепер роблять адаптивне придушення типу RTSP з невеликим початковим збільшенням пропускної здатності та великими передачами. Залежно від розмірів вашої сторінки (графіка, великий html / css / javascript), ви можете побачити початкові затримки підключення / пропускну здатність набагато нижче / вище, ніж велика сторінка або перенесення на повну сторінку. Якщо частина вашої сторінки потокова, ви можете побачити різко різну ефективність між сторінкою та потоком.


Дякую за все чудове введення: 1.) Це той самий перемикач, 2.) Другий NIC для внутрішніх / зовнішніх звуків, резонансних і варто спробувати - хоча, наприклад, MySQL / тощо. всі двосторонні, тому зіткнення "лише" зменшиться до половини. апаратне забезпечення: "56 байт = 19% поліпшення, 200 байт = 27%, 1000 байт = 59%! Отже, чим більший пакет, тим більше це має значення. І гігабіт збільшився лише з 0,17 мс (56 байт) до 0,23 мс (1000 байт ) => 35%, тоді як 100 Мбіт збільшився з 0,21 до 0,56 => 166% ".
Андреас Ріхтер

1

Припустимо, 300 байт-пакетів (якщо ви використовуєте, -s 300це було б насправді більше через заголовки).

300 bytes = 2400 bits
2400 bits / 100Mbit/sec = 0.024ms

0,024 мс - це приблизно фактичний час, необхідний для надсилання кадру (без урахування середнього часу доступу та заголовків).

У послідовності пінг-понгу це знадобиться вдвічі більше (0,048 мс), плюс час, щоб ОС обробити запит.

Це означає для мене, що ваша затримка обумовлена ​​90% кількох накладних факторів. Я не впевнений, чи побачите ви велику різницю з Gb. Можливо, різниця менше 1 мс не буде помітною для веб-сервера.

У будь-якому випадку ви можете спробувати з дійсно великим пакетом, як 1400 байт?


Хтось уже запустив номери для певного сервера, і різниця повернулася на 40 наносекунд. Ваша здогадка вимикається в 25 разів завеликий.
Chris S

@LatinSuD: дякую за конструктивний підхід і не звинувачую, що я не знаю, що роблю. Я опублікую результати в актуальному запитанні, оскільки можу там формувати. Але btw. Я також очікував би, що на 90% накладніші мають збільшити швидкість , оскільки процесори в мережевих картах і т.д. швидші для GBit (сподіваємось). @ChrisS: мікросекунди, і я не розумію, що ти маєш на увазі під 25.
Андреас Ріхтер

Мої вибачення за змішування мікро та нано; у будь-якому випадку це непомітно. LatinSuD відгадав різницю в 1 цілу мілісекунд, що в 25 разів більше, ніж 40 мікросекунд, знайдених Майком.
Chris S

@ChrisS: не хвилюйся. 0,04 мс припадало на 38-байтний пінг, якщо наш середній пакет сервер-сервер становить близько 300 байт, різниця може становити 0,4 мс. Якщо ми зараз зробимо 20 запитів на один сервер-запит (Redis, MySQL тощо), це призведе до збільшення швидкості на 8 мс, що було б на 10% швидкішим для поточних веб-запитів і повністю виправдало б додаткові витрати. Я просто не маю тут ресурсів, щоб сам проводити тести, але повірте, що навіть якщо люди не сприймають, це все ще може мати значення. Як електрика чи бог.
Андреас Ріхтер

1
@Andreas, я дуже сумніваюся, що це буде масштабуватися так; обидва пакети на 10 разів більший, затримка на 10 разів менша, і 20 разів більша кількість пакетів на 20 разів швидше. Якщо це не виходить, це на 10% зменшення накладних витрат на мережу, вам все одно доведеться враховувати час, витрачений на додаток, який, ймовірно, буде на один-кілька порядків більше, ніж компонент затримки в мережі. Я сподіваюся, що це у вас вийде добре у будь-якому випадку.
Chris S

1

Це залежить від типу комутатора, до якого ви підключаєтесь. На деяких постачальниках (таких як Crisco ... я маю на увазі Cisco) пакети ICMP повернуться до процесора ( gag ).

Ви можете знайти кращий тест - виконати тест "хост-хост", використовуючи посилання 100Mbps та 1Gbps (тобто не тест "хост-комутатор" або "хост-маршрутизатор").

Зрештою, затримка знижується до швидкості переадресації на комутаторі та деталей архітектури вимикача (де ASIC розміщені на платі, як здійснюється блокування між лініями карт тощо). Удачі у вашому тестуванні.


Дякую, я маю на увазі лише тести Host-Switch-Host і не розумію всіх інтернетів комутаторів. Я просто хотів би побачити, якщо хтось коли-небудь орієнтується: Host- (100mbit) -Switch- (100mbit) -Host, Host- (100mbit) -Switch- (1gbit) -Host і Host- (1gbit) -Switch- (1gbit ) -Висока затримка для різних розмірів пакету. Якщо ніхто цього не зробив, я це зроблю і опублікую відповідь тут.
Андреас Ріхтер

1
Раніше я перепродав перемикач передач. Досить сказати, ваші висновки підказують мені, що ви підключені до комутатора Cisco. Є й інші варіанти, які забезпечують менші затримки. Як ви справедливо зазначали, більша пропускна здатність не призводить до менших затримок (Comcast є основним винуватцем того, що люди німіють у цьому плані). З огляду на те, що ви перебуваєте в розміщеному середовищі, ви, мабуть, застрягли з їх обладнанням (а оскільки в розміщеному середовищі зайві кілька мікросексів не дуже важливі). Покажіть мені мільйони пунктів у стаціонарному режимі, і я зацікавлюсь у наданні більше деталей. :)
Шон
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.