Prezentacja

Jmeter: Pierwsze kroki w
testowaniu wydajności
Anna Kovalchuk
07.05.2014
Plan
1. Wymagania i cele
2. Modelowanie obciążenia
3. Parametryzacja i korelacja
scenariuszy
4. Analiza wyników
Help! My boss wants me to load test
our web app!
Klatka z video: http://youtu.be/BKorP55Aqvg
Wydajność
Stopień, w jaki system lub moduł, przy zadanych
ograniczeniach, spełnia zamierzoną funkcjonalność
odnośnie szybkości przetwarzania i przepustowości.
[IEEE 610] Patrz także efektywność.
Performance: The degree to which a system or component accomplishes
its designated functions within given constraints regarding processing time
and throughput rate. See also efficiency.
http://testerzy.pl/slownik/wydajnosc
Efektywność
Zdolność
oprogramowania
do
zapewnienia
odpowiedniego poziomu wydajności, relatywnie do
ilości zużytych zasobów, w określonych warunkach.
[ISO 9126]
• Zachowanie z czasem (Time behavior)
• Wykorzystanie zasobów (Resource behaviour)
Efficiency: The capability of the software product to provide appropriate
performance, relative to the amount of resources used under stated
conditions. [ISO 9126]
http://testerzy.pl/slownik/efektywnosc
Performance efficiency
ISO 25010 :
Wydajność w stosunku do ilości zasobów
wykorzystywanych pod ustalonymi warunkami
Zachowanie z czasem
Wykorzystanie zasobów
Zgodność
The performance relative to the amount of resources used under stated
conditions
- Time Behaviour
- Resource Utilisation
- Compliance
Niezawodność
ISO 25010 : stopień, w jakim system lub jego element wykonuje
określone funkcje w określonych warunkach, w określonym okresie
czasu.
 Stabilność
 Odporność na błędy
 Zdolność do przewrócenia stanu początkowego
 Zgodność
Reliability - The degree to which a system or component performs specified
functions under specified conditions for a specified period of time.
- Maturity
- Fault Tolerance
- Recoverability
- Compliance
Testowanie wydajności =
Testowanie efektywności
+
Testowanie niezawodności
*zależy od celów testowania
Przykład wymagań
Przy obciążeniu do 100 jednocześnie
pracujących klientów z systemem:
• średni czas odpowiedzi powinien wynosić nie
więcej niż 2,5 sekundy.
Przykład wymagań
Przy obciążeniu do 100 jednocześnie
pracujących klientów z systemem:
• średni czas odpowiedzi powinien wynosić nie
więcej niż 2,5 sekundy.
• liczba błędów nie powinna przekroczyć 1%
Przykład wymagań
Przy obciążeniu do 100 jednocześnie
pracujących klientów z systemem:
• średni czas odpowiedzi powinien wynosić nie
więcej niż 2,5 sekundy.
• liczba błędów nie powinna przekroczyć 1%
• rozrzut (dyspersja) nie przekracza 5%
Przykład wymagań
Przy obciążeniu do 100 transakcji na sekundę
typu «ping» i 10 transakcji na sekundę typu
«akcja»:
• średni czas odpowiedzi powinien wynosić nie
więcej niż 2,5 sekundy.
• liczba błędów nie powinna przekroczyć 1%
• rozrzut (dyspersja) nie przekracza 5%
Przykład wymagań
Przy obciążeniu do 100 transakcji na sekundę
typu «ping» i 10 transakcji na sekundę typu
«akcja»:
• średni czas odpowiedzi dla transakcji typu
«akcja» powinien być nie więcej niż 2,5
sekundy, a na typu «ping» 1 sekunda
• liczba błędów nie powinna przekroczyć 1%
• rozrzut (dyspersja) nie przekracza 5%
Przykład wymagań
Przy obciążeniu do 100 transakcji na sekundę typu
«ping» i 10 transakcji na sekundę typu «akcja»:
• średni czas odpowiedzi dla transakcji typu
«akcja» powinien być nie więcej niż 2,5 sekundy,
a na typu «ping» 1 sekunda
• liczba błędów nie powinna przekroczyć 1%
• rozrzut (dyspersja) nie przekracza 5%
• Serwer aplikacji powinien zużywać nie więcej niż
75% CPU i nie więcej niż 2,2 GB pamięci RAM
Przykład wymagań
Przy obciążeniu do 100 transakcji na sekundę typu «ping»
i 10 transakcji na sekundę typu «akcja»:
• średni czas odpowiedzi dla transakcji typu «akcja»
powinien być nie więcej niż 2,5 sekundy, a na typu
«ping» 1 sekunda
• liczba błędów nie powinna przekroczyć 1%
• rozrzut (dyspersja) nie przekracza 5%
• Serwer aplikacji powinien zużywać nie więcej niż 75%
CPU i nie więcej niż 2,2 GB pamięci RAM
• System powinien nawiązywać nie więcej niż trzy
połączenia jednocześnie z DBMS
Jakie wymagania są lepsze?
Szczegółowe?
VS
Przy obciążeniu do 100 transakcji na sekundę
typu «ping» i 10 transakcji na sekundę typu
«akcja»:
• średni czas odpowiedzi dla transakcji typu
«akcja» powinien być nie więcej niż 2,5
sekundy, a na typu «ping» 1 sekunda
• liczba błędów nie powinna przekroczyć 1%
• rozrzut (dyspersja) nie przekracza 5%
• Serwer aplikacji powinien zużywać nie więcej
niż 75% CPU i nie więcej niż 2,2 GB pamięci
RAM
• System powinien nawiązywać nie więcej niż
trzy połączenia jednocześnie z DBMS
Nieformalne i rozmyte?
Przy obciążeniu do 100
jednocześnie pracujących
klientów z systemem:
• średni czas odpowiedzi
powinien wynosić nie
więcej niż 2,5 sekundy.
Cel testowania
• Sprawdzenie zgodności z wymaganiami
Przykład wymagań
Przy obciążeniu do 100 transakcji na sekundę typu «ping»
i 10 transakcji na sekundę typu «akcja»:
• średni czas odpowiedzi dla transakcji typu «akcja»
powinien być nie więcej niż 2,5 sekundy, a na typu
«ping» 1 sekunda
• liczba błędów nie powinna przekroczyć 1%
• rozrzut (dyspersja) nie przekracza 5%
• Serwer aplikacji powinien zużywać nie więcej niż 75%
CPU i nie więcej niż 2,2 GB pamięci RAM
• System powinien nawiązywać nie więcej niż trzy
połączenia jednocześnie z DBMS
Cel testowania
• Sprawdzenie zgodności z wymaganiami
• Uzyskać informacje na temat wydajności i
dostarczyć zainteresowanym stronom,
aby mogły one wykorzystać je do
podejmowania decyzji
Cele testowania
Wykorzystanie otrzymanej informacji
1. Sprawdzenie zgodności z
wymaganiami
2. Porównanie różnych wersji i
konfiguracji systemu
3. Identyfikowanie „wąskich miejsc”
(bottlenecks)
Informacja
Statyczna
VS
• Odsetek blędów przy
stałym obciążeniu 100
transakcji na sekundę
• Zużycie pamięci RAM w
ustalonym obciążeniu
100 transakcji na
sekundę
Dynamiczna
• Zależność
Ilości błędów od
obciążenia
• Zależność
Zużycia RAM od
obciążenia
Jakie wymagania są lepsze?
Szczegółowe?
VS
Nieformalne i rozmyte?
Dynamiczna informacja
Trzy bazowe komponenty
• Generacja obciążenia
• Monitorowanie charakterystyk
wydajności
• Analiza wyników
Narzędzia dla generowania obciązenia
• JMeter – http://jmeter.apache.org/
• grinder – http://grinder.sourceforge.net/
• multi-mechanize – http://testutils.org/multimechanize/
• Gatling – http://gatling-tool.org/
• Tsung – http://tsung.erlang-projects.org/
• loadUI – http://www.loadui.org/
• curl-loader – http://curl-loader.sourceforge.net/
Z chmur
•
•
•
•
•
BlazeMeter – http://blazemeter.com/
Blitz – https://www.blitz.io/
Load Impact – http://loadimpact.com/
LoadStorm – http://loadstorm.com/
SOASTA – http://www.soasta.com/
Monitoring
• Wbudowane narzędzia
• Narzędzia systemu operacyjnego
(Perfmon, SAR)
• Narzędzia serwerowe, DBMS, ...
• Narzędzia specjalistyczne (Zabbix,
Nagios, Hyperic)
Analiza wyników
• Wbudowane narzędzia
• Arkusze kalkulacyjne
• Pakiety dla przetwarzania danych
statystycznych
Praktyczna demonstracja
Zadanie
• Zapisać rekorderem scenariusz dodawania
grup
• Ustawić grupę wątków dla 50 użytkowników i
czas trwania testu 180 sec
• Monitorować zmiany średniego czasu reakcji
(response time) z czasem w Graph Result
Plan
1. Wymagania i cele
2. Modelowanie obciążenia
3. Parametryzacja i korelacja
scenariuszy
4. Analiza wyników
Model obciążenia
Ile i jakich akcji(działań) na system ma
być na system w jednostkę czasu
• Log file
• Dane historyczne
http://www.symplur.com/blog/dayofdiabetes-shared-in-real-time/
Słownik pojęć
• Profil - zbiór scenariuszy, danych
testowych, i opis sposobu uruchomienia
scenariuszy
• Scenariusz – sekwencją zapytań,
rozdzielonych czasowymi odstępami
• Zapytanie – jednostka interakcji
pomiędzy systemem testującym i
testowanym systemem
Zależność od czasu
Zależność od czasu akcji (dla
każdego rodzaju zapytań)
• stała
• zmienna
Rodzaj oddziaływań
• Osobne zapytania
–Testowanie zorientowane na kliknięcia
(hit-oriented testing)
• Scenariusz (kolejność wniosków)
–Testowanie zorientowane na
scenariusze (scenario-oriented testing)
Przykład zorientowany na hity
Osobne akcje
– Przeglądanie listy grup (2)
– Otwieranie strony z formularzem (1)
– Wysłanie wypełnionego formularza (1)
Przykład modelu obciążenia
• Stałe obciążenie
– wirtualnych użytkowników lub transakcji
• Cel: uzyskać informacje o zachowaniu systemu
Praktyczna demonstracja
Praktyczna demonstracja
Zmodyfikować przykład 1
a) Ustawić 100 wątków, mają oni być
uruchomione po kolei za 1 minutę i
obciążenie generowanie przez 10 min
b) Ustawić stałe obciążenie 2 zapytania na
sekundę w ciągu 10 min
Przykład modelu obciążenia
• Stale zwiększa obciążenie
• Cel: Aby wyszukać punkt nasycenia
Praktyczna demonstracja
Praktyczna demonstracja
Zmodyfikować przykład 1
• Ustawić 600 wątków, mają oni rosnąć z
czasem od 0 do 600 i obciążenie generowanie
przez 10 min
Przykład modelu obciążenia
• Stałe obciążenie bliskie do granicznego
• Cel: Aby sprawdzić stabilność
Praktyczna demonstracja
Zmodyfikować przykład 1
• Ustawić obciążenie na 10% mniej od
krytycznego i testować przez 10 min
Praktyczna demonstracja
Przykład modelu obciążenia
• Obciążenie z "seriami"
• Cel: Aby sprawdzić stabilność
– Plugin „ Throughput Shaping Timer”
Plan
1. Wymagania i cele
2. Modelowanie obciążenia
3. Parametryzacja i korelacja
scenariuszy
4. Analiza wyników
Parametryzacja
• Opcje konfiguracyjne
• Dane testowe
–Generowanie danych losowych
–Dane z tabeli (pliku zewnętrznego)
Praktyczna demonstracja
Korelacja
• Przekazywanie danych z odpowiedzi na
poprzednie zapytanie do jednego z
następnych zapytań
– wyodrębnienie danych z wyniku zapytania
– wykorzystanie wyodrębnionych danych
Praktyczna demonstracja
Plan
1. Wymagania i cele
2. Modelowanie obciążenia
3. Parametryzacja i korelacja
scenariuszy
4. Analiza wyników
To jest – testowanie!
• Problem może być znaleziono lub nie
znaleziono
– zebranych danych nie jest wystarczająco
– niepoprawna metoda analizy
– może być że w ogóle nie tego szukaliśmy
• Nie można udowodnić brak defektów
– eksperyment pokazuje coś
– ale mogą istnieć różne interpretacje
Примеры проблем
• большое время отклика
• большое количество отказов
• высокое потребление ресурсов
• большой разброс значений
• отдельные значительные отклонения
Przykłady problemów
• Duży czas reakcji
• Duża liczba błędów
• Wysokie zużycie zasobów
• duży zakres wartości
• niektóre znaczące odchylenia
Źródło problemów
• brak zasobów
• nieoptymalne algorytmy
•
•
•
•
•
niewłaściwe zbalansowanie
niewłaściwe keszowanie
niewłaściwa synchronizacja (blokowanie)
niewłaściwe zarządzanie kolejką
defekty funkcjonalne
Analiza jakościowa
•
•
•
•
•
Przegląd ręczny danych surowych
Budowanie wykresów
Szukanie wzorców
Szukanie trendy
Szukanie anomalie
Analiza ilościowa
• Średnie jednakowe
• Gdzie „lepsza” wydajność
Błędy pierwszego i drugiego rodzaju
• Fałszywo-pozytywny wynik
– ma objawy defektu, ale w rzeczywistości nie ma
defektu, ale objawy są spowodowane przez coś
innego
• Fałszywo-niegatywny wynik
– objawy defektu nie pojawiają się lub nie są
zauważone, ale w rzeczywistości jest defekt.
Raport
• Aktualny
• Trafny (Relevant)
• Zrozumiały
• Samowystarczalny
• Opierający się na danych
Dane żródłowe
• Nie zapomnij, aby wskazać:
–kiedy uzyskane dane
–jakie testy były uruchomione
–w jaką konfiguracją były uruchomione
Trzeba pamiętać że
• Dane liczbowe dostarczone w dużej ilości są
ciężkie do zrozumienia
• Ludzie źle znają matematykę
• Ludzie nie mają intuicyjnego rozumienia
zjawisk statystycznych
• Błędna interpretacja danych prowadzi do
błędnych wniosków
Dobry raport zawiera
•
•
•
•
•
•
Porównanie czegoś z czymś
Jest oczywiste, co jest lepsze a co gorsze
Zawiera ustne wyjaśnienia
Skala wykresów dobrana odpowiednio
Łączy obserwację z celami
Zawiera linki do danych źródłowych
Narzędzia
•
•
•
•
Wbuwane pluginy w Jmeter
Excel
Loadosophia
RapidMiner
Przykład analizy
Literatura
1.
2.
3.
4.
Jmeter user manual i wiki
Apache Jmeter. Emily H. Halili
Web Load testing for dummies
Performance Testing Guidance for Web
Applications (Microsoft)
5. The Art of Application Performance Testing By
Ian Molyneaux
6. Data Mining for the Masses by Dr. Matthew A
North (Author)
Dropbox link
http://goo.gl/loVv18
Pytania?
Dziękuję za uwagę