Budując nowy serwis internetowy, stawiając różne usługi na serwerze warto jest przetestować nowe rozwiązania pod względem wydajności. Przydatna do tego będzie aplikacja Apache JMeter napisana w Javie. Program Apache JMeter jest zaawansowanym systemem do mierzenia wydajności obiektów statycznych oraz dynamicznych (np. plików, servletów, klas Javy, serwerów HTTP i FTP itd.). Umożliwia testowanie wydajności, poprawności, wytrzymałości na duże obciążenie oraz analizę otrzymanych danych.

Dodatkowo aplikacja potrafi testować bazy danych za pomocą JDBC. Aby przeprowadzać testy JDBC, musimy dodać sterowniki naszej bazy danych do classpath JMeter. Możemy również wygenerować dowolny ruch TCP, pobierać dane z usługi LDAP, wywoływać Webservices oraz JMS.

Program potrafi również testować serwisy oraz usługi internetowe w celu znalezienie błędów regresyjnych. Błędy takie najczęściej pojawiają się po wprowadzeniu zmian w usługach i serwisach (np. zmiana w kodzie aplikacji). Zazwyczaj wykonywanie testów regresyjnych związane jest z ponownym uruchomieniem zestawu testów, które wcześniej kończyły się poprawnie. Ma ono na celu ujawnienie potencjalnych problemów powstałych na skutek dokonanych zmian.

Instalacja

Aby zainstalować JMeter należy posiadać zainstalowane Java SE Development Kit (JDK), oraz ustawioną zmienną JAVA_HOME. Teoretycznie wystarczy JDK 1.3, aczkolwiek autorzy podręcznika użytkownika zalecają korzystanie z JDK1.4 lub nowszych.

Aplikacja dostępna jest do pobrania ze strony: jakarta.apache.org. Po pobraniu paczki z aplikacją, należy ją rozpakować i uruchomić za pomocą pliku jakarta-jmeter-2.3.2\bin\jmeter.sh.

Zgodnie z zapewnianiami ekipy rozwijającej JMeter, działanie tego narzędzia zostało przetestowane (i jest poprawne) na platformach Solaris, Linux, wszelkich systemach typu Unix, jak również Windows (98, NT, 2000, XP).

Pierwsze uruchomienie

Po uruchomieniu aplikacji pojawi nam się GUI aplikacji. Za pomocą tego interfejsu stworzymy plan testu wydajnościowego składającego się z wielu zapytań HTTP.

JMeter - Test Plan

Budowanie przebiegu testu wydajnościowego będziemy wykonywać w polu Test Plan. Jeżeli nie chcemy przeprowadzać interakcyjnego testowania, możemy wczytać testy z pliku i zapisać wyniki do innego pliku. Możemy wówczas uruchomić JMeter w trybie wsadowym, nie korzystającym z interfejsu GUI. W tym celu należy skorzystać z opcji:

  • -n – uruchomienie w trybie bez GUI
  • -t plik_JMX – określa plik zawierający Test Plan
  • -l plik_JTL – określa plik do którego zostaną zapisane rezultaty przeprowadzonych testów

Możliwe jest również wykonywanie testów rozproszonych. Dla celów wykonywania testów rozproszonych, należy uruchomić JMeter w trybie serwerowym, i kontrolować każdy z serwerów poprzez GUI. W tym celu należy wykonać skrypt jmeter-server, znajdujący się w katalogu bin.

Budowanie testu wydajnościowego

Rozpoczynając budowanie klikamy prawym przyciskiem myszki na Test Plan. Dodajemy kolejno komponenty w zależności od tego jaki test chcemy przeprowadzić na serwerach. Następnie wybieramy opcje:

  1. Add → Thread Group – element odpowiedzialny za ilość użytkowników jacy będą wywoływać zapytania HTTP na serwerze.
  2. Add → Config Element → HTTP Authorization Manager – element odpowiedzialny za uwierzytelnienie HTTP do serwera integracyjnego.
  3. Add → Sampler → HTTP Request – element odpowiedzialny za kliknięcie. Komponent generuje zapytanie GET / POST po protokole HTTP.
  4. Add → Assertion → Response Assertion – ustawiamy warunek dla poprawności wykonania się testu zapytania HTML.
  5. Add → Listner → Aggregate Report – agreguje wyniki wyżej wygenerowanego testu.
  6. Add → Listener → Assertion Results – pokazuje wyniki związane z Response Assertion.

Konfigurujemy je zgodnie z uznaniem i wymogami. Opis wszelakich opcji konfiguracyjnych dostępny jest w manualu na stronie: jakarta.apache.org.

JMeter - Test Plan

Wszystkie wartości wyżej pokazanego testu dostępne są poniżej w postaci pliku XML, który należy zaczytać w aplikacji JMeter.

Nagrywanie testu

Wywołanie prostego zapytania HTTP nie jest skomplikowane do odtworzenia w JMeterze. Problemem może być np. zasymulowanie procesu rejestracji użytkowników, lub zakupu towaru w sklepie. Na szczęście aplikacja udostępnia komponent HTTP Proxy Server, który nagra za nas cały proces.

Na początku dodajemy WorkBench → Add → Non-Test Elements → HTTP Proxy Server. Konfigurujemy następnie ten komponent:
URL Patterns to Include

.*

URL Patterns to Exclude

.*\.png
.*\.ico
.*\.css
.*\.jpg
.*\.gif

Dodajemy również komponent Test Plan → Add → Thread Group, a następnie dodajemy do niego Config Element → HTTP Request Defaults. Wpisujemy w nim adres serwera jaki będziemy testować oraz Path ustawiamy na /.

W komponencie HTTP Proxy Server wciskamy guzik Start i udajemy się do przeglądarki internetowej. Konfigurujemy ją by korzystała z serwera Proxy i ustawiamy go na localhost:8080, chyba że skonfigurowaliśmy inaczej komponent w JMeterze.

JMeter - HTTP Proxy Server

Teraz wystarczy wejść kilka razy na stronę, przeprowadzić proces rejestracji, a aplikacja JMeter nagra nasze poczynania i przygotuje za nas test.

Tak nagrane requesty możemy uruchomić teraz i symulować różne zachowania użytkowników na serwerze.

Zdalne uruchamianie testów

W wielu przypadkach, aby wygenerować dość duży ruch na maszynie, która jest testowana, potrzeba jest skorzystać z kilku innych maszyn, które obciążą testowany serwer. Aplikacja JMeter udostępnia taką możliwość za pomocą narzędzia jmeter-server.

Po zbudowaniu planu testów za pomocą GUI zapisujemy plik w postaci jmx. Następnie należy edytować plik bin/jmeter.properties. W nim ustawimy jakie zdalne serwery będziemy konfigurować za pomocą aplikacji.

# Remote Hosts - comma delimited
remote_hosts=kione.pl:1001,windziarz.pl:1002,muszelka.org:6547,ixdude.com:6655

Po uruchomieniu ponownie JMetera w menu zobaczymy możliwość uruchomienia testów zdalnie. Będziemy mogli z kilku wcześniej skonfigurowanych maszyn uruchomić zbudowany przez nas test.

JMeter - Remote

Na maszynach jakie zostały dodane do JMetera należy uruchomić aplikację jmeter-server. Posłuży ona do wygenerowania ruchu. Na fizycznych serwerach uruchamiamy aplikacje.

SERVER_PORT=1001 ./jmeter-server &
SERVER_PORT=1002 ./jmeter-server &

W tym wypadku są to dwie instancje jmeter-server na maszynę uruchamiane na różnych portach. Po tej operacji klikamy na Remote Start All i czekamy na zakończenie testu. Możliwe jest również uruchomienie tych testów z innego serwera tak by zebrał wyniki do pliku, które można potem obejrzeć lokalnie.

jmeter -Ljmeter.engine=TRACE -Jremote_hosts=kione.pl:1001,windziarz.pl:1002,muszelka.org:6547,ixdude.com:6655 -n -r -t thecamels.jmx -l thecamels.jtl

Należy pamiętać, że wykonywanie takich testów z wielu maszyn na jeden serwer może spowodować jego zawieszenie.

Bibliografia

Podobne artykuły

  • Siaco

    Używam JMetera od kilku lat, w tym kilka razy w roku przy testowaniu całkiem niebanalnych serwisów. Z ciekawych przypadków mogę wymienić:

    * testowanie części aplikacji wymagających wprowadzania danych – nagrywasz profil przy użyciu JMeterProxy, potem zamieniasz wartości na zmienne, które w trakcie działania profilu dociągasz np. z pliku CSV.

    * testowania formularzy kilkuetapowych (np. rejestracja użytkownika w systemie), również takich, gdzie dopuszczalny zakres wartości danych wprowadzanych na jednym etapie jest uzależniony od tego, co zostało wybrane w poprzednim

    * testowanie aplikacji wykonujących operacje w tle – strona, którą otrzymujesz, ładuje się błyskawicznie (np. z informacją "przetwarzam…."), a serwer mieli pod spodem przez kilkanaście sekund

    Takie i wiele nie mniej interesujących przypadków można JMeterem przetestować, trzeba pamiętać tylko o kilku sprawach:

    * nie rezygnować po kilku nieudanych próbach (jeśli Java jest Ci obca na pewno takie będą ;-))

    * przeczytać kawałek dokumentacji i najlepiej FAQ

    * nie spodziewać się, że stworzenie dobrego profilu może być szybkie (poza najprostszymi przypadkami, bez autoryzacji, wprowadzania danych etc, ale do tych wystarczy 'ab' czy 'siege')

    * dobrze być w miarę sprawnym w przetwarzaniu plików tekstowych, wyciąganiem danych wejściowych z baz etc. (perl rulez! ;-))

    Jedno, czego czasem mi w JMeterze brakuje, to player do co raz częściej spotykanego flasha. Poza tym – nie znam lepszego FLOSS narzędzia do testowania (nawet wśród komercyjnych może być trudno), a bardzo chciałbym zobaczyć nawet takie za parę kUSD, przy pomocy którego dałoby się jakąś ciekawszą aplikację przetestować nie spędziwszy nad tym kilku dni…

  • @Siaco, dzięki za fajny komentarz. JMeter sprawdza się idealnie. Ostatnio generowałem nim ruch na poziomie ponad 1 mln requestów na minutę.

  • gr..

    Jmeter nie jest idealny, ale używałem go z radością (poza momentami zawieszenia całego systemu)

    Z tego co kojarzę to Jmeter obciąża serwer pomijając browser'a.

    W związku z czym brak jest wyników realnych (działania przetwarzania odpowiedzi serwera przeglądarki) – ale tak jest już ze wszystkimi obecnymi 'performance' narzędziami

  • Osobiście próbowałem używać jmetera, ale finalnie poprzestałem na tsungu – jest dużo lżejszy, potrafi wygenerować większe obciążenia, również jest dostarczany z proxy, i ma tranzakcje ;)

    http://web-dev.pl/tsung-przyklad-rozproszonego-te

  • Wygląda ciekawie. Przyjrzę się temu bliżej.

    @Bluszcz, skontaktuj się ze mną.

  • Ciekawy wpis. Tylko do Apache się to nadaje, czy z innymi serwerami (np. lighttpd, nginx) też się daje używać?

  • Tak, a dlaczego nie? Ja testowałem tym wydajność WebMethods Integration Serwer, około 120 JBOSSów i 4 bazy Oracle. Testujesz tym co chcesz tak naprawdę.

  • Pingback: SLAMD Distributed Load Generation Engine | thecamels.org()

  • Pingback: Tsung – narzędzie do testowania wydajności()

  • Pingback: Tsung – narzędzie do testowania wydajności()

  • Pingback: Tsung – narzędzie do testowania wydajności | thecamels.org()

  • admin

    Czy ktoś wie czy jest taka możliwość, że symuluje na wordpresie
    sytuacje gdy 10 użytkowników np komentuje post ->następnie ta
    operacja jest zapisywana gdzies do logu bodajże linuxowego albo
    wordpresowego> a następnie benchmarkiem jakimś powtarzam tą operacje z
    logu kilkukrotnie? Da się coś takiego zrobić?

    Bo skanowanie samego index.php na surowym wordpressie jest ponoć bez
    sensu, ma być to w miare rozbudowany serwis na którym będzie można operacje zasymulować i nastepnie benchmarkiem zwielokrotnić to i zbadać czasy na nginxie, apachu i IIS.

  • Pingback: SLAMD Distributed Load Generation Engine - OSWorld.pl()

  • Pingback: Linux Magazine – numer 143, czyli informacje o HTTP/2 i testowaniu obciążeń serwerów przy użyciu Apache JMetera - OSWorld.pl()