Zacznij od pytania, a nie od narzędzia
“Sprawdźmy wydajność” to za mało, żeby zaplanować test. Potrzebujesz pytania, na które da się odpowiedzieć liczbą: czy koszyk obsłuży ruch z kampanii, ile użytkowników wytrzyma API, zanim czasy odpowiedzi przestaną być akceptowalne.
Dobry cel ma trzy elementy:
- obciążenie: ilu użytkowników lub żądań na sekundę,
- próg: np. 95% odpowiedzi poniżej 800 ms,
- margines błędów: np. mniej niż 1% żądań zakończonych błędem.
Liczby powyżej są przykładowe. Swoje weź z danych produkcyjnych albo z założeń biznesowych.
Rodzaje testów
- Test obciążenia sprawdza działanie przy oczekiwanym ruchu.
- Test przeciążeniowy szuka granicy, po której system zaczyna się psuć.
- Test wytrzymałościowy trzyma stałe obciążenie przez wiele godzin i pokazuje wycieki pamięci albo połączeń.
- Test skokowy sprawdza nagły wzrost ruchu, np. po wysłaniu newslettera.
Na początek wystarczy test obciążenia kilku kluczowych usług.
Plan testu w JMeter
Podstawowy plan ma kilka elementów:
- Thread Group: liczba wirtualnych użytkowników, czas narastania (ramp-up) i czas trwania,
- HTTP Request: żądania do testowanych endpointów,
- HTTP Header Manager: nagłówki, np. token autoryzacji,
- CSV Data Set Config: dane testowe, żeby każdy użytkownik logował się na inne konto,
- Assertions: sprawdzenie kodu odpowiedzi i treści, bo szybki błąd 500 to wciąż błąd.
Ramp-up ustaw tak, żeby ruch narastał stopniowo. Start wszystkich użytkowników w tej samej sekundzie testuje raczej serwer przyjmujący połączenia niż aplikację.
Uruchamiaj bez GUI
Interfejs JMetera służy do budowania planu. Sam test uruchamiaj z linii poleceń, bo GUI zużywa zasoby i zniekształca wyniki:
jmeter -n -t plan.jmx -l wyniki.jtl -e -o raport/Flaga -n wyłącza GUI, -l zapisuje surowe wyniki, a -e -o generuje raport HTML. Katalog raportu musi być pusty.
Generator obciążenia nie powinien stać na tej samej maszynie co testowany system. Inaczej mierzysz, jak obie aplikacje walczą o procesor.
Jak czytać wyniki
Średni czas odpowiedzi ukrywa problemy. Jeśli 90 żądań trwa 100 ms, a 10 trwa 5 sekund, średnia wygląda znośnie, a co dziesiąty użytkownik czeka bardzo długo. Dlatego patrz na:
- percentyle (p95, p99): jak długo czekają najwolniej obsłużeni użytkownicy,
- przepustowość: ile żądań na sekundę system faktycznie obsługuje,
- odsetek błędów: rośnie zwykle razem z obciążeniem,
- zasoby serwera: procesor, pamięć, połączenia do bazy.
Moment, w którym przepustowość przestaje rosnąć, a czasy odpowiedzi idą w górę, wskazuje wąskie gardło.
Środowisko i dane
Wyniki są tyle warte, ile środowisko. Test na małej instancji z pustą bazą nie powie wiele o produkcji. W jednym z moich projektów testowałem wydajność kluczowych usług backendu pod symulowanym obciążeniem produkcyjnym. Przygotowanie realistycznego ruchu to zwykle najbardziej pracochłonna część takiego testu.
Zapisz wersję aplikacji, konfigurację i dane wejściowe. Bez tego nie porównasz dwóch uruchomień.
Podsumowanie
Pierwszy test wydajności nie musi być duży. Jedno pytanie, kilka usług, stopniowe narastanie ruchu i patrzenie na p95 zamiast średniej dają już użyteczną odpowiedź. Jeśli chcesz sprawdzić swój system przed ważnym wydaniem, opisz swój projekt.