Методології тестування продуктивності WAN-ланки

11

У нас є пара нових різноманітно маршрутизованих 1Gbps Ethernet-зв'язків між місцями, приблизно в 200 милях. "Клієнт" - це нова досить потужна машина (HP DL380 G6, подвійні E56xx Xeons, 48 ГБ DDR3, R1 пара 300 ГБ 10krpm дисками SAS, W2K8R2-x64), а "сервер" теж досить пристойний автомат (HP BL460c G6 , подвійні E55xx Xeons, 72 ГБ, пара R1 146 ГБ 10 10 / min SAS-диски, двопортовий Emulex 4Gbps FC HBA, пов'язаний з подвійним Cisco MDS9509s, потім на виділені HP EVA 8400 з 128 x 450GB 15krpm дисками FC, RHEL 5.3-x64).

Використовуючи SFTP від клієнта, ми бачимо лише близько 40 Кбіт / с пропускної здатності, використовуючи великі (> 2 Гб) файли. Ми виконали тестування сервера на "інших локальних серверах" і побачили близько 500 Мбіт / с через локальні комутатори (Cat 6509), ми будемо робити те ж саме на стороні клієнта, але це ще день або близько.

Які ще методи тестування ви б використали, щоб довести постачальникам зв’язків, що проблема полягає у їхньому?

networking performance sftp

— Подрібнювач3
джерело

Я також хотів би дізнатися відповідь на це. Ми отримаємо орендовану лінію на 100 Мбіт наступного тижня десь :)

— Том О'Коннор

як каже user37899 - результати будуть вдячні.

— pQd

Будь які оновлення? Мені цікаво, як виходить цей.

— Кайл Брандт

Я побив провайдерів посилань "досить сильно" (за іронією долі вони є частиною тієї самої організації, в якій я працюю!) - вони до нас ще не повернулися.

— Chopper3

1

Ну добре, і до речі, якщо ви можете зрозуміти, чому я отримую 7 голосів за serverfault.com/questions/134467/… і 1 за це, я хотів би знати ;-)

— Кайл Брандт,

10

Налаштування слона: для
цього може знадобитися налаштування, ймовірно, тут не проблема, як каже pQd. Цей тип посилання відомий "Довга, жирна труба" або слон (див. RFC 1072 ). Оскільки це жирова гігабітна труба, що йде на відстань (відстань - це дійсно час / затримка в цьому випадку), вікно прийому tcp повинно бути великим (див. Малюнки див. У розділі TCP / IP Illustrated Volume 1, розділ розширень TCP).

Щоб зрозуміти, яким має бути вікно прийому, ви обчислюєте продукт затримки пропускної здатності:

Bandwidth * Delay = Product

Якщо затримка становить 10 МС, цей калькулятор вважає, що потрібно вікно отримання приблизно 1,2 Мбайт. Ми можемо зробити розрахунок самостійно за вищенаведеною формулою:

echo $(( (1000000.00/.01)/8  )) 
12500000

Таким чином, ви можете запустити дамп пакета, щоб побачити, чи масштабування вікна tcp (розширення TCP, що дозволяє використовувати більші вікна) відбувається правильно, щоб налаштувати це, як тільки ви зрозумієте, яка велика проблема.

Обмеження вікон:
Якщо це проблема, що ви обмежуєте розмір вікна без масштабування, я очікую наступних результатів, якщо не встановлено масштабування вікон, і затримка становить близько 200 мс, незалежно від розміру труби:

Throughput = Recieve Window/Round Trip Time

Тому:

echo $(( 65536/.2 ))
327680 #Bytes/second

Для отримання результатів, які ви бачите, вам потрібно просто вирішити питання про затримку, а саме:

RTT = RWIN/Throughput

Отже (для 40 кБайт / с):

echo $(( 65536.0/40000.0 )) 
1.63 #Seconds of Latency

(Будь ласка, перевірте мою математику, і вони, звичайно, не включають усі накладні протоколи / заголовки)

— Кайл Брандт
джерело

Ви знаєте, що я відчув трохи вини за тим, що тимчасово "наздогнав" вас на реп на другому тижні, і причина в тому, наскільки чортово гарні ваші відповіді - і БУМ! Ви навіть використовуєте оболонку, щоб робити математику, а не 1.5MB Mac Calculator.app, який я роблю! :) Дякую.

— Chopper3

1

У вас є і хороші відповіді, і мені подобається, що у мене є хтось, з ким я близький у відповіді, трохи покращує гру :-) Швидкий запит google нагадує мені, що ви також відповіли на мої запитання: serverfault.com/questions/107263/ … . Я просто дуже вдячний активним користувачам, які намагаються зробити так, щоб ця спільнота «відбулася». Але дякую за доповнення!

— Кайл Брандт

Мені теж немає нічого, що мені подобається більше, ніж знати, що ми допомогли тому, хто відчув, що вони самі по собі, з розчаруванням - окрім сиру, звичайно. Це сказало, що я ненавиджу це, коли ми також отримуємо погано сформовані запитання, чи ти чув моє запитання на SO podcast 82? також отримав безкоштовну футболку SF!

— Chopper3

Я слухаю більшість подкастів, але пропустив цей, повернусь і перевіряю його (ймовірно, у ці вихідні).

— Кайл Брандт

Вибачте за цей pQd, я фактично завжди читав ваш нік як PDQ, як у PDQ Баха: en.wikipedia.org/wiki/P._D._Q._Bach :-)

— Кайл Брандт

6

40 кбіт / с дуже низький [до того моменту, що я б підозрював несправні медіаконвертери / дуплексне невідповідність [але у вас є гігабіт, тому немає місця для напівдуплексу!] Тощо]. повинні бути задіяні втрати пакетів або дуже велике тремтіння.

iperf - це перший інструмент, який мені спадає на думку виміряти пропускну здатність. бігати в один бік

iperf -s

а з іншого:

iperf -t 60 -c 10.11.12.13

тоді ви можете поміняти ролі клієнта / сервера, використовувати -d для дуплексу та ін., запустити mtr між обома машинами перед початком тесту та побачити, які затримки / втрати пакету у вас є на невикористаному посиланні та як вони змінюються під час передачі даних.

ви хотіли б побачити: дуже невеликий тремтіння і відсутність втрат пакетів, поки посилання не насититься на 90-відсотковий відсоток її ємності.

iperf для * nix і win , читайте тут і тут про це.

mtr для * nix і win .

— pQd
джерело

Ми знаємо, що посилання складається з 6 посилань на 1000-базу-zx, так що, можливо, затримка буде введена всіма повторюваними, але навіть я здивований, як ви настільки низькі, чудова підказка на речі iperf від До речі, я зовсім забув, що воно існувало!

— Chopper3

будь ласка, опублікуйте свої результати!

— Двірник Unix

1

trapseath може показати вам проблеми з маршрутизацією між двома сайтами.

iperf, ttcp та bwping можуть дати вам корисну інформацію.

чи знаєте ви, як забезпечується посилання на 1 Гб? Ви наближаєте чи маршрутизуєте це посилання? Який угода про угода про зв'язок? вас може сформувати ваш постачальник посилань?

якщо ви отримуєте лише 40 кбіт, то є серйозна проблема, ви впевнені, що це не посилання на 1 Мб, а не на 1 ГБ / с. Напевно, ви побачите, що швидкість посилання - це не те, що ви думаєте :-)

— Двірник Unix
джерело

Дякуємо за вашу відповідь, це виділене багатосегментне з'єднане одномодове волоконне посилання, взагалі немає жодної форми, оскільки це всього лише L2 - о, і я так сподіваюся, що це не посилання на 1 Мбіт / с, не з грошима, які коштують :)

— Chopper3

1

якщо ваш мостинг до вашої локальної мережі, тобто немає маршрутизації нікуди, то мережеві трансляції будуть витрачати потужність посилання, правда, для 1 ГБ це буде невелика частка, але непрацююча мережева послуга може згладити посилання. Я припускаю, що ці мости поза вашим контролем. Ці перемикачі можуть бути перевантажені або мати дуже високу затримку. Висока затримка означає низьку пропускну здатність.

— Двірник Unix

@ user37899 - висока затримка не повинна означати низьку пропускну здатність, але вимагає налаштування ... все одно - скільки затримок можна отримати на 200 миль - якщо все нормально - не більше 3-10 мс. arp [або інша] трансляція по гігабітному каналу, ймовірно, дуже мала частка всієї наявної ємності.

— pQd

1

Якщо у вас є мережеві трансляції, що відбуваються на такому рівні, що впливає на продуктивність посилання, я підозрюю, що у вас виникли б проблеми із внутрішньою ефективністю задовго до того, як з'явився новий рядок і помітили б стільки ж.

— joeqwerty

@pQd Я насправді говорив про штормову трансляцію.

— Двірник Unix

0

RFC 2544 або Y.156sam

Це мережеві тести, які робляться для того, щоб довести довіреність угоди про угода. IPERF тощо не є верифікованими методами тестування в мережі.

— Ансель Ґадді
джерело