Debugowanie niskiej prędkości transferu z serwera


9

Staram się wyjaśnić to tak prosto, ale jak najlepiej udokumentowane. Nie dotyczy to wyłącznie tego serwera ani mojego obecnego dostawcy usług internetowych . Przez lata widziałem ten sam dokładny problem, będąc z różnymi dostawcami usług internetowych i mając swoje serwery u różnych dostawców (GoDaddy w USA, iWeb i GloboTech w Kanadzie). Jedyną powszechną rzeczą jest system operacyjny Windows Server (2003 i 2008 R2). Ale spójrzmy teraz na mój obecny serwer i mojego obecnego ISP.

Problem :

Otrzymuję bardzo niskie prędkości transferu między moją lokalną stacją roboczą a moim zdalnym serwerem dedykowanym. Mój serwer jest na porcie 100 Mbps, a moja lokalna stacja robocza jest na symetrycznym połączeniu 50 Mbps przez światłowód.

Objawy :

Zarówno serwer, jak i stacja robocza uzyskują doskonałe wyniki (bardzo zbliżone do prędkości połączenia) podczas przeprowadzania testów na speedtest.net na różnych serwerach i lokalizacjach w Stanach Zjednoczonych i Meksyku. Jeśli pobieram duże pliki, powiedzmy Dropbox, na mój serwer lub stację roboczą, uzyskuję prędkości transferu odpowiednio 10 MB / s i 5 MB / s na jednym połączeniu, co jest poprawne w zależności od prędkości połączenia 100 Mb / s i 50 Mb / s odpowiednio

Jednak jeśli przesyłam plik z mojego serwera (przez HTTP lub FTP) na moją stację roboczą, nie zbliżam się nawet do prędkości 50 Mb / s, którą powinienem uzyskać (szybkość transferu 5 MB / s), ale zamiast tego otrzymuję coś równoważnego 3 Mb / s (Szybkość transferu 300 KB / s).

Próbuję zrozumieć, dlaczego otrzymuję tak niski współczynnik transferu. Nie jestem pewien, jak to debugować. Ilekroć podnoszę zgłoszenie problemu z dostawcami usług hostingowych, pytają mnie o wyniki tracert i w końcu po prostu winią to na jakimś serwerze pośrodku. Ale to nie wydaje się poprawne, jeśli weźmiemy pod uwagę to, co powiedziałem na początku: widziałem tę dokładną prędkość / problem, mając moje serwery z GoDaddy, iWeb i GloboTech, i będąc sobą z różnymi dostawcami usług internetowych różne rodzaje usług internetowych . To naprawdę wygląda na ustalone ustawienie gdzieś w obszarze serwera.

Testy, które wykonałem :

TEST PRĘDKOŚCI

Są to testy prędkości z speedtest.net, które zostały przeprowadzone na moim serwerze dedykowanym dla różnych serwerów zdalnych, w tym serwera w centrum danych mojego dostawcy usług internetowych w Meksyku:

Kanada : 94,64 Mb / s do pobrania i 94,87 do przesłania http://www.speedtest.net/my-result/3470801975

San Jose, Kalifornia : 93,58 Mb / s do pobrania i 95,48 Mb / s do przesłania http://www.speedtest.net/my-result/3470805341

Mexico City (serwer we własnym kamerze danych ISP) : 92,99 Mb / s do pobrania i 95,39 Mb / s do przesłania http://www.speedtest.net/my-result/3470810269

Jeśli uruchomię te testy na tych samych serwerach z mojej lokalnej stacji roboczej, uzyskam prędkości zbliżone do mojego połączenia 50 Mb / s.

TRACERT

Oto ostatnie wyjście tracert wykonane z mojej stacji roboczej na mój serwer dedykowany:

 1    <1 ms    <1 ms    <1 ms  192.168.7.254
 2     2 ms     1 ms     1 ms  10.69.32.1
 3     *        3 ms     2 ms  10.5.50.174
 4     3 ms     2 ms     2 ms  10.5.50.173
 5     *        5 ms     3 ms  fixed-203-69-2.iusacell.net [189.203.69.2]
 6    32 ms    32 ms    32 ms  8-1-33.ear1.Dallas1.Level3.net [4.71.220.89]
 7    33 ms    33 ms    33 ms  ae-3-80.edge5.Dallas3.Level3.net [4.69.145.145]
 8    33 ms    33 ms    33 ms  ae13.dal33.ip4.tinet.net [77.67.71.221]
 9    76 ms    76 ms   157 ms  xe-1-0-0.mtl10.ip4.tinet.net [89.149.185.41]
10    72 ms    72 ms    72 ms  te2-2.cr2.mtl3.gtcomm.net [67.215.0.160]
11    72 ms    72 ms    72 ms  ae2.csr2.mtl3.gtcomm.net [67.215.0.134]
12    72 ms    72 ms    73 ms  te3-4.dist1.mtl8.gtcomm.net [67.215.0.83]
13    72 ms    72 ms    72 ms  ns1.marveldns.com [173.209.57.82]

IPERF

To jest test iperf wykonywany przy użyciu mojego serwera dedykowanego jako serwera i mojej stacji roboczej jako klienta:

------------------------------------------------------------
Client connecting to ns1.marveldns.com, TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.7.2 port 60339 connected with 173.209.57.82 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.3 sec  5.62 MBytes  4.59 Mbits/sec

ŚCIEŻKA

Oto wynik polecenia pathping wykonanego z mojej stacji roboczej na mój serwer dedykowany:

Tracing route to ns1.marveldns.com [173.209.57.82]
over a maximum of 30 hops:
  0  ws1 [192.168.7.2]
  1  192.168.7.254
  2  10.69.32.1
  3     *     10.5.50.174
  4  10.5.50.173
  5  fixed-203-69-2.iusacell.net [189.203.69.2]
  6  8-1-33.ear1.Dallas1.Level3.net [4.71.220.89]
  7  ae-3-80.edge5.Dallas3.Level3.net [4.69.145.145]
  8  ae13.dal33.ip4.tinet.net [77.67.71.221]
  9  xe-1-0-0.mtl10.ip4.tinet.net [89.149.185.41]
 10  te2-2.cr2.mtl3.gtcomm.net [67.215.0.160]
 11  ae2.csr2.mtl3.gtcomm.net [67.215.0.134]
 12  te3-4.dist1.mtl8.gtcomm.net [67.215.0.83]
 13  ns1.marveldns.com [173.209.57.82]

Computing statistics for 325 seconds...
            Source to Here   This Node/Link
Hop    RTT  Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           ws1 [192.168.7.2]
                                0/ 100 =  0%   |
  1    0ms     0/ 100 =  0%     0/ 100 =  0%  192.168.7.254
                                0/ 100 =  0%   |
  2    1ms     0/ 100 =  0%     0/ 100 =  0%  10.69.32.1
                                0/ 100 =  0%   |
  3    3ms     0/ 100 =  0%     0/ 100 =  0%  10.5.50.174
                                0/ 100 =  0%   |
  4    2ms     0/ 100 =  0%     0/ 100 =  0%  10.5.50.173
                                0/ 100 =  0%   |
  5    4ms    20/ 100 = 20%    20/ 100 = 20%  fixed-203-69-2.iusacell.net [189.203.69.2]
                                0/ 100 =  0%   |
  6   34ms     0/ 100 =  0%     0/ 100 =  0%  8-1-33.ear1.Dallas1.Level3.net [4.71.220.89]
                                0/ 100 =  0%   |
  7   34ms     0/ 100 =  0%     0/ 100 =  0%  ae-3-80.edge5.Dallas3.Level3.net [4.69.145.145]
                                0/ 100 =  0%   |
  8   33ms     0/ 100 =  0%     0/ 100 =  0%  ae13.dal33.ip4.tinet.net [77.67.71.221]
                                0/ 100 =  0%   |
  9   79ms     0/ 100 =  0%     0/ 100 =  0%  xe-1-0-0.mtl10.ip4.tinet.net [89.149.185.41]
                                2/ 100 =  2%   |
 10   73ms    14/ 100 = 14%    12/ 100 = 12%  te2-2.cr2.mtl3.gtcomm.net [67.215.0.160]
                                0/ 100 =  0%   |
 11   72ms     2/ 100 =  2%     0/ 100 =  0%  ae2.csr2.mtl3.gtcomm.net [67.215.0.134]
                                2/ 100 =  2%   |
 12   72ms    18/ 100 = 18%    14/ 100 = 14%  te3-4.dist1.mtl8.gtcomm.net [67.215.0.83]
                                0/ 100 =  0%   |
 13   72ms     4/ 100 =  4%     0/ 100 =  0%  ns1.marveldns.com [173.209.57.82]

Trace complete.

Rzeczy, których możesz spróbować sam

Jeśli chcesz spróbować, oto kilka rzeczy, które skonfigurowałem na serwerze do celów testowych:

Duży plik na serwerze HTTP

Na moim serwerze umieściłem plik 5 GB, który można pobrać przez HTTP. Można go znaleźć tutaj: http://www.marveldns.com/transfer_test/

Aplikacja Speedtest MINI

Na moim serwerze skonfigurowałem test „speedtest mini”. Możesz go odwiedzić i zobaczyć, jaką prędkość otrzymujesz zarówno do pobrania, jak i przesłania na mój serwer i siebie. Można go znaleźć tutaj: http://www.marveldns.com/speedtest/

Wreszcie :

Jak powiedziałem wcześniej, staram się uzyskać pomoc w zrozumieniu tego wszystkiego. Nie jestem ekspertem od TCP / IP ani sieci top-end. Szczerze mówiąc, nie mam nawet jasności, jak korzystać z wyników tracert, iperf lub pingpath, aby rozwiązać problem, ale uwzględniam je, ponieważ zawsze jestem o to proszony, kiedy mówię o tym problemie.

Jeśli w moim pytaniu brakuje czegoś lepszego, nie głosuj tylko i daj mi znać, co jest z nim nie tak lub co jeszcze mogę dodać, aby uzyskać pomoc. Dziękuję Ci.


tylko dlatego, że jestem ciekawy, jaką szybkość masz, kiedy zapominasz o pliku na localhost na serwerze dedykowanym?
Brice

Cześć Brice. Dostaję około 50 MB / s (bajtów, a nie bitów), co jest prawie taką samą prędkością, jaką otrzymuję, jeśli ręcznie kopiuję plik do tego samego folderu na tym samym dysku bezpośrednio w Eksploratorze Windows (więc jest to ograniczone przez szybkość dysk podczas odczytu i zapisu do siebie).
Francisco Zarabozo

1
Według tracert, twoja stacja robocza jest w dość dużej sieci. Czy próbowałeś zapytać administratora sieci lokalnej, czy istnieje jakiś Qos spowalniający połączenia?

Jeśli uruchomisz wiele transferów jednocześnie, czy łączna prędkość sumuje się w pobliżu oczekiwanych 50 Mb / s? to znaczy. Czy ogólnie jest wolny, czy wolny na połączenie?
Udziel

@Grant: Przy wielu połączeniach reklamuje do 50 Mb / s. Limit występuje na połączenie.
Francisco Zarabozo

Odpowiedzi:


9

Wąskie gardło, które widzę podczas uzyskiwania dostępu do tego adresu URL, jest wyraźnie spowodowane rozmiarem okna.

Kiedy próbuję pobrać z twojego serwera, otrzymuję 555 KB / s. Mam czas w obie strony 108ms. Robiąc matematykę, otrzymuję następujący rozmiar okna: 555 KB / s * 108 ms = 59,94 KB.

Tak długo, jak robię to z hosta w centrum danych, otrzymuję bardzo spójną przepustowość i transport w obie strony. Dodatkowo, jeśli zacznę dwa pobieranie równolegle, każdy dostanie 555 KB / s. Właśnie takie objawy zobaczysz, gdy wąskim gardłem jest rozmiar okna.

Bez skalowania okna okno nie może być większe niż 64 KB. Ale widzę, że skalowanie okien jest negocjowane, więc powinna być możliwa większa przepustowość. Pozostawia to dwie hipotezy do zbadania:

  • Coś zakłóca opcję skalowania okna na ścieżce od klienta do serwera, przez co serwer myśli, że okno jest skalowane 1-krotnie.
  • Serwer może być skonfigurowany tak, aby nigdy nie używał okna wysyłania większego niż 60 KB na każde połączenie.

Pierwszy jest łatwy do zweryfikowania, czy można wykonać przechwytywanie pakietów na serwerze. Wystarczy spojrzeć na opcję skalowania przychodzących pakietów SYN, aby dowiedzieć się, czy serwer otrzymuje współczynnik skalowania większy niż jeden. Mogę polecić użycie Wireshark do analizy ruchu.

Weryfikacja drugiej hipotezy wymaga pewnej wiedzy na temat używanego systemu operacyjnego. Zdarzyło się, że wybrałeś nieznany mi system operacyjny, więc nie mogę pomóc. Mogę więc pomóc tylko ze specjalistyczną wiedzą w zakresie sieci.


Nie jestem w 100% pewien, ale czy na rozmiar okna nie ma wpływu rozmiar bufora wysyłania i odbierania przez gniazdo (opcje gniazda SO_RVSBUF i SO_SNDBUF)? Widziałem podobne zdarzenia, w których bufor był zbyt mały (np. 1KB), a przepustowość była bardzo ograniczona w porównaniu do 4KB lub 8KB).
Cameron Kerr

@CameronKerr Twój komentarz skłonił mnie do ponownego przyjrzenia się komunikacji. Tym razem przetestowałem na moim laptopie (który jest na Wi-Fi i ma niższą przepustowość). Zauważyłem, że uzyskuję 138 KB / s przy 105 ms w obie strony. Oznacza to, że efektywny rozmiar okna wynosi 14,5 KB. Okno odbioru reklamowane przez mojego laptopa wzrosło do 679 << 7 (około 85 KB), zanim ustabilizowała się przepustowość. To powinno wykluczyć możliwość, że współczynnik skalowania został po prostu wyzerowany w transporcie i wykluczyć możliwość ograniczenia przepustowości przez bufor odbiorczy po mojej stronie.
kasperd

Odpowiedni artykuł dla systemu Windows Server 2008 R2 można znaleźć tutaj: andydavies.me/blog/2011/11/21/...
Francisco Zarabozo
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.