Testowanie wydajności web aplikacji

Obecnie na rynku można spotkać wiele różnych rozwiązań służących do testowania wydajności: ab, jmeter, httperf . W mojej opinii każde z nich jest dobre pod warunkiem, że dobierzemy je do naszych potrzeb.

Ostatnio potrzebowałem przetestować niewielką web aplikację i wystarczającym narzędziem było dla mnie narzędzie o nazwie siege.

Trochę bardziej rozbudowane od ab, lecz z mniejszą ilością funkcji niż jmeter.

Najważniejsze flagi

• -c - Ilość symulowanych użytkowników
• -r - Ilość powtórzeń wysyłanego requesta
• -i - Losowo pobiera strony określone w pliku urls.txt
• -t - Pozwala prowadzić test przez określony czas
• -v - Wyświetla nagłówki HTTP i żądania GET w czasie testu
• -d - Losowe opóźnienie w wysyłaniu requesta przez symulowanego użytkownika, od 0 do X sekund.

Przykłady użycia

siege -c 50 -r 10 http://app.teamrock.pro/api/v1/auth/register

Ilość wysłanych requestów = -c (ilość użytkowników) * -r (ilość requestów per użytkownik)

siege -t60s -c 20 -d 10 http://app.teamrock.pro/api/v1/auth/register

Przez 60 sekund symuluj 20 użytkowników, którzy robią odstępy średnio od 0 do 10ciu sekund w wysyłanych requestach

siege -t 60s -c 20 -d 10 — header=”Authorization:Bearer JWT TOKEN” 'http://app.teamrock.pro/api/v1/company'

Przez 60 sekund symuluj 20 użytkowników którzy robią odstępy średnio od 0 do 10ciu sekund w wysyłanych requestach, uwierzytelniając się za pomocą tokenu JWT

Strategia testowania

Wykonujemy kilka testów, za każdym razem zwiększając parametr symulowanych użytkowników (-c), czy też ilości requestów (-r).

Przy każdym teście sprawdzamy, czy parametr Availability nie spada oraz czy ilość błędnych transakcji nie rośnie Failed transactions. Warto też sprawdzić, ilość requestów ze statusem 200 Successful transactions

Może się zdarzyć, że raport nie wykazał błędnych transakcji, lecz ilość transakcji ze statusem 200 nie pokrywa się z wartością parametru Availability. Może to oznaczać wysyłanie przez serwer requestów z innymi statusami takimi jak 4xx. Dobrze jest więc włączyć flagę -v, aby sprawdzać na bieżąco jakie requesty zostały wysłane oraz jakie mają statusy.

Laravel, a testowanie wydajności

Jeżeli korzystacie z frameworka Laravel, to od wersji 5 standardowo ma włączoną opcje Throttle. Oznacza to tyle, że blokuje zbyt dużą ilość requstów z jednego IP przez co testy mogą nie przechodzić poprawnie.

Aby zmienić tą opcje należy w pliku app/Http/Kernel.php zmienić parametr throttle:60,1, gdzie pierwszy parametr to limit ilości requestów, natomiast drugi to czas podawany w minutach. Czyli w przeciągu jednej minuty można wysłać 60 requestów z jednego IP na podany url.

Dla bardziej zainteresowanych polecam sprawdzić nagłówki. Zauważycie tam dwa parametry określające limit jak i ilość pozostałych requstów, które mogą zostać przesłane.

X-RateLimit-Limit → 60
X-RateLimit-Remaining → 52

Natomiast po przekroczeniu limitu dostaniemy odpowiedź z serwera

HTTP/1.1 429 Too Many Requests

Poniżej kilka linków z których czerpałem wiedzę

http://work.stevegrossi.com/2015/02/07/load-testing-rails-apps-with-apache-bench-siege-and-jmeter/

https://kalamuna.atlassian.net/wiki/spaces/KALA/pages/16023587/Testing+With+Apache+Benchmark+and+Siege

https://drupalize.me/blog/201507/load-testing-your-site-siege

http://www.linux.rk.edu.pl/w/p/siege-i-httperf-testowanie-serwerw/

http://ideas2action.pl/2012/09/13/tech-jak-testowac-wydajnosc-sklepu-internetowego/

https://mattstauffer.com/blog/api-rate-limiting-in-laravel-5-2/

https://www.cloudways.com/blog/laravel-and-api-rate-limiting/