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…


Jmeter-all

W tym artykule skupimy si臋 na funkcjach u偶ywanych przy testowaniu aplikacji webowych. Po przeczytaniu dzisiejszego wpisu b臋dziesz wiedzia艂:

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

jmeter-test-plan

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.

Thread Group

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

Nowy Thread Group

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 鈥歳eu偶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.

Google Thread Group Test


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.

Samplers

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偶nezapisuj膮 one te same dane, r贸偶nica polega na tym w jaki spos贸b te dane s膮 prezentowane.

Listners

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).

Google Graph Result Test

Google Summary Report Test

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).

Google Calendar View Result Tree

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.

0 0 vote
Article Rating
Tagi:
Subscribe
Powiadom o
guest
2 komentarzy
najnowszy
najstarszy oceniany
Inline Feedbacks
View all comments
Space Invader
Space Invader
1 miesi膮c temu

Cze艣膰
Ciekawy wpis. Co my艣lisz o tym aby go rozwinac o sprawdzanie rezultatu odpowiedzi?
Przyk艂adowo jakiego艣 rodzaju uwierzytelnianie, sprawdzenie kodu 200, sprawdzenie konkretnego komunikatu po uwierzytelniania. Wywo艂anie ci膮gu us艂ug/stron z badaniem rezultatu.
Dawno temu odpali艂alem jmeter i mia艂em przypadek 偶e przy du偶ym obci膮偶eniu zacz臋艂y lecie膰 500setki.
Pozdro