Testy wydajnościowe to nie tylko JMeter. Podobnie jak w przypadku testów automatycznych, liczba frameworków do badania wydajności stale rośnie. Poza wprowadzeniem w tematykę testów wydajnościowych, w trakcie prezentacji przyjrzymy się ich implementacji we frameworku k6. Opowiemy również dlaczego w The Software House postawiliśmy na jego wybór i jak dzięki prostym skryptom testowym zoptymalizowaliśmy kilka naszych projektów.
6. PODSTAWOWE INFORMACJE
Badają zachowanie aplikacji
i serwisów w różnych warunkach
obciążenia, wykorzystując dostępne
funkcjonalności do symulacji
działań użytkownika.
6
7. TYPY TESTÓW WYDAJNOŚCIOWYCH
Testy wydajnościowe dzielimy
na kilka typów. Każdy z nich ma
na celu dostarczenie różnych
informacji o systemie.
7
15. SOAK / ENDURANCE TESTS
15
Informują o niezawodności
i wydajności systemu w dłuższym
okresie czasu.
16. 1 Dbamy o zadowolenie swoich
użytkowników
2 Poznajemy szybkość i stabilność
swojej aplikacji
3 Poprawiamy skalowalność
4 Identyfikujemy wąskie gardła
5 Jesteśmy przygotowani
na nieoczekiwany ruch
DLACZEGO WARTO?
16
21. KILKA SŁÓW O K6
k6 jest nowoczesnym narzędziem
do testowania obciążenia, stworzonym
z myślą o zadowoleniu programistów.
Silnik k6 jest napisany w Go, co czyni
go jednym z najlepszych tego typu
dostępnych narzędzi.
21
22. 1 Niski próg wejścia, łatwy w użyciu
2 Brak XML, brak DSL, po prostu
JavaScript
3 Integrowalny z wieloma narzędziami
4 Wspiera WebSockety i gRPC
5 Spójny z technologiami TSH
6 Darmowy w użyciu
DLACZEGO K6?
22
23. 1 To nie NodeJS, nie wspiera
pakietów npm
2 Część atrakcyjnych funkcjonalności
dostępna jest w płatnej usłudze
k6 Cloud
ZAWSZE JEST JAKIEŚ “ALE”
23
25. CENIONY PRZEZ INNYCH
25
"The engineering effort of writing tests for just
one of our microservices was going to be 2+
Engineering weeks in JMeter, versus the ½ day
it took us in k6!"
Alex Hibbitt, Site Reliability Engineer
26. CENIONY PRZEZ INNYCH
26
"Very good load testing platform. We as a retailer got
tremendous help with the load testing to survive Black
Friday 2019. Biggest plus is that the tests can be run
from command line, and are configured with code."
CTO dużej firmy branży e-commerce
38. 1. Inicjatywa zespołu developerskiego
2. Chęć rozwoju testów przez
Developerów
3. Potrzeba obsługi Websocketów
4. Dedykowane środowisko
do przeprowadzenia testów
5. Brak informacji o spodziewanym
ruchu
WSTĘPNE INFORMACJE
38
41. 1. Część aplikacji radzi sobie bez
problemu z dużym ruchem (500 vus)
2. Dla jednego procesu przy niewielkim
ruchu (20 vus) dwie usługi AWS
przestają działać
3. Mechanizm automatycznego restartu
niedostępnych usług zawodzi
PIERWSZE WNIOSKI
41
46. 1. Pierwsze timeouty przy ruchu 60 req/s
2. Kod prototypu aplikacji wymaga
dalszych optymalizacji
3. Wymagana jest również zmiana
konfiguracji środowiska aplikacji
PIERWSZE WNIOSKI
46
48. 1. Inicjatywa zespołu developerskiego
(i ich intuicji)
2. Dedykowane środowisko
do przeprowadzenia testów
3. Konkretna informacja nt.
oczekiwanej wydajności
(w szczycie 60k użytkowników)
WSTĘPNE INFORMACJE
48
50. 1. Konieczność większej optymalizacji UI
(z uwagi na SSR)
2. Wydajność API powyżej oczekiwań
3. Konieczna rekonfiguracja usług AWS
4. Wymagane zwiększenie zasobów
aplikacji (CPU oraz RAM)
PIERWSZE WNIOSKI
50
51. 1. Zaangażowanie Developerów
oraz DevOpsów w pierwsze testy
2. Utrzymanie i rozwój testów przez
Developerów i/lub DevOpsów
3. Kontynuowanie i cykliczne
wykonywanie testów (Smoke,
Performance, Endurance)
4. Uzyskanie oczekiwanej wydajności
PODSUMOWANIE CASE STUDIES
51
53. MANIFEST K6
53
Simple testing is better than no testing
Load testing should be goal oriented
Load testing by developers
Developer experience is super important
Load test in a pre-production environment