Metodologie testowania wydajności łącza WAN

11

Mamy parę nowych, zróżnicowanych trasowanych łączy Ethernet 1 Gb / s między lokalizacjami w odległości około 200 mil od siebie. „Klient” to nowa, dość wydajna maszyna (HP DL380 G6, podwójne eeony E56xx, 48 GB DDR3, para dysków 300 GB 10krpm SAS, W2K8R2-x64), a „serwer” jest również wystarczająco przyzwoity (HP BL460c G6 , podwójne Xeony E55xx, 72 GB, R1 para 146 GB dysków 10krpm SAS, podwójny port Emulex 4Gbps FC HBA połączony z podwójnym Cisco MDS9509s, a następnie na dedykowanym HP EVA 8400 z dyskami FC 128 x 450GB 15krpm, RHEL 5.3-x64).

Używając SFTP od klienta, widzimy tylko około 40 Kb / s przepustowości przy użyciu dużych (> 2 GB) plików. Przeprowadziliśmy testy serwera na innym serwerze lokalnym i widzimy około 500 Mb / s za pośrednictwem przełączników lokalnych (Cat 6509s), zrobimy to samo po stronie klienta, ale to już około dnia.

Jakich innych metod testowania użyłbyś, aby udowodnić dostawcom linków, że problem jest ich przyczyną?

networking performance sftp

— Siekacz 3
źródło

Chciałbym również poznać odpowiedź na to pytanie. Kiedyś w przyszłym tygodniu instalujemy naszą dzierżawioną linię 100Mbit :)

— Tom O'Connor

jak mówi użytkownik 37899 - wyniki będą mile widziane.

— pQd

Jakieś aktualizacje? Jestem ciekawy, jak to się okazuje.

— Kyle Brandt

„Źle” pokonałem dostawców linków (jak na ironię są częścią tej samej organizacji, dla której pracuję!) - jeszcze do nas nie wrócili.

— Chopper3

1

Ach, w porządku, a przy okazji, jeśli potrafisz zrozumieć, dlaczego dostaję 7 głosów za serverfault.com/questions/134467/... i 1 za to, chciałbym wiedzieć ;-)

— Kyle Brandt

10

Tuning an Elephant:
Może to wymagać strojenia, prawdopodobnie nie jest to tutaj problem, jak mówi pQd. Tego rodzaju link jest znany jako „Long, Fat Pipe” lub „elephant” (patrz RFC 1072 ). Ponieważ jest to gruba rura gigabitowa przechodząca na odległość (w tym przypadku odległość jest naprawdę czasem / opóźnieniem), okno odbioru tcp musi być duże (zdjęcia pokazano w Ilustrowanym tomie 1 TCP / IP, sekcja Rozszerzenia TCP).

Aby dowiedzieć się, jakie powinno być okno odbiorcze, oblicz produkt iloczynu opóźnienia przepustowości:

Bandwidth * Delay = Product

Jeśli występuje opóźnienie 10MS, kalkulator szacuje, że chcesz otrzymać okno odbioru o wielkości około 1,2 MB. Obliczenia możemy wykonać samodzielnie za pomocą powyższej formuły:

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

Możesz więc chcieć uruchomić zrzut pakietów, aby sprawdzić, czy skalowanie okna Tcp (rozszerzenie TCP, które pozwala na większe okna) dzieje się dobrze, aby dostroić to, gdy odkryjesz, jaki jest duży problem.

Ograniczenie okna:
jeśli jest to problem związany z ograniczeniem rozmiaru okna bez skalowania, oczekiwałbym następujących wyników, jeśli skalowanie okna nie jest dostępne i opóźnienie wynosi około 200 ms niezależnie od rozmiaru rury:

Throughput = Recieve Window/Round Trip Time

Więc:

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

Aby uzyskać widoczne wyniki, wystarczy rozwiązać problem z opóźnieniem, którym byłoby:

RTT = RWIN/Throughput

Tak więc (dla 40 kB / s):

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

(Proszę sprawdzić moją matematykę, a te oczywiście nie obejmują całego narzutu protokołu / nagłówka)

— Kyle Brandt
źródło

Wiesz, że czułem się trochę winny za tymczasowe „wyprzedzanie” cię w rep. W drugim tygodniu, a powodem jest to, jak cholernie dobre są twoje odpowiedzi - i BOOM! nawet robisz matematykę, a nie 1,5 MB Mac Calculator. :) Dziękuję Ci.

— Chopper3

1

Masz również dobre odpowiedzi i podoba mi się to, że mam kogoś, kogo jestem bliski w przedstawicielu, trochę ulepsza grę :-) Szybkie zapytanie Google przypomina mi, że również odpowiedziałeś na moje pytania: serverfault.com/questions/107263/ ... . Naprawdę doceniam aktywnych użytkowników, którzy próbują sprawić, by ta społeczność „się wydarzyła”. Ale dziękuję za uzupełnienie!

— Kyle Brandt

Mnie też nie ma nic bardziej, niż wiedzieć, że pomogliśmy komuś, kto czuł, że są sami z frustrującym problemem - oczywiście poza serem. To powiedziawszy, nienawidzę go, gdy mamy również źle sformułowane pytania. Czy słyszałeś moje pytanie na SO podcast 82? również z tego darmową koszulkę SF!

— Chopper3 16.04.2010

Słucham większości podcastów, ale przegapiłem ten, wrócę i sprawdzę (prawdopodobnie w ten weekend).

— Kyle Brandt

Przepraszam za to pQd, tak naprawdę zawsze czytałem twój nick jako PDQ jak w PDQ Bach: en.wikipedia.org/wiki/P._D._Q._Bach :-)

— Kyle Brandt

6

40 kb / s jest bardzo niskie [do tego stopnia, że podejrzewam, że wadliwe konwertery mediów / niedopasowanie dupleksu [ale masz gigabit, więc nie ma miejsca na półdupleks!] Itp. muszą wystąpić straty pakietów lub bardzo wysoki jitter.

iperf to pierwsze narzędzie, które przychodzi mi na myśl do pomiaru dostępnej przepustowości. biegnij z jednej strony

iperf -s

a z drugiej:

iperf -t 60 -c 10.11.12.13

następnie możesz zamienić role klient / serwer, użyć -d dla dupleksu itp. Uruchom mtr między obiema maszynami przed rozpoczęciem testu i sprawdź, jakie opóźnienia / straty pakietów masz na nieużywanym łączu i jak zmieniają się podczas transferu danych.

chciałbyś zobaczyć: bardzo mały fluktuacja i brak strat pakietów, dopóki łącze nie zostanie nasycone na poziomie 90 procent pojemności.

iperf for * nix i Win , przeczytaj o tym tutaj i tutaj .

mtr dla * nix i wygraj .

— pQd
źródło

Wiemy, że link składa się z 6 łączy 1000-base-zx, więc wszystkie powtarzające się elementy muszą być opóźnione, ale mimo to jestem zaskoczony, jak niski jest, świetna wskazówka na temat iperf przez całkowicie zapomniałem, że istnieje!

— Chopper3

proszę zamieścić swoje wyniki!

— The Unix Janitor

1

tracepath może pokazać problemy z routingiem między tymi dwoma stronami.

iperf, ttcp i bwping mogą dostarczyć użytecznych informacji.

czy wiesz, w jaki sposób udostępniany jest ten link 1 GB? czy łączysz się z tym linkiem? Jaka jest Twoja umowa SLA dla łącza? możesz być kształtowany przez swojego dostawcę linków?

jeśli dostajesz tylko 40kbs, to jest poważny problem, czy jesteś pewien, że nie jest to łącze 1 MB, a nie łącze 1 GB / s. Prawdopodobnie przekonasz się, że szybkość łącza nie jest taka, jak myślisz :-)

— The Unix Janitor
źródło

Dzięki za odpowiedź, jest to dedykowane, wielosegmentowe, mostkowane łącze światłowodowe jednomodowe, nie wymaga żadnego kształtowania, ponieważ jest to po prostu L2 przez całą drogę - och, i mam nadzieję, że nie jest to łącze 1 Mb / s, nie przy kosztach, które kosztuje :)

— Chopper3

1

jeśli łączysz się z siecią LAN, tj. nie ma żadnego rutingu, to transmisje sieciowe będą marnować przepustowość łącza, co prawda dla 1 GB, będzie to niewielki ułamek, ale źle działająca usługa sieciowa może spłaszczyć łącze. Zakładam, że te mosty są poza twoją kontrolą. Przełączniki te mogą być przeciążone lub powodować bardzo duże opóźnienia. Wysokie opóźnienie oznacza niską przepustowość.

— The Unix Janitor

@ user37899 - duże opóźnienie nie musi oznaczać niskiej przepustowości, ale wymaga strojenia ... w każdym razie - ile opóźnienia można uzyskać na 200 milach - jeśli wszystko jest w porządku - nie więcej niż 3-10 ms. arp [lub inny] nadawany na łączu gigabitowym to prawdopodobnie bardzo niewielki ułamek całej dostępnej pojemności.

— pQd

1

Jeśli masz transmisje sieciowe na takim poziomie, który wpływa na wydajność łącza, podejrzewam, że miałbyś wewnętrzne problemy z wydajnością na długo przed pojawieniem się nowej linii i zauważyłbyś tyle.

— joeqwerty

@pQd właściwie mówiłem o burzy nadawczej.

— The Unix Janitor

0

RFC 2544 lub Y.156sam

Są to testy sieciowe wykonywane w celu udowodnienia SLA przez przewoźnika. IPERF i tym podobne nie są weryfikowalnymi metodami testowania sieci.

— Ansel Gaddy
źródło