JMeter w chmurze

Z AmberPlace

Spis treści

Wstęp

Zawsze na kursach z testowania uczyłem, że podczas planowania testów trzeba zaplanować wszystkie zasoby z dużym wyprzedzeniem. Zwłaszcza jeżeli chcemy robić testy wydajnościowe, to zdarza się, że potrzeba kilka maszyn, żeby wygenerować dostateczne obciążenie testowanej aplikacji.

Poniżej opisuję jak zestawić środowisko do testów wydajnościowych oparte na JMeterze i maszynach z EC2 Amazona. Zestawienie takiego środowiska zajmuje kilka chwil i zawiera tylko elementy darmowe. Artykuł powstał podczas wykonania Proof of Concept uruchamiania JMetera w chmurze i rozpoznawania koncepcji "cloud testing". Zawiera on podstawową konfigurację, która pewnie da się zoptymalizować i zautomatyzować.

Proces

Żeby uruchomić testy wydajnościowe potrzeba kilka elementów:

  • testowanej aplikacji
  • skryptów generujących obciążenie
  • maszyn i narzędzie uruchamiającego skrypty obciążające

Jako aplikacja testująca została wykorzystana prosta aplikacyjna napisana przeze mnie w PHP na potrzeby warsztatów konferencji Testwarez 2011 . Jest ona dostępna na serwerze konferencji. (link). Zestawienie pozostałych elementów podaję poniżej w tekście artykułu.

W prawdziwych testach wydajnościowych pozostanie problem, czy łącze pomiędzy generatorami obciążenia a testowaną aplikacją jest dostatecznie szerokie. Jeżeli testujecie system, który ma być dostępny w Internecie, to i tak odpowiednie łącze musi istnieć i nawet korzystne jest, że wchodzi ono w skład środowiska testowego.

Założenia

Pisząc ten artykuł zakładałem że czytlnik:

  • zna JMetera i potrafi tworzyć w nim skrypty
  • ma konto na Amazonie, a w szczególności na Amazon Web Services
  • posiada i umie używać klienta SSH

Przygotowanie maszyn

JMeter potrafi pracować w konfiguracji wielomaszynowej, w której jedna maszyna jest kontrolerem testu, a pozostałe generują obciążenie. Taka konfiguracja pozwala na uruchomienie dużej ilości wirtualnych użytkowników, co może się nie udać na jednej maszynie np. z powodu braku pamięci, czy procesora.

Utworzenie pierwszej maszyny pod JMetera

Żeby przygotować maszyny pod JMetera należy

  1. zalogować się na Amazon Web Services]
  2. wejść do zakładki EC2
  3. nacisnąć przycisk "Launch Instance"
  4. pojawi się lista dostępnych typów maszyn
    • wybrać "Basic 32-bit Amazon Linux AMI 2011.09"
  5. pojawi się pytanie i szczegóły instancji
    • jako typ instancji wybrać "t1.micro", którego użycie jest na EC2 darmowe
  6. dalej nacisnąć "Continue"
  7. później można wpisać nazwę maszyny np. "JMeter_Controler", lub jeżeli zamierzacie rozbudowywać środowisko dodać dodatkowe tagi, po których można filtrować maszyny
  8. następnie należy utworzyć i ściągnąć klucze, które będą służyły do logowania do maszyny
  9. później trzeba ustawić konfigurację fiewalla (Security Group)
    • wpisać nazwę konfiguracji
    • otworzyć port SSH dla wszystkich
    • otworzyć wszystkie porty TCP lokalnie do komunikacji pomiędzy JMeterami
  10. na końcu obejrzeć sobie podsumowanie konfiguracji i uruchomić instencję

Po uruchomieniu maszyny jest ona widoczna AWS Management Console w zakładce EC2 w elemencie Instances.

Instalacja JMetera

Żeby zainstalować JMetera wchodzimy musimy się dostać do naszej nowiutkiej maszyny. W tym celu klikamy prawym klawiszem myszy na instancję i wybieramy "Connect"

Później wykonujemy polecenia z okienka, które się pojawiło

Po zalogowaniu do maszyny wykonujemy:

wget http://ftp.tpnet.pl/vol/d1/apache//jakarta/jmeter/binaries/jakarta-jmeter-2.5.1.tgz

Następnie:

tar -xzf jakarta-jmeter-2.5.1.tgz

Warto też w katalogu domowym utworzyć folder na skrypty. W moim przypadku będzie to folder scripts:

mkdir scripts

W tym momencie mamy już gotowego JMetera do pracy w postaci podstawowej. Jeżeli chcemy dorzucać biblioteki, to warto to zrobić w tym momencie.

Klonowanie maszyn

W związku z tym, że wybraliśmy maszyny najsłabsze dostępne na EC2, to nie uruchomimy na nich zbyt wielu wirtualnych użytkowników. Trzeba więc maszyny powielić, tak żeby wzmocnić środowisko.

Klikamy w AWS Management Console prawym klawiszem na naszą instancję i wybieramy Launch more like this.

Wpisujemy liczbę maszyn do stworzenia (np. 4) i konfigurujemy je tak jak pierwszą. Jeżeli nie chcemy sobie komplikować życia, to wybieramy taką samą konfigurację jaką stworzyliśmy dla pierwszej maszyny.

Po stworzeniu maszyn dobrze jest pozmieniać im nazwy.

Przygotowanie skryptów

Skrypty testowe najlepiej przygotować lokalnie na swoim komputerze, tam gdzie możemy uruchomić JMetera z GUI. Jeżeli mamy już przygotowane skrypty, to w zasadzie bez poprawek można je wrzucić na kontroler (maszynę JMeter_Controler).

Przy przygotowaniu skryptów warto pamiętać o kilku sprawach:

  • wyłączyć wszystkie listenery, ponieważ za bardzo obciążają pamięć (wybrane przez nas maszyny mają około 600MB pamięci)
  • podstawowe parametry skryptu umieścić w propertiesach, które można później zmieniać w pliku na maszynie w chmurze bez konieczności edycji skryptu 
# properties for the Smary_test script
host=www.testwarez.pl
path=jmeter
threads=50
  • JMeter uruchomi na każdym generatorze dokładnie taki sam skrypt, to znaczy jeżeli w skrypcie jest zadeklarowanych 50VU i mamy 4 maszyny, to system zostanie obciążony 200VU.

Przygotowane skrypty oraz propertiesy wrzucamy na kontroler przy pomocy np. WinSCP, które też pozwala na prostą edycję plików zdalnych. Edycja przyda się do szybkiej zmiany propertiesów w pliku.

W tym momencie mamy już przygotowane maszyny do generowania obciążenia, a na kontrolerze w folderze ~/scripts mamy umieszczony skrypt i propertiesy do niego.

Uruchamianie testów

Żeby uruchomić testy należy na początku uruchomić jmeter-severy, które będą generowały ruch, a później uruchomić same testy z kontrolera.

Uruchamianie generatorów obciążenia

W celu uruchomienia generatorów obciążenia trzeba na każdym generatorze wykonać następujące kroki:

  1. uruchomić maszynę z generatorem (o ile nie jest uruchomiona)
  2. zalogować się na generator
    1. kliknąć prawym klawiszem myszy na instancję i wybrać Connect z menu
    2. wykonać połączenie
  3. wykonać ifconfig
  4. skopiować na bok IP maszyny (IP maszyn zmieniają się przy każdym uruchomieniu instancji)
  5. cd jakarta-jmeter-2.5.1/bin/
  6. ./jmeter-server

IP maszyny można też odczytać z jej opisu. Interesuje nasz parametr Private IP address

Uruchomienie testów

W celu uruchomienia testów trzeba zalogować się na kontroler metodą wyżej opisaną a następnie wykonać na przykład:

cd scripts

../jakarta-jmeter-2.5.1/bin/jmeter.sh -n -G Smarty_test_XPath.properties -t Smarty_test_XPath.jmx -l Smarty_test_XPath.jtl -R 10.194.75.56,10.243.73.4

Poszczególne opcje oznaczają odpowiednio:

  • -n - uruchomienie bez GUI
  • -G - wskazanie na plik z propertiesami (JMeter używa wielu plików z propertiesami dokładniejszy opis jest tu)
  • -t - plik JMX z testem
  • -l - plik z wynikami testów, do późniejszej analizy
  • -R - lista z IP generatorów obciążenia oddzielonych przecinkami ustalona w poprzednim kroku

Zatrzymywanie testów

Zatrzymać testy najlepiej przez wykonanie skryptu ../jakarta-jmeter-2.5.1/bin/stoptest.sh. Wyśle on na port 4445 żądanie zatrzymania testów. W ten sposób powstały plik JTL, który jest XMLem będzie miał dobrą strukturę, to znaczy zostanie zakończony tag <testResults>.

Zbieranie wyników

Wyniki samplerów zbierane są do pliku JTL. Powstały plik ściągamy do siebie na komputer i wczytujemy do listenerów w JMeterze uruchomionym lokalnie i z GUI.

Możemy użyć View Results Tree, żeby obejrzeć błędy. W tym celu wybieramy z drzewka JMetera View Results Tree. Zaznaczmy opcję Errors/Błędy. Klikamy naprzycisk Browse.../Przeglądaj... i wybieramy plik załadowany z kontrolera z chmury.

Najbardziej przydatny oczywiście jest Aggregate report, który przygotowujemy w podobny sposób.

Można też wygenerować Aggregate graph

Plik z wynikami sesji testów warto zachować jako dowód na wykonanie testów i na prawdziwość ich wyników.

Podsumowanie

Podany przepis na wykonywanie testów w chmurze powstał w ciągu jednego weekendu zabawy z EC2 Amazona i JMeterem. Dużo rzeczy wykonuje się ręcznie, zostały użyte same darmowe komponenty (łącznie z darmowymi maszynami Amazona).

Najprawdopodobniej wykonywanie testów w prawdziwym projekcie, w którym trzeba rozwijać skrypty, a później wielokrotnie je puszczać i analizować dane byłoby zbyt męczące. Głównie ze względu na zmianę IP generatorów obciążenia.

Na pewno Amazon daje API, które pozwoliłoby na zautomatyzowanie wielu czynności. Istnieje też wiele rozwiązań Continuous Integration, które prawdopodobnie zautomatyzowałyby uruchamianie testów i analizę wyników. Można też pokusić się o wysyłanie wyników testów on-line do Nagiosa do wizualizacji.

Ale to już temat na inną bajkę i inny weekend.

Źródło „http://amberplace.amberteam.pl/JMeter_w_chmurze”
Osobiste