Testy wydajnościowe

0

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.

1

Poczytaj o coordinated omission. Polecam wrk2

1

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.

0

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).
1

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.

0
Patryk27 napisał(a):

JMeter oraz Gatling ogarną

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

2

Mi personalnie bardziej podpadł Gatling.

2

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).

0

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

1

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.

1
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ń

0

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

1

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

1 użytkowników online, w tym zalogowanych: 0, gości: 1