Методики тестирования производительности канала WAN


11

У нас есть пара новых разветвленных каналов Ethernet 1 Гбит / с между точками на расстоянии около 200 миль. «Клиент» - это новый достаточно мощный компьютер (HP DL380 G6, двойные E56xx Xeons, 48 ​​ГБ DDR3, пара R1 300 ГБ дисков SAS 10krpm в минуту, W2K8R2-x64), а «сервер» тоже достаточно приличный компьютер (HP BL460c G6 два E55xx Xeons, 72 ГБ, пара R1 из 146 ГБ дисков SAS 10 кбит / с, двухпортовый HBA-адаптер Emulex 4 Гбит / с, подключенный к двум Cisco MDS9509, затем к выделенному HP EVA 8400 с 128 x 450 ГБ 15 кбит / с FC-дисками, RHEL 5.3-x64).

Используя SFTP от клиента, мы видим пропускную способность около 40 Кбит / с при использовании больших (> 2 ГБ) файлов. Мы выполнили тесты с сервера на «другой локальный сервер» и увидели около 500 Мбит / с через локальные коммутаторы (Cat 6509), мы собираемся сделать то же самое на стороне клиента, но это через день или около того.

Какие еще методы тестирования вы бы использовали, чтобы доказать провайдерам ссылок, что проблема в их?


Я также хотел бы знать ответ на этот. На следующей неделе мы установим нашу выделенную 100-мегабитную линию :)
Том О'Коннор,

как говорит user37899 - результаты будут оценены.
2010 г.

Любые обновления? Мне любопытно, как это получается.
Кайл Брандт

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

1
Ну ладно, и, кстати, если вы можете понять, почему я получаю 7 голосов за serverfault.com/questions/134467/… и 1 за это, я бы хотел знать ;-)
Кайл Брандт

Ответы:


10

Настройка слона:
это может потребовать настройки, вероятно, здесь не проблема, как говорит pQd. Этот вид связи известен как «Длинная, толстая труба» или слон (см. RFC 1072 ). Поскольку это толстый гигабитный канал, проходящий через расстояние (в данном случае это действительно время / задержка), окно приема tcp должно быть большим (см. Иллюстрации в TCP / IP, том 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 и победа .


Мы знаем, что ссылка состоит из 6 ссылок 1000-base-zx, так что все эти повторения неизбежно повлекут за собой задержку, но даже в этом случае я удивлен, насколько вы низки, и отличный совет от iperf Кстати, я совсем забыл, что оно существует!
Chopper3

пожалуйста, опубликуйте свои результаты!
The Unix Дворник

1

tracepath может показать вам проблемы маршрутизации между двумя сайтами.

iperf, ttcp и bwping могут дать вам полезную информацию.

Знаете ли вы, как эта ссылка 1GB предоставляется? Вы соединяете или маршрутизируете по этой ссылке? Какой у вас SLA по ссылке? Вы могли бы быть сформированы вашим поставщиком ссылок?

если вы получаете только 40 КБ, то есть серьезная проблема, вы уверены, что это не ссылка 1 МБ, а не ссылка 1 ГБ / с. Вы, вероятно, обнаружите, что скорость ссылки не такая, как вы думаете :-)


Спасибо за ваш ответ, это выделенная многомодовая мостовая одномодовая волоконно-оптическая линия связи, в которой вообще нет необходимости в формировании, так как это всего лишь L2 - о, и я очень надеюсь, что это не линия связи 1 Мбит / с, не за счет денег, которые она стоит :)
Chopper3

1
если ваше мостовое соединение с вашей локальной сетью, т.е. нигде нет маршрутизации, то сетевые широковещательные рассылки будут тратить пропускную способность канала, правда, для 1 ГБ это будет небольшая доля, но неправильно работающая сетевая служба может сгладить соединение. Я предполагаю, что эти мосты находятся вне вашего контроля. Эти переключатели могут быть перегружены или иметь очень большую задержку. Высокая задержка означает низкую пропускную способность.
Дворник Unix

@ user37899 - высокая задержка не обязательно означает низкую пропускную способность, но требует настройки ... в любом случае - какую задержку вы можете получить на 200 миль - если все в порядке - не более 3-10 мс. Передача arp [или другого] по гигабитному каналу, вероятно, очень малая часть всей доступной емкости.
2010 г.

1
Если у вас есть сетевые трансляции, происходящие на таком уровне, чтобы повлиять на производительность канала, то я подозреваю, что у вас были бы внутренние проблемы с производительностью задолго до появления новой линии, и вы бы заметили столько же.
Joeqwerty

@pQd Я действительно говорил о широковещательном шторме.
Дворник Unix

0

RFC 2544 или Y.156sam

Это сетевые тесты, которые выполняются для подтверждения SLA оператором. IPERF и т.п. не являются проверяемыми методами тестирования сети.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.