JMeter – Wszystko Co Jest Ci Potrzebne Do Uruchomienia Pierwszych Testów 📌

JMeter jest zaawansowanym narzędziem do testowania wydajności. Na pierwszy rzut oka może nawet odstraszać przez ilość opcji jakie posiada. W praktyce jednak nie wszystkie funkcjonalności są Ci potrzebne. Ba! Bardzo często (szczególnie jak dopiero zaczynasz) potrzebnych jest Ci dosłownie kilka opcji – i właśnie na tym się dziś skupimy! Poznasz najpotrzebniejsze fukncjonalności do wykonania pierwszych testów. A na zaawansowane lekcje przyjdzie jeszcze czas…

W tym artykule skupimy się na funkcjach używanych przy testowaniu aplikacji webowych. Po przeczytaniu dzisiejszego wpisu będziesz wiedział:

• Co to Test Plan
• Czym jest Thread Group
• Do czego służą Samplers
• Jak gromadzić i czytać Metryki

A żebyś lepiej rozumiał co się dzieje przetestujemy wydajność dobrze wszystkim znanego serwisu google.com.

Nie traktuj tego wyniku jako wyznacznika – jest on zależny od kilku czynników jak np. obecne obciążenie serwera, mojej prędkości Internetu,  CPU, itd…

Co to Test Plan

Po pobraniu i uruchomieniu JMeter na swoim komputerze pojawi Ci się następujące okno

Pierwsze co rzuca się w oczy to Test Plan. Jest to po prostu root trzymający wszystkie elementy testów. Możesz go nazwać, choć ja nie spotkałem się jakoś specjalnie z tym aby plany testów były nazywane. Zazwyczaj poszczególne thread group’y dostają odpowiednią nazwę.

Wydaje mi się, że dobrą praktyką jest aby taki plan testów nie zawierał w sobie za dużo testów. No i można zapytać co to znaczy nie za dużo?? Nie umiem na to odpowiedzieć – działaj według swojego gustu. Jeżeli widzisz, że dany test będzie testował ten sam kontekst to moim zdaniem jak najbardziej możesz dołożyć do tego samego planu. Natomiast, jeżeli widzisz że zaczynasz testować inny serwis / obszar to zastanów się czy nie lepiej stworzyć osobny plan testów właśnie dla tego przypadku (i bardzo możliwe, że innych, które mogą się pojawić).

Czym jest Thread Group

Technicznie, Thread Group jest zbiorem wątków wykonujących konkretny scenariusz testowy. Swoim językiem, Thread Group jest użytkownikiem lub grupą użytkowników którzy wykonują ten sam scenariusz testowy.

W JMeter aby stworzyć nowy Thread Group wystarczy kliknąć prawy przycisk myszy na Test Plan, a później Add >> Threads (Users) >> Thread Group. Efektem będzie takie okno

To co jest dla nas interesujące, to Thread Properties:

• Number of Threads (users): reprezentuje całkowitą liczbę użytkowników, którzy będą wykonywali dany scenariusz testowy.
• Ramp-up period (seconds): informuje JMeter, jak długo trzeba czekać aby wszyscy użytkownicy wykonywali testy. Jeśli wprowadzimy 100 użytkownków i ustawimy ramp-up na 50 sekund, to JMeter będzie potrzebował 50 sekund na uruchomienie wszystkich 100 wątków. Czyli co każdą sekundę będą przybywały 2 nowe działające wątki.
  • Wzór na obliczenie ilości nowych użytkownków: Ramp-up Period / Number of Threads. Np. 120/30 = 4 – czyli co 4 sekundy dochodzi nam nowy użytkownik testujący nas scenariusz.
  • Ramp-up needs to be long enough to avoid too large a work-load at the start of a test, and short enough that the last threads start running before the first ones finish (unless one wants that to happen). – dokumentacja JMeter.
• Loop Count: liczba wykonań. Jeśli Loop Count wynosi 2, a liczba wątków 100, to test zostanie uruchomiony 200 razy. Jeśli zostanie zaznaczony checkbox Infinite, nowe wątki będą się uruchamiać do momentu zatrzymania testów.
• Same user on each iteration: pozwala na 'reużycie’ ciasteczek, jeżeli w testach użyty jest HTTP Coockie Manager.
  • Ciasteczka otrzymywane są w pierwszej odpowiedzi a później reużywalne w następnych requestach.

O pozostałych opcjach (Delay Thread creation until needed, Specify Thread lifetime) możesz doczytać googlując je sobie. Na tę chwilę nie jest Ci to potrzebne.

Do przetestowania google.com, użyjemy 100 użytkowników, którzy będą przychodzić co sekundę (ramp-up = 100) i powtórzą akcję 10 razy – czyli łącznie pojedyczny request zostanie uruchomiony 1000 razy.

Do czego służą Samplers

Samplers (próbniki??) są odpowiednikami kontrolerów – wysyłają żadania do serwera i czekają na odpowiedź. Są one przetwarzane w kolejności, w jakiej pojawiają się w drzewie struktury. Można testować wiele usług/protokołów (smtp, ftp, tcp, ldap, jdbc, …) – nas interesuje HTTP Request.

W naszym przypadku chcemy przetestować dwa żądania do usługi google – wyszukiwarkę (google.com) oraz kalendarz (google.com/calendar). Po utworzeniu nowego Sampler’a – HTTP Request – pojawia nam się okno do którego wprowadzamy adres serwera (Server Name or IP), który będziemy testować i ewentualnie ścieżkę (Path) pod jaką znajduje się usługa (w przypadku wyszukiwarki google dajemy tylko adres serwera, dla kalendarza trzeba dodać jeszcze ścieżkę – calendar – jak na screenie)

Jak gromadzić i czytać Metryki

Samo wykonanie testu niewiele nam daje jeżeli nie umiemy określić jego wyniku. Ważne jest aby przed uruchomieniem testów przemyśleć co chcemy mierzyć – pisałem o tym tydzień temu. Jak już znamy wymagania z pomocą przychodzą nam Listenery. Możemy je utworzyć na dowolnym elemencie w naszym drzewie (test plan, thread group, sampler), będą one gromadziły dane z poziomu na którym są i poniższych. Istnieje kilka różnych listenerów, ale to co jest ważne – zapisują one te same dane, różnica polega na tym w jaki sposób te dane są prezentowane.

Nie będziemy wchodzić w szczegóły każdego widoku – zobaczmy jak dla naszego testu wygląda Graph Result i Summary Report (test był wykonany na hot spocie przy słabym połączeniu).

Przy testowaniu wydajności aplikacji webowych to co może nas szczególnie interesować to:

• Throughput – przedstawia jak wydajny jest serwer. Im większa jest przepustowość tym lepiej. Przepustowość jest obliczana na podstawie ilości requestów dzielonej przez całkowity czas wykonania i jest wyrażona w KB/sec.
• Standard Deviation – odchylenie standardowe od normy wyrażane w milisekundach.
• Average – średni czas odpowiedzi, również wyrażany w milisekundach.

W naszych testach od razu rzuca się w oczy że korzystanie z kalendarza Google wymaga większych zasobów. Request zwraca więcej danych, przez co czasy odpowiedzi są dłuższe. Jeślibyśmy spojrzeli do View Result Tree (gdzie można podejrzeć szczegóły każdego z requestów), to zauważymy, że prosty GET do /calendar robi po drodze jeszcze 2 przekierowania (co oczywiście też kosztuje – w kontekście wydajności).

Bardzo ważne – w realnych testach wydajnościowych nie powinniśmy używać Graph Result Listenera:

Graph Results MUST NOT BE USED during load test as it consumes a lot of resources (memory and CPU). Use it only for either functional testing or during Test Plan debugging and Validation.

Podsumowanie

Testowanie wydajnościowe z narzędziem JMeter nie jest wcale takie trudne i straszne. Polecam Ci zacząć powoli (o ile pozwala na to Twoja sytuacja) – od bawienia się ogółami. Jak już ogarniesz podstawy to przechodź do rzeczy bardziej zaawansowanych. Informacji na ten temat jest w Internecie mnóstwo – kwestia, żebyś tylko umiał sprecyzować co chcesz osiągnąć.

Osobiście też się dopiero uczę tego narzędzia i właśnie w taki sposób podchodzę do nauki. Za jakiś czas się okaże co z tego wyjdzie 🙂

Za tydzień

Zmienimy nieco temat i porozmawiamy o metryce, ale innej, potrzebnej deweloperom czyli logach oraz ustawieniach logbacka w spring-boocie.

Btw. Jeżeli masz jakieś uwagi/sugestie co do artykułu, daj znać w komentarzu.