Określanie realistycznej miary żądań na sekundę dla serwera WWW

15

Przed uruchomieniem konfiguruję stos nginx i optymalizuję konfigurację. Uruchamiając ab, aby przetestować maszynę w warunkach skrajnych, byłem rozczarowany, widząc, że wszystko osiąga szczyt przy 150 żądaniach na sekundę, a znaczna liczba żądań zajmuje> 1 sekundę. Co dziwne, sama maszyna nawet nie oddychała ciężko.

W końcu pomyślałem o pingowaniu pudełka i zobaczyłem czasy pingowania około 100-125 ms. (Ku mojemu zaskoczeniu maszyna jest w całym kraju). Wygląda więc na to, że w moich testach dominują opóźnienia sieci. Uruchomienie tych samych testów z komputera w tej samej sieci co serwer (czasy ping <1ms) i widzę> 5000 żądań na sekundę, co jest bardziej zgodne z tym, czego oczekiwałem od komputera.

Ale to sprawiło, że pomyślałem: jak określić i zgłosić „realistyczną” miarę żądań na sekundę dla serwera WWW? Zawsze widzisz stwierdzenia dotyczące wydajności, ale czy nie należy brać pod uwagę opóźnień w sieci? Jasne, że mogę obsłużyć 5000 żądań na sekundę na maszynie obok serwera, ale nie na maszynie w całym kraju. Jeśli mam dużo wolnych połączeń, ostatecznie wpłyną one na wydajność mojego serwera, prawda? Czy też myślę o tym źle?

Wybacz, jeśli to 101 inżynierii sieci. Z wykształcenia jestem programistą.

Aktualizacja: Edytowane dla przejrzystości.

— Don
źródło

abma opcję współbieżności. Co to ustawiłeś? Ponadto, jeśli testujesz z krajowego połączenia ADSL, test prawdopodobnie będzie zdominowany przez twoje pasmo i w ogóle nie będzie testował niczego na serwerze.

— Ladadadada

Znam opcję współbieżności ab i wypróbowałem szeroki zakres wartości, aby odkryć granice skrzynki. Jak napisałem powyżej, rozumiem, że moje pierwsze testy były zdominowane przez sieć i nie odzwierciedlały możliwości serwera. Ale wciąż mam pytanie: skąd większość ludzi przeprowadza testy, aby uzyskać realistyczne dane? Testy uruchamiane z urządzenia w tej samej sieci co serwer (skutecznie usuwając wszelkie opóźnienia sieci z równania) zwracają wielkie liczby, ale nie wydają się być „uczciwymi” liczbami, ponieważ prawdziwi użytkownicy będą pochodzić spoza sieci.

— Don

Testy przeprowadzane z tej samej sieci mogą w rzeczywistości być bardziej „uczciwe”, ponieważ zasadniczo ignorują sieć. Twoi użytkownicy prawdopodobnie są w różnych sieciach - więc łączna przepustowość wszystkich tych sieci powinna łatwo przekroczyć dostępną przepustowość serwera. Biorąc pod uwagę wszystkich użytkowników razem, wąskim gardłem są zatem możliwości serwera - podczas gdy biorąc pod uwagę pojedynczego użytkownika, wąskim gardłem może być przepustowość pojedynczego użytkownika. (Być może idealny test zostałby przeprowadzony z wielu odległych lokalizacji w celu najlepszej symulacji rzeczywistych okoliczności, chociaż większość przypadków nie powinna tego wymagać).

— cyberx86

„Biorąc pod uwagę wszystkich użytkowników razem, wąskim gardłem są zatem możliwości serwera” - to ma sens i wydaje się być właściwym sposobem myślenia o tym. Podejrzewam, że serwer może siedzieć za kiepskim sprzętem sieciowym, ograniczając jego szybkość reakcji do świata zewnętrznego, ale tak naprawdę nie jest to problem serwera i należy go rozwiązać osobno. Coś jak Pingdom mogłyby zostać wykorzystane do uruchomienia testu idealnego, jak sądzę.

— Don

3

Jeśli zależy ci na wydajności twojego serwera, gdy jest dostępny z dowolnego miejsca na świecie, poproś znajomego gdzieś na świecie (powinien mieć dobre pasmo), aby zainstalował sproxy + oblężenie na swoim Linux- ie . Wystarczy pobrać, skonfigurować, zrobić. Te narzędzia są małe, kompilują się w ciągu kilku sekund.

Najpierw zacznij sproxyod Linuksa. Domyślnie będzie działał na porcie 9001 na localhost (127.0.0.1). Jeśli chcesz uzyskać do niego dostęp z zewnątrz, po prostu przekaż mu wychodzący adres IP jako parametr.
Teraz połącz się ze sproxy, ustawiając przeglądarkę tak, aby używała tego adresu IP i portu jako serwera proxy dla HTTP. Wszystko, co robisz od teraz, jest rejestrowane przez sproxy i może być odtworzone później. Teraz surfuj po swojej witrynie, rób to, co robili Twoi klienci i próbuj robić „drogie” rzeczy, które wykorzystują Twój serwer.
Po zakończeniu zakończ sproxy, naciskając CTRL ^ C. Zapisał twoje działania do $HOME/urls.txt. Przenieś plik do miejsca, w którym znajduje się oblężenie. Aby rozpocząć testy warunków skrajnych, uruchom siege -f urls.txt -d NUM -c NUM. doznacza opóźnienie między żądaniami, wykonując testy wydajności, użyj 1 (sekundy).coznacza liczbę symulowanych jednoczesnych użytkowników. Wybierz wedle woli, ale zacznij od niskiej. Oblężenie pokaże liczbę transakcji na sekundę, wskaźnik błędów, czas potrzebny na uśrednienie żądań itp. Jest to potężne i łatwe w użyciu narzędzie.
Jeśli potrzebujesz więcej informacji na temat parametrów (jest ich wiele), sprawdź oblężenie obsługi AN sproxy instrukcja

Aby uzyskać bardziej realistyczne wyniki, pozwól wielu osobom przetestować Twój serwer z różnych krajów jednocześnie i pozwól im przesłać statystyki.

— SebiF
źródło

2

Realistyczne żądania / sekundę należy pobrać z dzienników dostępu. IMO, opóźnienie żądania nie ma nic wspólnego z obciążeniem serwera, ponieważ serwer przetwarza wszystkie żądania z tą samą prędkością bez względu na ich pochodzenie.

— ejaenv
źródło

1

Rozważ skorzystanie z usług takich jak Soasta Cloudtest . Dzięki niemu możesz uzyskać dość szczegółowe raporty z testów i możesz przeprowadzać testy wydajności od różnych dostawców publicznej chmury / wirtualizacji. Możesz skonfigurować, jak mocno i na jak długo chcesz młotkować swoje serwery. Mają także bezpłatną wersję „ lite ”, dzięki czemu możesz zobaczyć, co można zrobić przed dokonaniem jakichkolwiek pieniędzy.

— Mxx
źródło