Każdy projekt IT powinien mieć dobrze określone wymagania funkcjonalne. Wydaje mi się, że każdy zgodzi się z poprzednim zdaniem. Niestety już nie każdy pamięta, że oprócz wymagań funkcjonalnych należy również pamiętać o niefunkcjonalnych. Często zapominamy, że oprócz opisu “co system powinien robić” należy dokładnie zaplanować “jak powinien to robić”.

Wymagania niefunkcjonalne opisują właściwości systemu, np. czas reakcji, zajętość pamięci, niezawodność czy wydajność. Niestety czasami określenie tych cech jest dość trudne, właściciel systemu powinien je oszacować na podstawie planu biznesowego czy statystyk dotyczących aktualnego ruchu jego serwisu czy konkurencji. W Kainos kilkukrotnie musieliśmy interweniować i modyfikować gotowe aplikacje z tego względu, że ruch generowany przez użytkowników był niedoszacowany. Dlatego staramy się wprowadzać testy wydajnościowe od samego początku projektu, przedstawiać klientom statystyki odnośnie maksymalnego ruchu i analizować wspólnie wyniki. Aby proces ten szedł jak najsprawniej ruszyliśmy z wewnętrznym projektem Performance Test Academy. Z Inicjatywy Ireneusza Pastusiaka, wspólnie z Michałem Sierzputowskim rozpoczęliśmy pracę nad przygotowaniem dwudniowego kursu dla pracowników Kainos. Kurs skupiał się na JMeterze a obejmował tworzenie scenariuszy testowych, analizę danych, rozproszone uruchamianie testów oraz integrację z CI (TeamCity). Do tej pory przeprowadziliśmy workshopy w połowie Grudnia w Gdańsku i miesiąc później w Belfaście.
 
Myślę, że całkowicie zamknięte szkolenie byłoby jednak niezgodne z polityką otwartej firmy prowadzonej przez Kainos, dlatego zdecydowaliśmy się z Michałem podzielić choć częścią wiedzy i materiałów ze szkolenia na blogu. Tym samym zapraszam na pierwszy wpis z cyklu JMeter.

 

Pierwszy test.
Aby rozpocząc pracę z Jmeterem należy pobrać aplikację:
http://jmeter.apache.org/download_jmeter.cgi
po rozpakowaniu otrzymujemy strukturę katalogów zawierającą wiele skryptów, bibliotek, przykładów i dokumentacji. Jednak zaczniemy od napisania prostego testu. Po odpaleniu aplikacji (bin/jmeter.sh lub bin/jmeter.bat) ukazuje się nam interfejs:
Screen Shot 2016-01-18 at 17.28.16
Aby móc określać ilu wirtualnych użytkowników i przez jaki czas ma testować nasz serwis musimy dodać “grupę wątków” (Thread Group). Wszelkie komponenty testu dodajemy z pozycji menu pod prawym przyciskiem myszy na planie testów w drzewku z lewej strony interfejsu.
Screen Shot 2016-01-18 at 17.30.34
Nasz podstawowy test będzie symulował 10 użytkowników, którzy będą rozpoczynali pracę w odstępie jednosekundowym i każdy przeprowadzi testy pięciokrotnie:
Screen Shot 2016-01-18 at 17.31.58
Następnie musimy określić na czym test będzie polegał, w tym celu dodajemy prosty sampler który będzie wysyłał requesty HTTP (uwaga, sampler dodajemy do stworzonej Grupy Wątków:

 

Screen Shot 2016-01-18 at 17.35.41

w kolejnym widoku określamy adres serwera oraz ścieżkę i ewentualne parametry zapytania. Możemy przykładowo zasymulować użytkowników wyszukujących w google frazy “jmeter” w tym celu ustawiamy:
Server name : google.pl
Path : (puste)
a następnie parametr w sekcji “Parameters” : Add -> Name: q, Value: jmeter
 Screen Shot 2016-01-18 at 17.41.09
W tym momencie stworzyliśmy w pełni funkcjonalny test. Potrzebujemy jednak narzędzie do zobrazowania wyników. Do tego służą Listenery. My użyjemy “View Results Tree”:

Screen Shot 2016-01-18 at 17.43.45

Teraz wystarczy odpalić test zielonym przyciskiem, lub z pozycji menu run->start aby zobaczyć że google całkiem nieźle radzi sobie z takim ruchem ;)

Screen Shot 2016-01-18 at 17.45.15

zielone pozycje w lewym okienku obrazują requesty HTTP, standardowe ustawienia oznaczają odpowiedź 200 OK kolorem zielonym. W przypadku gdyby odpowiedź była inna, byłyby oznaczone na czerwono. Możemy to zasymulować zmieniając adres serwera na nieistniejący (zachęcam do zabawy ;) ). Dodatkowo mamy dostęp do wszelkich informacji o requeście oraz odpowiedzi serwera w prawym okienku pod zakładkami request i response data:
Screen Shot 2016-01-18 at 17.48.43