Testy wydajnościowe

Klient wymaga przeprowadzenia testów wydajnościowych. Projekt napisany z użyciem Java, Spring, Kafka, Couchbase. Od czego zacząć?
Jakie polecacie narzędzia? Wiem, że jmeter do tego służy ale słyszałem różne opinie na temat tego narzędzia.

Poczytaj o coordinated omission. Polecam wrk2

zaczij od ustalenia wymagan. Tego jakiego rodzaju to maja byc testy, jaki load, jak masz pozniej przedsatwic wyniki itp.

Z narzedzi do wyboru: Jmeter, Locust (chyba najmniejszy prog wejscia), Gatling, wrk2. Kazde ma swoje plusy dodatnie i ujemne.

Jest spora szansa ze narzedzie to bedzie wybor drugorzedny.
Co do coordinated omission -> nie jest uwzgledniane w statystykach z Jmetera, ale jak sobie podlaczysz perfmona to widzisz na wykresach co sie dzieje.

Czy wspomniane przez was narzędzia np. wrk2 ogarną to, że np. response z pierwszego rq będzie potrzebny w kolejnym rq?

Przykładowy scenariusz testowy:

1. Użytkownik rejestruje się.
2. Użytkownik loguje się -> token.
3. Użytkownik szuka produktu w sklepie (potrzebny token z pkt 2).
4. Użytkownik dodaje produkt do koszyka (potrzebny token z pkt 2).
5. Użytkownik składa zamówienie (potrzebny token z pkt 2).

JMeter oraz Gatling ogarną (możesz w nich przygotować cały scenariusz testowy), wrk2 jest dosyć prymitywne i raczej z tym konkretnie zadaniem sobie nie poradzi.

Patryk27 napisał(a):

JMeter oraz Gatling ogarną

Które z tych dwóch będzie prostsze do ogarnięcia / przyśpieszy development?

Mi personalnie bardziej podpadł Gatling.

Testy wydajnościowe trzeba zacząć od wymagań. Jak ktoś Ci powie, że 'aplikacja ma działać szybko' to gorzej, niż jakby Ci nic nie powiedział. Musi określić, w jakim środowisku, przy jakim obciążeniu, w jakich warunkach, przy jakim ruchu jakie mają być czasy odpowiedzi (średnie i maksymalne, po ucięciu np 3% najlepszych i najgorszych rezultatów) oraz przez jaki czas ma być przeprowadzany test.

Co do samych tooli, to JMeter jest najprostszy, ale Gatling:

1. Jest w Scali (moda + ScalaTest + model aktorów)
2. Jest narzędziem z kodem
3. Ma lepsze wsparcie do CI/CD
4. Jest w Scali (drugi raz to samo, ale skoro temat w sekcji Java to zakładam, że JVM Wam nie obcy) i będzie łatwiej rozszerzalny.

JMeter jest prostszy i zapewnia więcej funkcji out-of-the-box, ale dopisanie czegoś customowego już takie fajne nie będzie (aczkolwiek też się da).

PM powiedział zróbcie testy wydajnościowe, nic nie wspomniał o wymaganiach.

To pozostaje się dowiedzieć ;] Można na przykład wziąć ruch i konfiguracje z produkcji i przeskalować to na to, jakie możecie mieć środowisko testowe. I określić, co dokładnie chcecie zmierzyć, bo testy wydajnościowe też się dzielą na kilka rodzajów.

lookacode1 napisał(a):

PM powiedział zróbcie testy wydajnościowe, nic nie wspomniał o wymaganiach.

może chodziło mu o to żęby określić jaki ruch/jakie obciążenie przyjmie aplikacja w obecnej formie? to chyba da sie zmierzyć bez bardzo szczegółowych wymagań

Jeśli nie masz jeszcze środowiska produkcyjnego, to wtedy musisz przewidzieć jak mniej-więcej wyglądają typowe use-case'y aplikacji.
Wtedy sobie "nagrywasz" ścieżkę/ścieżki, jaką/jakie odbywa user podczas normalnego użytkowania aplikacji (większość narzędzi ma takie funkcje). Na środowisku testowym będziesz musiał sobie przygotować X-set/tysięcy/milionów userów testowych (chyba, że masz pewność, że wydajność appki będzie taka sama niezależnie od tego czy masz milion sesji jednego usera, czy po jednej dla miliona userów - wtedy dla ułatwienia możesz sobie darować)

Jeśli nie masz zdefiniowanych wymagań, to zapewne na Twojej głowie jest ustalenie ile system jest w stanie uciążyć w obecnej wersji.

Jakiego rodzaju testy przeprowadzić? Tutaj zależy od samej aplikacji... Ale standardowo widzę poniższe:

1. Test sprawdzający jak apka się zachowuje przy "peak load" przez np. ~2h ()
2. Jeśli np. aplikacja przewiduje jakieś "promocje" dla userów, typu "super produkt X, w promocji -90%, limitowana oferta, dziś o godz. 11:00", to przygotowujesz "burst test" (z obserwacji wiemy, że często ludzie tego nie sprawdzają, i przygotowują podobne akcje a potem cały system się wysypuje kompletnie - patrz https://www.spidersweb.pl/2018/07/allegro-nie-dziala-honor-7c.html)
3. SOAK test - sprawdzający jak apka się zachowa przy dłuższym okresie użytkowania - dobre do wykrywania memory leaków (w przypadku gdy jest memory leak, a nie ma developera który to sfixuje, będzie wiadomo że trzeba zrobić "tymczasowe" rozwiązanie jakim jest np. restart instancji co 1 dobę, ale przynajmniej będziesz na to gotowy xD)

Jaki set up środowiska?
Środowisko testowe musi przypominać PROD 1:1, czyli nic nie stubujesz (w miarę możliwości), stawiasz wszystkie komponenty z konfiguracjami identycznymi jak na prodzie, z identycznym hardwarem, nie omijasz load balancerów / proxy itp.
Jeśli na prodzie jest/ma być na prawdę wiele instancji, to możesz np. ograniczyć liczbę node'ów. Oczywiście, jeśli np. na prodzie masz 4 nody a na testowym 2, i osiągniesz 10000 concurrent users na 2 nodach, nie oznacza to, że prod uciągnie 20000 - nie wiesz ile uciągnie, ale będziesz mógł bezpiecznie założyć, że prod uciągnie 10000 + nawiązka :D

W praktyce jak PM mówi, że trzeba zrobić testy wydajnościowe, tzn. że zauważył w umowie, że ma dostarczyć "raport z testów wydajnościowych" i ma gdzieś jak jest, tylko chce dostarczyć raport ;)

Umiesz odpowiedzieć sobie na pytanie "Co to jest wydajność systemu?"?. Bez zrozumienia ciężko będzie testować

Możesz spojrzeć tak, że na wejściu masz:

• system, który realizuje jakieś przypadki użycia: UC_1, ..., UC_N
• platformę na której realizowane są testy (ustalone parametry typu: CPU/RAM/storage/sieć/... - dowolne zasoby, ale których wykorzystanie da się zmierzyć)

Użytkowników nie interesuje ile dla UC#x masz pod spodem wywołań do bazy czy web serwisu, tylko dostarczona funkcjonalność.

Powinieneś umieć:

• wygenerować obciążenie systemu - wywoływać przypadki użycia z określoną intensywnością:
  tpsUC3 = 12 -> 12 wywołań UC#3 w ciągu sekundy
• zmierzyć:
• czas odpowiedzi systemu (czas oczekiwania na obsługę + czas przetwarzania przez system)
• przepustowość systemu
• utylizację zasobów

Na wydajność można spojrzeć jak na funkcję: WYDAJNOSC_SYSTEMU: OBCIAZENIE -> (serviceTime, waitTime, throughput, resource_utilization)

1. Czy dla obciążenia X wartość funkcji jest "dobra" ? Nie wiadomo co to znaczy "dobra" -> trzeba znać wymagania na wydajność, żeby odpowiedzieć TAK/NIE.
2. Jak zmienimy obciążenie, to jak zmieni się utylizacja zasobów (pochodna funkcji WYDAJNOSC_SYSTEMU :P)

Na tej podstawie 2) będziesz w stanie przewidzieć jak wydajnościowo zachowuje się system pod wzrostem obciążenia, np. zwiększasz liniowo ilość tps na UC#x, a w pewnym momencie następuje załamanie czasów odpowiedzi, przy "akceptowalnej utylizacji ". Nic Ci to jednak nie powie czy jest to dobra sytuacja czy nie.

Jak dla mnie, to masz 2 ścieżki postępowania:
a) pytasz biznesu - ile UC#N w ciągu dnia generujecie i jaki jest spodziewany czas odpowiedzi dla tego UC -> z góry wiesz jakiego obciążenia się spodziewać
b) nie ma żadnego biznesu, bo to nowy produkt i trzeba sprawdzić jak system się zachowuje dla różnych obciążeń, żeby wiedzieć czego się spodziewać jak już biznes będzie