JMeter – praktycznie zastosowanie

Część ogólna

Apache JMeter jest narzędziem do przeprowadzania testów obciążeniowych (wydajnościowych). Testy te są bardzo ważną częścią każdego serwisu – pozwalają oszacować jak duży ruch jest w stanie obsłużyć nasz serwer www, baza danych itp. Wpis będzie dotyczył wykorzystania JMetera do przeprowadzania testów obciążeniowych np. aplikacji www. Wersja programu – 3.1. Każda z niżej wymienionych opcji dostępna jest po kliknięciu prawym klawiszem myszy.

Na początku musimy zdefiniować grupę wątków. Znajdziemy go w Test plan → Add → Threads (Users) → Thread group

Grupa wątków służy do zarządzania ilością żądań, które będą wysyłane w ciągu jednej sekundy:

Number Of Threads – ilość wątków używanych do wysyłania żądań,
Ramp-Up Period – w ciągu ilu sekund mają zostać wysłane żądania,
Loop Count – ile razy dany test ma się powtórzyć,
Delay Thread creation until needed – bez oznaczonej tej opcji, JMeter przydziela od razu całą pamięć dla wszystkich wątków. Oznacza to, że nawet jeżeli użytkownik wykona swoją próbkę po np. 30 minutach to pamięć będzie dla niego zarezerwowana od razu po uruchomieniu skryptu
Scheduler – możemy ustawić w jaki dzień i o której godzinie chcemy uruchomić test.

Dla przykładu, jeżeli podamy number of thread na 100, ramp-up period na 10, wtedy na każdą sekundę będzie wysyłanych 10 użytkowników (żądań).

Następnym krokiem będzie skonfigurowanie testu dla wcześniej utworzonej grupy wątków. Jako, że żądania JMetera są ubijane przez wiele serwisów (brak odpowiedniej identyfikacji), na początku należy skonfigurować nagłówek z User-Agent. Znajdziemy go w Thread Group → Add → Config Element → HTTP Header Manager.

Kolejnym krokiem będzie zdefiniowanie domyślnego adresu url. Jest to o tyle ważne, że usprawnia proces zmiany głównej ścieżki. Może zmienić się nazwa domeny z np. teststrona.pl na testowy.pl. Jeżeli nie przygotowalibyśmy domyślnego adresu należałoby zmienić adres w każdym kroku testu gdzie wykonujemy żądania na sprecyzowany adres url np. test.pl/home. Znajdziemy go w Thread Group → Add → Config Element → HTTP Request Defaults.

Jeżeli chcemy, aby każde żądanie pobierało nam dodatkowo zawartość dynamiczną strony (zdjęcia, js itp.), należy w HTTP Request Default lub w każdym HTTP Request z osobna, oznaczyć Retrieve All Embedded Resources. Parallel Downloads wskazuje ile ma być równolegle pobieranych zasobów, a URLs must match wskazujemy z jakiego adresu url chcemy pobierać zasoby.

Dla przykładu wysłałem dwa żądania na ten sam adres url. Jeden pobiera zawartość dynamiczną a drugi statyczną:

Następnie definiujemy Random Controller. Dodajemy go w celu zwiększenia losowości wykonywanego testu. Po jego użyciu wybierana jest tylko jedna akcja z kilku dostępnych w ramach danego wątku w określonym teście. Thread Group → Add → Logic Controller → Random Controller.

Dla Random Controllera dodajemy HTTP Request. Służą one do wskazywania na jaki adres url mają być wysyłane żądania. W poprzednim kroku zdefiniowaliśmy HTTP Request Default, więc teraz pozostaje wskazać już tylko ścieżkę docelową. Thread Group → Add → Sampler → HTTP Request

Dodatkowo w tym miejscu możemy definiować:

protocol – jaki to jest protokół tzn http/https,
method – jaką metodą ma być wysyłane żądanie dla zasobu (GET, POST itp.),
path – podajemy tutaj naszą docelową ścieżkę,
parameters/body data – możemy przekazać dodatkowe parametry/dane

Bardzo ważnym elementem są również słuchacze. Zbierają one różne dane o próbkach (żądaniach), w zależności od wybranego elementu. Oczywiście można wybrać każdy z nich: Thread Group → Add → Listener → View Results in Table

Należy pamiętać, że dużym ograniczeniem dla JMeter-a są zasoby oraz łącze. Podczas działania testu zużywane są spore zasoby pamięci ram oraz łącza.

Uruchamianie JMeter-a poza GUI

Komendą do uruchamiania JMeter-a poza GUI jest:

sh jmeter -n -t /home/dawid/testObciazeniowy.jmx

Aby uruchomić test tą komendą musimy znajdować się w katalogu gdzie zainstalowaliśmy Apache JMeter → bin

Bardzo ważne są domyślne ograniczenia Javy, które wynoszą raptem 1 GB pamięci ram. Z doświadczenia wiem, że jest to bardzo mało, jeżeli chcemy zasymulować duży ruch. W przypadku gdy chcemy ustawić większą ilość pamięci dla procesów Javy wykonujemy nasz skrypt z dodatkowymi parametrami:

JVM_ARGS="-Xms16384m -Xmx16384m -XX:NewSize=8192m -XX:MaxNewSize=8192m" && export JVM_ARGS && sh jmeter -n -t /home/dawid/testObciazeniowy.jmx 

Dodatkowo nie uruchamiając testu poprzez GUI możemy otrzymać jego wynik w pliku. Należy do naszej komendy dodać jeszcze jeden parametr. Finalna komenda wygląda następująco:

JVM_ARGS="-Xms16384m -Xmx16384m -XX:NewSize=8192m -XX:MaxNewSize=8192m" && export JVM_ARGS && sh jmeter -n -t /home/dawid/testObciazeniowy.jmx -l /home/dawid/wynikTestu.csv 

Uruchomienie skryptu – widok terminal:

Wynik w postaci pliku csv:

Wyniki testu

Poniżej przedstawię wyniki testu, który przeprowadzałem na jednym z naszych sklepów. Narzędzie wykorzystane do rejestrowania ruchu to relic. Jak widać na screenie ruch wyrażony jest w rpm czyli „requests per minute” (żądania na minutę):

Podsumowanie testu w pliku prezentuje się w następujący sposób:

Screen jest podglądowy, ogółem wszystkich wierszy jest dużo więcej.

Autorem tekstu jest Dawid Adamczyk.

Zdjęcie od: AltumCode na Unsplash