W tej chwili próbujemy zdecydować, czy przenieść nasze centrum danych z zachodniego wybrzeża na wschodnie wybrzeże.
Widzę jednak niepokojące liczby opóźnień od mojego położenia na zachodnim wybrzeżu do wschodniego wybrzeża. Oto przykładowy wynik: pobranie małego pliku logo .png w Google Chrome i użycie narzędzi programistycznych do sprawdzenia, jak długo trwa żądanie:
- Wybrzeże zachodnie do wybrzeża wschodniego:
opóźnienie 215 ms, czas transferu 46 ms, łącznie 261 ms - Zachodnie wybrzeże do zachodniego wybrzeża:
opóźnienie 114 ms, czas transferu 41 ms, łącznie 155 ms
Ma to sens, że Corvallis, OR jest geograficznie bliżej mojej lokalizacji w Berkeley, Kalifornia, więc spodziewam się, że połączenie będzie nieco szybsze .. ale widzę wzrost opóźnienia o + 100 ms, gdy wykonuję ten sam test w Nowym Jorku serwer. To wydaje mi się ... przesadne. Zwłaszcza, że czas przesyłania rzeczywistych danych wzrósł tylko o 10%, a opóźnienie wzrosło o 100%!
To wydaje mi się ... złe ... dla mnie.
Znalazłem tutaj kilka linków, które były pomocne (nie mniej przez Google!) ...
- Czy odległość trasy znacząco wpływa na wydajność?
- Jak geografia wpływa na opóźnienie sieci?
- Opóźnienia w połączeniach internetowych z Europy do USA
... ale nic wiarygodnego.
Czy to jest normalne? To nie wydaje się normalne. Jakiego „typowego” opóźnienia należy się spodziewać przy przenoszeniu pakietów sieciowych ze wschodniego wybrzeża <--> zachodniego wybrzeża USA?
źródło
Odpowiedzi:
Szybkość światła:
Nie pobijesz prędkości światła jako interesującego punktu akademickiego. Ten link działa Stanford do Bostonu na około 40ms najlepszy możliwy czas. Kiedy ta osoba wykonała obliczenia, zdecydował, że Internet działa z prędkością „około dwa razy większą niż prędkość światła”, więc czas transferu wynosi około 85ms.
Rozmiar okna TCP:
Jeśli masz problemy z szybkością transferu, może być konieczne zwiększenie rozmiaru okna odbiorczego tcp. Konieczne może być również włączenie skalowania okna, jeśli jest to połączenie o dużej przepustowości i dużym opóźnieniu (nazywane „długą grubą rurą”). Jeśli więc przenosisz duży plik, musisz mieć wystarczająco duże okno odbiorcze, aby wypełnić rurę bez konieczności oczekiwania na aktualizacje okna. W mojej odpowiedzi „ Tuning an Elephant” szczegółowo opisałem, jak to obliczyć .
Geografia i opóźnienie:
W przypadku niektórych sieci CDN (sieci dystrybucji treści) punktem krytycznym jest to, że utożsamiają one opóźnienia i geografię. Google przeprowadziło wiele badań w swojej sieci i znalazło w tym wady, opublikowali wyniki w białej księdze Moving Beyond End-to-end Path Information to Optimize Performance CDN :
Peerings BGP:
jeśli zaczniesz studiować BGP (podstawowy protokół routingu internetowego) i sposób, w jaki dostawcy usług internetowych wybierają peeringi, przekonasz się, że często dotyczy to finansów i polityki, więc nie zawsze możesz wybrać najlepszą trasę do określonych lokalizacji geograficznych, w zależności na twoim ISP. Możesz sprawdzić, w jaki sposób twój adres IP jest połączony z innymi dostawcami usług internetowych (Autonomous Systems) za pomocą routera z lustrami . Możesz także skorzystać ze specjalnej usługi whois :
Przyjemnie jest też odkrywać je jako peery z narzędziem GUI, takim jak linkrank , które daje obraz Internetu wokół ciebie.
źródło
Ta witryna sugerowałaby, że opóźnienie na wschodnim / zachodnim wybrzeżu USA wynosi około 70–80 ms (na przykład z San Francisco do Nowego Jorku).
Oto moje czasy (jestem w Londynie, w Anglii, więc moje czasy na zachodnim wybrzeżu są wyższe niż na Wschodzie). Otrzymuję różnicę opóźnienia 74 ms, która wydaje się potwierdzać wartość z tej witryny.
Zostały one zmierzone za pomocą narzędzi programistycznych Google Chrome.
źródło
71 msz NY do SF , więc masz rację - nie możemy się spodziewać lepszych wyników.Najpierw zmierz za pomocą ICMP, jeśli to w ogóle możliwe. Testy ICMP zwykle domyślnie używają bardzo małego ładunku, nie używają potrójnego uzgadniania i nie muszą wchodzić w interakcje z inną aplikacją na stosie, tak jak HTTP. W każdym razie niezwykle ważne jest, aby wyniki HTTP nie były pomieszane z wynikami ICMP. Są to jabłka i pomarańcze.
Przechodząc od odpowiedzi Richa Adamsa i korzystając z witryny , którą polecił, widać, że na szkielecie AT&T ruch ICMP zajmuje 72 ms między punktami końcowymi SF i NY. To niezła liczba do przejścia, ale należy pamiętać, że jest to sieć całkowicie kontrolowana przez AT&T. Nie uwzględnia przejścia do sieci domowej lub biurowej.
Jeśli wykonasz polecenie ping przeciwko careers.stackoverflow.com z sieci źródłowej, powinieneś zobaczyć coś niezbyt odległego od 72 ms (może +/- 20 ms). W takim przypadku możesz prawdopodobnie założyć, że ścieżka sieci między wami jest w porządku i działa w normalnych zakresach. Jeśli nie, nie panikuj i dokonuj pomiaru z kilku innych miejsc. To może być twój dostawca usług internetowych.
Zakładając, że minęło, następnym krokiem jest zajęcie się warstwą aplikacji i ustalenie, czy coś jest nie tak z dodatkowym obciążeniem, które widzisz przy żądaniach HTTP. Może się to różnić w zależności od aplikacji, ze względu na sprzęt, system operacyjny i stos aplikacji, ale ponieważ masz w przybliżeniu identyczny sprzęt zarówno na wschodnim, jak i zachodnim wybrzeżu, użytkownicy wschodniego wybrzeża mogą trafić na serwery zachodniego wybrzeża, a użytkownicy zachodniego wybrzeża - na wschodnie Wybrzeże. Jeśli obie strony są odpowiednio skonfigurowane, spodziewam się, że wszystkie liczby będą mniej równe, a tym samym zademonstruję, że to, co widzisz, jest prawie równe grubej.
Jeśli te czasy HTTP mają dużą zmienność, nie zdziwiłbym się, gdyby wystąpił problem z konfiguracją w witrynie działającej wolniej.
Teraz, gdy już będziesz w tym momencie, możesz spróbować przeprowadzić bardziej agresywną optymalizację po stronie aplikacji, aby sprawdzić, czy te liczby można w ogóle zmniejszyć. Na przykład, jeśli używasz IIS 7, czy korzystasz z jego możliwości buforowania itp.? Może mógłbyś tam coś wygrać, a może nie. Jeśli chodzi o ulepszanie elementów niskiego poziomu, takich jak okna TCP, jestem bardzo sceptyczny, że miałoby to duży wpływ na coś takiego jak przepełnienie stosu. Ale hej - nie będziesz wiedział, dopóki nie spróbujesz tego zmierzyć.
źródło
Kilka odpowiedzi tutaj używa pingów i traceroute do wyjaśnienia. Narzędzia te mają swoje miejsce, ale nie są niezawodne w pomiarze wydajności sieci.
W szczególności (przynajmniej niektóre) routery Juniper przesyłają przetwarzanie zdarzeń ICMP na płaszczyznę sterowania routera. Jest to DUŻO wolniej niż płaszczyzna przekazująca, szczególnie w routerze szkieletowym.
Istnieją inne okoliczności, w których odpowiedź ICMP może być znacznie wolniejsza niż faktyczna wydajność przekierowywania routera. Wyobraźmy sobie na przykład router z oprogramowaniem (bez specjalistycznego sprzętu do przekazywania), który ma 99% pojemności procesora, ale nadal dobrze porusza się w ruchu. Czy chcesz, aby spędzało dużo cykli na przetwarzaniu odpowiedzi traceroute lub przekazywaniu ruchu? Przetwarzanie odpowiedzi ma więc bardzo niski priorytet.
W rezultacie ping / traceroute daje rozsądne górne granice - wszystko idzie co najmniej tak szybko - ale tak naprawdę nie mówią ci, jak szybko idzie prawdziwy ruch.
W każdym razie -
Oto przykład traceroute z University of Michigan (środkowe USA) do Stanford (zachodnie wybrzeże USA). (Zdarza się, że jedzie przez Waszyngton (wschodnie wybrzeże USA), który jest 500 mil w „złym” kierunku).
W szczególności zwróć uwagę na różnicę czasu między wynikami traceroute z routera myjącego i routera atla (przeskok 7 i 8). ścieżka sieci przechodzi najpierw do mycia, a następnie do atla. pranie trwa 50-100 ms, a atla około 28 ms. Najwyraźniej atla jest dalej, ale jej wyniki traceroute sugerują, że jest bliżej.
Zobacz http://www.internet2.edu/performance/, aby uzyskać wiele informacji na temat pomiaru sieci. (zrzeczenie się, kiedyś pracowałem dla Internetu2). Zobacz także: https://fasterdata.es.net/
Aby dodać pewne szczególne znaczenie do pierwotnego pytania ... Jak widać, miałem czas pingowania w obie strony do Stanforda w czasie 83 ms, więc wiemy, że sieć może pójść przynajmniej tak szybko.
Zauważ, że ścieżka sieci badawczo-edukacyjnej, którą wybrałem na to traceroute, będzie prawdopodobnie szybsza niż zwykła ścieżka internetowa. Sieci R&E generalnie zawyżają swoje połączenia, co sprawia, że buforowanie w każdym routerze jest mało prawdopodobne. Zwróć też uwagę na długą ścieżkę fizyczną, dłuższą niż wybrzeże-wybrzeże, chociaż wyraźnie reprezentującą rzeczywisty ruch.
michigan-> waszyngton, dc-> atlanta-> houston-> los angeles-> stanford
źródło
Widzę stałe różnice i siedzę w Norwegii:
Zostało to zmierzone za pomocą naukowej dokładnej i sprawdzonej metody korzystania z widoku zasobów Google Chrome i po prostu wielokrotnego odświeżania każdego linku.
Traceroute to serverfault
Traceroute do kariery
Niestety, teraz zaczyna przechodzić w pętlę lub coś w tym stylu i nadal daje gwiazdy i limit czasu do 30 przeskoków, a następnie kończy.
Uwaga: traceroutes pochodzą z innego hosta niż czasy na początku, musiałem wykonać RDP na moim serwerze hostowanym, aby je wykonać
źródło
Widzę około 80-90 ms opóźnienia w dobrze zarządzanych, dobrze zmierzonych połączeniach między wschodnim i zachodnim wybrzeżem.
Ciekawie byłoby zobaczyć, gdzie zyskujesz opóźnienie - wypróbuj narzędzie, takie jak traceroute warstwy czwartej (lft). Szanse są duże, że zyskuje się na „ostatniej mili” (tj. U lokalnego dostawcy usług szerokopasmowych).
Należy się spodziewać, że czas transferu był tylko nieznacznie zmieniony - utrata pakietów i fluktuacje są bardziej użytecznymi pomiarami do zbadania podczas badania różnic czasu transferu między dwiema lokalizacjami.
źródło
Dla zabawy, gdy grałem w grę online Lineage 2 NA z Europy:
Różnica wydaje się potwierdzać, że do 100 ms jest w granicach rozsądku, biorąc pod uwagę nieprzewidywalny charakter Internetu.
Korzystając z uznanego testu odświeżania Chrome, otrzymuję czas ładowania dokumentu, który różni się z grubsza 130ms.
źródło
każdy tutaj ma naprawdę dobry punkt. i mają rację we własnym POV.
A wszystko sprowadza się do tego, że nie ma tutaj prawdziwej dokładnej odpowiedzi, ponieważ istnieje tak wiele zmiennych, że każda udzielona odpowiedź zawsze może zostać udowodniona jako niepoprawna przez zmianę jednej ze stu zmiennych.
Podobnie jak opóźnienie 72 ms NY do SF jest opóźnieniem z PoP do PoP nośnika pakietu. Nie bierze to pod uwagę żadnego z innych wspaniałych punktów, które niektórzy wskazywali tutaj na temat przeciążenia, utraty pakietów, jakości usług, pakietów poza kolejnością lub rozmiaru pakietów, lub przekierowania sieci między idealnym światem PoP na PoP .
A potem, kiedy dodasz ostatnią milę (zazwyczaj wiele mil) od PO do swojej rzeczywistej lokalizacji w dwóch miastach, w których wszystkie te zmienne stają się znacznie bardziej płynne, rzeczy zaczynają gwałtownie eskalować z rozsądnej zgadywanki!
Jako przykład przeprowadziłem test między miastem NY a SF w ciągu dnia roboczego. Zrobiłem to pewnego dnia, na całym świecie nie było żadnych „incydentów”, które spowodowałyby gwałtowny wzrost ruchu. Więc może nie było to przeciętne w dzisiejszym świecie! Niemniej jednak był to mój test. W tym okresie faktycznie mierzyłem od jednej lokalizacji firmy do drugiej i podczas normalnych godzin pracy każdego wybrzeża.
W tym samym czasie monitorowałem numery dostawców obwodów w Internecie.
Wynikiem były liczby opóźnień od 88 do 100 ms od drzwi do drzwi w lokalizacjach biznesowych. Nie zawierało to żadnych opóźnień w sieci między biurami.
Opóźnienie sieci dostawcy usług wynosiło od 70 do 80 ms. Oznacza to, że opóźnienie ostatniej mili mogło wynosić od 18 do 30 ms. Nie skorelowałem dokładnych szczytów i spadków między tymi dwoma środowiskami.
źródło
Terminy NYC:
Za pomocą Chrome na połączeniu domowym.
Używanie lft z VPS w centrum danych w Newark, New Jersey:
źródło