Niepoprawnie założyłem, że moje wewnętrzne testy AB oznaczają, że mój serwer może obsłużyć 1k współbieżności @ 3k trafień na sekundę.

Moja teoria w tej chwili jest taka, że ​​sieć stanowi wąskie gardło. Serwer nie może wystarczająco szybko wysłać wystarczającej ilości danych.

Testy zewnętrzne z blitz.io przy 1k współbieżności pokazują, że moje trafienia / s spadają do 180, a strony reagują coraz dłużej, ponieważ serwer jest w stanie zwracać tylko 180 na sekundę.

Podałem pusty plik z nginx i sprawdziłem: skaluje się 1: 1 z współbieżnością.

Teraz, aby wykluczyć wąskie gardła we / wy / memcached (nginx zwykle ściąga z memcached), serwuję statyczną wersję buforowanej strony z systemu plików.

Wyniki są bardzo podobne do mojego oryginalnego testu; Mam ograniczenie do około 180 RPS.

Podział strony HTML na pół daje mi podwójny RPS, więc jest zdecydowanie ograniczony rozmiarem strony.

Jeśli wewnętrznie ApacheBench z serwera lokalnego, otrzymam spójne wyniki około 4k RPS zarówno na całej stronie, jak i na pół stronie, przy wysokich prędkościach transferu. Szybkość transferu: odebrano 62586.14 [kB / s]

Jeśli korzystam z zewnętrznego serwera, otrzymuję około 180 RPS - to samo co wyniki blitz.io.

Skąd mam wiedzieć, że nie jest to celowe ograniczanie?

Jeśli przeprowadzę testy porównawcze z wielu zewnętrznych serwerów, wszystkie wyniki staną się słabe, co prowadzi mnie do przekonania, że ​​problem dotyczy ruchu wychodzącego MOICH serwerów, a nie problemu z prędkością pobierania moich serwerów testowych / blitz.io.

Wracam więc do wniosku, że mój serwer nie może wystarczająco szybko wysłać danych.

Czy mam rację? Czy istnieją inne sposoby interpretacji tych danych? Czy rozwiązaniem / optymalizacją jest skonfigurowanie wielu serwerów + równoważenie obciążenia, z których każdy może obsłużyć 180 trafień na sekundę?

Jestem całkiem nowy w optymalizacji serwera, więc byłbym wdzięczny za wszelkie potwierdzenie interpretacji tych danych.

Ruch wychodzący

Oto więcej informacji na temat przepustowości wychodzącej: Wykres sieci pokazuje maksymalną wydajność 16 Mb / s: 16 megabitów na sekundę. W ogóle nie brzmi dużo.

Z powodu sugestii o ograniczeniu przepustowości przyjrzałem się temu i odkryłem, że linode ma ograniczenie 50 Mb / s (najwyraźniej nawet nie jestem bliski trafienia). Podniosłem go do 100 Mb / s.

Skoro linode ogranicza mój ruch i nawet go nie uderzam, czy to oznacza, że ​​mój serwer powinien rzeczywiście być zdolny do przesyłania do 100 Mb / s, ale jest ograniczony przez inne wewnętrzne wąskie gardło? Po prostu nie rozumiem, jak działają sieci na tak dużą skalę; czy mogą dosłownie wysyłać dane tak szybko, jak potrafią czytać z dysku twardego? Czy rura sieciowa jest tak duża?

Podsumowując

1: W oparciu o powyższe, myślę, że zdecydowanie mogę podnieść mój 180RPS, dodając moduł równoważenia obciążenia nginx na szczycie konfiguracji wielu serwerów nginx z dokładnie 180RPS na serwer za LB.

2: Jeśli linode ma limit 50 / 100mbit, którego w ogóle nie uderzam, musi być coś, co mogę zrobić, aby przekroczyć ten limit dzięki konfiguracji z jednym serwerem. Jeśli potrafię odczytywać / transmitować dane wystarczająco szybko lokalnie, a linode nawet zawraca sobie głowę limitem 50 Mb / 100 Mb, musi istnieć wewnętrzne wąskie gardło, które nie pozwala mi trafić w te ograniczenia, których nie jestem pewien, jak je wykryć. Poprawny?

Zdaję sobie sprawę, że pytanie jest teraz ogromne i niejasne, ale nie jestem pewien, jak je skondensować. Wszelkie uwagi są doceniane na podstawie jakichkolwiek wniosków, które poczyniłem.

Problem polegał na tym, że zakładając, że szczyty wykresu linode.com były prawdziwymi szczytami. Okazuje się, że wykres wykorzystuje średnie 5-minutowe punkty danych, więc mój szczyt wydawał się wynosić 24 bity, kiedy w rzeczywistości osiągałem pułap 50 mbit.

Teraz, kiedy podnieśli go do 100 Mb, moje testy porównawcze natychmiast wzrosły do ​​nowego limitu ruchu wychodzącego.

Gdybym tylko to zauważył wcześniej! Wiele moich rozważań opierało się na pomyśle, że nie osiągam limitu ruchu wychodzącego z powodu tego wykresu.

Teraz osiągam wartość szczytową przy 370 żądaniach na sekundę, czyli dokładnie poniżej 100 Mb / s, w którym to momencie zaczynam otrzymywać „zaległości” żądań i czasy odpowiedzi zaczynają się wydłużać.

Mogę teraz zwiększyć maksymalną współbieżność, zmniejszając stronę; z włączonym gzip dostaję 600RPS.

Nadal mam problemy, gdy nagle osiągam szczyt, a zaległości oczekujących żądań (ograniczone przepustowością) zaczynają się kumulować, ale to brzmi jak inne pytanie.

To była świetna lekcja optymalizacji / czytania tych danych / zawężania możliwych problemów. Dziękuję bardzo za Twój wkład!

Nieco późno, kiedy już to rozgryzłeś ... ale może powinieneś od czasu do czasu przeczytać blog ServerFault.

Myślę w szczególności o tym poście , w którym dyskutują, dlaczego jeden sekundowy interwał sondowania nie skraca go od czasu do czasu, związany z bardzo podobnym problemem do tego, który miałeś ..

Odkryliśmy, że dość często odrzucamy pakiety na interfejsach 1 Gbit / s z szybkością zaledwie 10-30 MBit / s, co negatywnie wpływa na naszą wydajność. Wynika to z faktu, że szybkość 10–30 MBit / s to tak naprawdę liczba bitów przesyłanych w ciągu 5 minut konwertowanych na szybkość jednej sekundy. Kiedy kopaliśmy bliżej za pomocą Wireshark i korzystaliśmy z wykresów IO o wartości milisekundy, widzieliśmy, że często rozbijamy szybkość 1 Mbit na milisekundę tak zwanych interfejsów 1 Gbit / s.

Pewnie zmusiło mnie do myślenia. I po prostu wiem, że po raz pierwszy dostaję to w pozostałych sklepach w moim sklepie. Będę wyglądać wyjątkowo błyskotliwie i spostrzegawczo, gdy napotkamy ten problem.

Kto wie, mogę nawet niektóre z nich ujawnić w tajemnicy. :)

Może być ograniczony przez sieć, ale niekoniecznie po prostu kwestią przepustowości. Opóźnienie zdalnej jednostki testowej będzie miało wpływ na liczbę oczekujących połączeń w danym momencie (oczekiwanie 50 ms na potwierdzenia różni się lokalnie od 0,5 ms), a także na negocjowanie i stabilizację rozmiarów okien w miarę postępu połączenia. Prawdopodobnie jesteś również narażony na pewną utratę pakietów - albo jako funkcję zatoru, albo jako mechanizm ograniczania przepustowości ze strony twojego operatora (lub tych z góry).

Proponuję wyeliminować jak najwięcej z równania, aby narysować rozsądną linię bazową. Zmierz szczytową przepustowość, opóźnienie i utratę pakietów z serwera do kilku punktów w ogólnym Internecie. Choć może się to wydawać mało prawdopodobne, spróbuj wyszukać „Test ruchu VoIP” lub podobny. Kilku dostawców usług VOIP ma aplikacje, które mogą mierzyć tego rodzaju wzorce (dwukierunkowo) z dość dużą dokładnością. Po uzyskaniu prawidłowych danych empirycznych dotyczących rzeczywistej użytecznej prędkości łącza wyniki mogą zostać zweryfikowane.

Oprócz testów przepustowości przydatne może być również przejrzenie przechwytywania pakietów o niedużym ruchu w sieci w celu wyszukania nadmiernej liczby retransmisji, a także zmierzenie pozornego czasu, jaki serwer zajmuje na odpowiedzi na żądania (.. jeśli to wartość rośnie znacznie w zależności od liczby połączeń, to duża wskazówka).