Testy wydajnościowe aplikacji webowych: JMeter, k6 i inne narzędzia w praktyce

Po co w ogóle testować wydajność aplikacji webowych?

Wydajność oczami użytkownika, biznesu i zespołu technicznego

Dla użytkownika wydajność to nie „średni czas odpowiedzi 350 ms”, tylko proste odczucie: aplikacja działa szybko albo irytująco wolno. Ma znaczenie, czy strona ładuje się w 1–2 sekundy, czy w 8–10, czy po kliknięciu „Zapisz” trzeba czekać, aż pasek ładowania „dumnie” kręci się kilka kolejnych sekund. To właśnie na tym poziomie wydajność przekłada się na konwersję, porzucone koszyki, liczbę otwieranych zgłoszeń do supportu.

Z perspektywy biznesu wydajność to przede wszystkim stabilność pod obciążeniem i koszt infrastruktury. Szybka aplikacja na przewymiarowanych serwerach może być niepotrzebnie droga. Zbyt wolna pod szczytowym ruchem – generuje straty wprost: klienci odpływają, a zespół gasi pożary. Testy wydajnościowe aplikacji webowych są po to, żeby znaleźć sensowny punkt równowagi między wydanymi pieniędzmi a jakością doświadczenia użytkownika.

Dla zespołu technicznego wydajność to już konkrety: czasy odpowiedzi endpointów, limity baz danych, parametry JVM, wydajność cache’y, przepustowość sieci. Mierzone w RPS (requests per second), p95 czy p99 czasu odpowiedzi, zużyciu CPU, pamięci, I/O. Testy wydajnościowe, szczególnie realizowane przez JMeter w praktyce albo k6 load testing, przekładają się na fakt, że zmiany w kodzie i konfiguracji można weryfikować na liczbach, a nie „bo na moim laptopie działa szybko”.

Typowe objawy problemów wydajnościowych w aplikacjach webowych

Problemy z wydajnością rzadko objawiają się jednym, czytelnym symptomem. Zazwyczaj to mieszanka kilku zjawisk, które użytkownicy i zespół zauważają w różnym momencie:

• Wolne odpowiedzi HTTP – odczuwalne opóźnienia przy przechodzeniu między ekranami, ładowaniu list, uruchamianiu raportów.
• Time-outy – przeglądarka po prostu „czeka i czeka”, a w końcu użytkownik widzi błąd lub pusty ekran.
• Błędy 5xx – szczególnie 500/502/503, często pojawiające się głównie przy większym ruchu lub po dłuższym czasie działania systemu.
• „Zawieszający się” front-end – animacje, które stają w miejscu, formularze, które po kliknięciu nie reagują, mimo że backend jeszcze żyje.
• Duże wahania czasu odpowiedzi – raz jest szybko, raz bardzo wolno, bez wyraźnej przyczyny z punktu widzenia użytkownika.

Na poziomie infrastruktury problemy często widać jako ciągłe 100% CPU, rosnące zużycie pamięci, zapychające się pule połączeń do bazy danych czy kolejki w message brokerach. Dobrze zaplanowane i tanio wykonane testy obciążeniowe i stresowe pozwalają te efekty zobaczyć jeszcze zanim uderzy realny ruch.

Kiedy testy wydajnościowe stają się obowiązkowe

Nie każdy projekt potrzebuje od razu pełnego wachlarza testów performance z rozproszoną infrastrukturą generującą ruch. Są jednak sytuacje, w których testy wydajnościowe aplikacji webowych przestają być „nice to have”, a stają się realną koniecznością:

• Premiera nowego produktu lub dużej funkcjonalności – pierwszy publiczny rollout systemu B2C, uruchomienie nowego modułu pod tysiące użytkowników, nowy panel klienta.
• Silne kampanie marketingowe – gdy marketing „jedzie na pełnym gazie”, ruch w krótkim czasie potrafi wzrosnąć wielokrotnie. Tu testy spike i stress są kluczowe.
• Integracja z dużym klientem – gdy do API podłącza się system korporacyjny, który generuje masowe zapytania lub ma swój harmonogram wsadowy.
• Migracje i zmiany architektury – przenoszenie do chmury, wymiana bazy danych, przejście z monolitu na microservices, zmiany w cache’u, wersji frameworka.
• Rosnące koszty utrzymania – aplikacja „mieli” zasoby, a rachunek za chmurę rośnie. Testy capacity pomagają zrozumieć realne limity i potencjał optymalizacji.

Nawet w mniejszych projektach opłaca się chociaż symboliczny zestaw testów: dwa–trzy scenariusze load i kilka krótkich spike, bo to bardzo tani sposób na złapanie grubych błędów w logice, indeksach baz danych czy konfiguracji serwera HTTP.

Jednorazowe testy vs ciągłe monitorowanie wydajności

Jednorazowe testy obciążeniowe (np. przed premierą) dają odpowiedź na pytanie: „czy w tym momencie, przy tej wersji kodu, ta infrastruktura wytrzyma zaplanowane obciążenie?”. To przydatne, ale krótkotrwałe. Po kolejnych wdrożeniach kodu lub zmianach w architekturze wynik szybko się dezaktualizuje.

Ciągłe testowanie wydajności w CI/CD oznacza, że po każdym (lub wybranych) merge’u do głównej gałęzi uruchamiane są krótkie testy wydajnościowe: np. k6 load testing z 1–2 minutami ruchu dla kilku krytycznych endpointów. Wyniki są porównywane z poprzednimi buildami i jeśli p95 czasu odpowiedzi przekracza ustalony próg, pipeline się zatrzymuje. Daje to tani i szybki sygnał, że ostatnia zmiana mogła pogorszyć performance.

Docelowo warto połączyć oba podejścia: ciągłe, szybkie testy w CI/CD jako bariera przed regresją plus okresowe, głębsze testy load, stress i endurance na osobnych środowiskach, np. przed większymi releasami czy kampaniami.

Podstawowe rodzaje testów wydajnościowych i ich cele

Kluczowe typy testów: load, stress, spike, endurance, capacity

Testy wydajnościowe aplikacji webowych nie są jednorodne. Każdy typ odpowiada na inne pytanie i warto je umiejętnie dobierać.

• Testy obciążeniowe (load) – sprawdzają, jak system zachowuje się pod spodziewanym, typowym lub lekko podniesionym obciążeniem. Celem jest potwierdzenie, że przy np. 500 aktywnych użytkownikach kluczowe scenariusze działają szybko i bez błędów.
• Testy stresowe (stress) – zwiększają obciążenie ponad zakładane maksimum, aby znaleźć punkt załamania. Nie chodzi tylko o to, kiedy zaczynają się błędy, ale też jak system się zachowuje po spadku obciążenia – czy wraca do normy.
• Testy przeciążeniowe (spike) – krótkie, gwałtowne skoki ruchu, np. w ciągu kilku sekund obciążenie rośnie z 50 do 1000 użytkowników równoczesnych. Symulują nagły napływ użytkowników z social media albo błędnie skonfigurowanego klienta API.
• Testy długotrwałe (soak/endurance) – mniejsze obciążenie, ale przez dłuższy czas (kilka–kilkanaście godzin). Szukają wycieków pamięci, narastających opóźnień, problemów z logami, rotacją połączeń.
• Testy pojemnościowe (capacity) – stopniowe podnoszenie obciążenia, aby określić maksymalną przepustowość przy zachowaniu założonej jakości (np. p95 < 500 ms i mniej niż 1% błędów).

Jak dopasować typ testu do pytania biznesowego

Dobór rodzaju testu warto zaczynać od konkretnych pytań, a nie od narzędzia. Narzędzie (JMeter, k6, inne narzędzia open source do testów load) jest tylko sposobem osiągnięcia celu.

• „Czy aplikacja wytrzyma kampanię marketingową?” – potrzebne są testy load (typowe obciążenie w czasie trwania kampanii) i spike (nagłe skoki po wysłaniu newslettera lub posta sponsorowanego). Dobrze jest też zasymulować typową krzywą ruchu w ciągu dnia.
• „Co się stanie, jeśli padnie jeden node aplikacji?” – testy stress lub capacity połączone z awarią jednego z serwerów w trakcie testu. Sprawdza się zarówno reakcję load balancera, jak i zachowanie sesji użytkowników.
• „Czy system może działać 12 godzin dziennie bez restartu?” – test endurance z umiarkowanym, ale realistycznym ruchem, monitorowany pod kątem zużycia pamięci, rosnących czasów odpowiedzi, liczby otwartych połączeń do bazy.
• „Ile realnie użytkowników możemy obsłużyć na obecnej infrastrukturze?” – testy capacity z powolnym zwiększaniem liczby wirtualnych użytkowników i analizą momentu, w którym czasy odpowiedzi i błędy zaczynają wychodzić poza akceptowalne progi.

Najważniejsze metryki w testach wydajnościowych

Surowe liczby bez kontekstu niewiele znaczą. Przy testach wydajnościowych liczą się przede wszystkim:

• Czas odpowiedzi – mierzony zwykle jako p50 (mediana), p95 i p99.
  p95 500 ms oznacza, że 95% żądań kończy się w czasie do 500 ms, ale 5% może być wolniejszych.
• Throughput (RPS / TPS) – liczba żądań na sekundę (requests per second) lub transakcji na sekundę. Pomaga zrozumieć przepustowość systemu.
• Współczynnik błędów – procent odpowiedzi 4xx/5xx w stosunku do wszystkich żądań. Osobno warto śledzić błędy aplikacyjne vs błędy sieciowe/time-outy.
• Zużycie zasobów – CPU, RAM, I/O, liczba otwartych połączeń do bazy, długość kolejek w middleware. To już bardziej monitoring niż samo narzędzie load testing.
• Limity i throttling – parametry warstwy API Gateway, serwera HTTP, reverse proxy, limitów w chmurze (np. IOPS, concurrency), które mogą być niewidoczne w samym kodzie.

Analiza wyników testów wydajności powinna brać pod uwagę zarówno metryki aplikacyjne, jak i te z infrastruktury. Sam JMeter czy k6 nie pokażą, że baza danych ma źle dobrane rozmiary buforów – to widać dopiero w monitoringu.

Przykładowy dobór testów dla małej aplikacji SaaS

Dla niewielkiej aplikacji SaaS z kilkoma kluczowymi funkcjami najczęściej wystarczy:

• 1–2 scenariusze testów load skupione na logowaniu, przeglądaniu listy i edycji danych, z obciążeniem odpowiadającym spodziewanej liczbie równoczesnych użytkowników.
• 1 prosty scenariusz testu spike – np. nagły wzrost z 10 do 200 użytkowników w ciągu kilkunastu sekund, utrzymanie tej liczby przez kilka minut i powrót.
• Kilka krótkich testów capacity raz na kilka miesięcy lub przed większą kampanią, aby sprawdzić, czy aktualna infrastruktura nadal „trzyma poziom”.

Pełne testy endurance przy wielogodzinnym obciążeniu są w takim przypadku często ponad miarę – zjadają czas, zasoby i budżet, a realnie niewiele wnoszą przy prostej architekturze. Lepiej zainwestować w dobrze zautomatyzowane, krótkie testy w CI/CD i podstawowy monitoring produkcji.

Pułapki nadmiernego upraszczania testów wydajnościowych

Oszczędność jest dobra, ale zbyt mocne cięcie zakresu potrafi wypaczyć sens całego procesu. Typowe błędy:

• Testowanie tylko jednego endpointu – np. samego logowania, bez dalszej nawigacji. W efekcie nie widać problemów z najbardziej kosztownymi operacjami.
• Pominięcie autoryzacji i sesji – testowanie jednego publicznego endpointu z wyłączonym JWT to fałszywy obraz realnego scenariusza, który wymaga walidacji tokenu, odczytu profilu, uprawnień.
• Ignorowanie frontendu – skupianie się wyłącznie na API, mimo że realny użytkownik czeka na wyrenderowanie SPA, pobranie assetów, działanie JS w przeglądarce.
• Nierealistyczne dane – testowanie na bazie z kilkudziesięcioma rekordami, podczas gdy produkcja będzie miała ich setki tysięcy. Indexy zachowują się zupełnie inaczej.

Przy ograniczonych zasobach lepiej zbudować 3–4 sensowne scenariusze, które odzwierciedlają prawdziwe zachowania użytkowników, niż 20 technicznych skryptów generujących „ładne” RPS-y, ale z małą wartością diagnostyczną.

Planowanie testów wydajnościowych: scenariusze, dane, środowisko

Wybór scenariuszy testowych: gdzie realnie „boli”

Zanim wejdzie w grę JMeter czy k6, trzeba zdecydować, co właściwie testować. Najwięcej korzyści dają scenariusze oparte na realnym użyciu aplikacji:

• Najczęściej używane funkcje – przeglądanie list, filtrowanie, formularze, dashboardy. Tu nawet niewielkie opóźnienia są dotkliwe, bo użytkownicy wykonują te operacje wielokrotnie.
• Najdroższe operacje – generowanie raportów, eksport danych, masowe importy, skomplikowane wyszukiwanie. Te akcje rzadziej się pojawiają, ale mocno obciążają bazę.
• Krytyczne ścieżki biznesowe – np. rejestracja, logowanie, płatność, złożenie zamówienia. Awaria lub spowolnienie w tych miejscach uderza bezpośrednio w przychody.

Jeśli brakuje twardych danych z produkcji, można oprzeć się na logach serwera, analityce frontendu (np. zdarzenia w GA, Matomo) albo krótkim nagraniu ruchu z realnego środowiska i przełożeniu go na uproszczone scenariusze. W małym zespole często wystarczy lista 3–5 kluczowych „historii użytkownika”, z których każda zostanie potem zamieniona na 1 skrypt w JMeterze czy k6. Resztę funkcji lepiej pokryć monitoringiem na produkcji niż inwestować w rozbudowane, rzadko odpalane testy load.

Drugim krokiem jest dobranie realistycznych danych testowych. Zbyt „czysta” baza daje złudnie dobre wyniki: brak fragmentacji indexów, brak starych rekordów, minimalna liczba powiązań. W praktyce wystarczy zanonimizowany zrzut części produkcyjnych danych albo generator, który tworzy kilka–kilkanaście procent oczekiwanej docelowej skali (liczba użytkowników, zamówień, wpisów). Przy ograniczonym budżecie lepiej zainwestować parę godzin w prosty skrypt seedujący bazę niż później gonić problemy z wydajnością na produkcji.

Środowisko testowe nie musi być identyczne z produkcją, ale musi być przewidywalne. Jeśli infrastruktura jest mniejsza (np. połowa CPU i RAM), wyniki nadal mają sens, o ile da się je przeliczyć i świadomie uwzględnić różnice. Kluczowe jest ograniczenie „szumu”: wyłączanie zbędnych cronów, jednorazowych migracji, równoległych testów innych zespołów. Przy chmurowych środowiskach dobrze działa prosty standard: jedna osobna instancja bazy + jedno „okno” na testy load w tygodniu, żeby nikt nie wrzucał w tym czasie eksperymentalnych buildów.

Na koniec potrzebna jest choćby minimalna automatyzacja: skrypty do uruchamiania testów, zrzucania wyników i przywracania stanu środowiska. Nawet prosty Makefile czy kilka komend w README oszczędzają godziny ręcznego klikania. Dzięki temu testy wydajnościowe stają się powtarzalną czynnością, którą można uruchomić przed większym releasem, a nie jednorazowym „projektem specjalnym”, do którego nikt nie chce wracać, bo jest za drogi i zbyt czasochłonny.

Taki pragmatyczny zestaw: kilka sensownych scenariuszy, przyzwoite dane, przewidywalne środowisko i lekka automatyzacja, w większości małych i średnich projektów daje lepszy efekt niż rozbudowane, ale odpalane raz na rok testy z wyrafinowanymi narzędziami. Dzięki temu decyzje o kolejnych krokach – czy dokładamy serwer, optymalizujemy zapytania, czy może zmieniamy limit RPS w API Gateway – opierają się na twardych liczbach, a nie na przeczuciach.

Przegląd narzędzi do testów wydajnościowych: JMeter, k6 i spółka

Apache JMeter – klasyk „wszystko w jednym”

JMeter od lat jest domyślnym wyborem, szczególnie w organizacjach, które zaczynały od testów ręcznych i szukały graficznego narzędzia do generowania obciążenia.

• Plusy:
  • GUI ułatwiające start osobom nietechnicznym – klikane scenariusze, podgląd requestów, nagrywanie ruchu przez proxy.
  • Bogaty zestaw protokołów: HTTP(S), JDBC, JMS, FTP, WebSocket (przez pluginy) i wiele innych – można jednym narzędziem obciążać różne warstwy.
  • Ogrom ekosystemu pluginów: dodatkowe raporty, samplery, integracje z CI.
  • Możliwość odpalenia w trybie „headless” z linii komend – nadaje się do CI/CD.
• Minusy:
  • GUI kusi, żeby wszystko robić ręcznie i „klikać” scenariusze, co utrudnia wersjonowanie i code review.
  • Przy większej liczbie wirtualnych użytkowników GUI staje się ociężałe; wymaga osobnych „load generatorów”, żeby nie zabijać jednej maszyny.
  • Scenariusze w XML są mało czytelne w porównaniu z podejściem „test as code”.

W realnych projektach JMeter sprawdza się szczególnie tam, gdzie istnieją już zespoły QA z doświadczeniem w narzędziach graficznych i priorytetem jest szybkie zbudowanie kilku scenariuszy bez dużej inwestycji w naukę nowego języka.

k6 – podejście „testy jako kod”

k6 jest dużo młodszy, ale przyjął się w zespołach developerskich, które lubią wszystko trzymać w repozytorium i wersjonować jak zwykły kod.

• Plusy:
  • Scenariusze w JavaScript – łatwe do wersjonowania, review i integracji z narzędziami deweloperskimi.
  • Bardzo małe zużycie zasobów przy generowaniu dużego obciążenia, zwłaszcza w trybie CLI.
  • Naturalna integracja z CI/CD – prosta komenda, sensowny exit code, raport w JSON.
  • Dobre wsparcie dla testów opartych na metrykach (thresholds), np. „p95 < 400ms lub build failuje”.
• Minusy:
  • Brak klasycznego, rozbudowanego GUI – dla części QA to bariera wejścia.
  • Mniejszy ekosystem pluginów niż w JMeterze (chociaż podstawy do HTTP/WS są bardzo solidne).
  • Wymaga minimalnego obycia z JS i Gitem; dla stricte manualnych testerów to dodatkowy próg.

k6 zwykle sprawdza się, gdy ciężar testów wydajnościowych spada bardziej na developerów niż na osobny zespół QA, a scenariusze mają żyć w tym samym cyklu co kod aplikacji.

Gatling, Locust i inne alternatywy

Poza JMeterem i k6 istnieje kilka narzędzi, które nie są aż tak popularne, ale w niektórych przypadkach wypadają korzystnie.

• Gatling – scenariusze pisze się w Scali (jest też DSL dla Javy/Kotlina). Bardzo wydajny silnik, dobra integracja z JVM i bogate raporty HTML. Minus: próg wejścia, jeśli zespół nie zna Scali.
• Locust – testy w Pythonie; prosty model użytkownika jako klasy, łatwe sterowanie ruchem. Plusem jest Python, który bywa znany w zespołach QA, minusem – mniejsza wydajność pojedynczego workera w porównaniu np. z k6.
• Artillery, vegeta – lekkie narzędzia CLI do HTTP, dobre do prostych scenariuszy, sanity checków i integracji z CI. Ograniczone, gdy trzeba symulować złożone ścieżki użytkownika.

Przy ograniczonym budżecie sensowna strategia to wybranie jednego głównego narzędzia (np. k6 lub JMeter) i ewentualne dołożenie małego, prostego narzędzia CLI do szybkich, lokalnych testów programistów.

Jak dobrać narzędzie do zespołu i projektu

Zamiast porównywać czysto techniczne parametry, lepiej zestawić narzędzia z realiami zespołu i projektu:

• Jeśli zespół QA jest silny, a deweloperzy są obciążeni – JMeter bywa wygodniejszy na start, bo pozwala QA szybko zbudować scenariusze bez wchodzenia w JS, a dopiero później je „uszczuplać” i automatyzować.
• Jeśli kultura „infrastructure as code” i CI/CD jest już ugruntowana – k6 naturalnie wpasowuje się w taki proces i mniej boli utrzymanie testów w dłuższym okresie.
• Dla startupu z małym zespołem – zwykle wygrywa prostota: 1–2 skrypty w k6 w repo projektu, odpalane z GitHuba lub GitLaba przy większych zmianach, zamiast rozbudowanej instalacji JMetera.

Najdroższe nie jest narzędzie, tylko utrzymanie scenariuszy i środowiska. Lepiej wybrać coś, co „dobrze leży” zespołowi, niż narzędzie z najdłuższą listą funkcji.

JMeter w praktyce: szybkie wejście, tworzenie i uruchamianie testów

Minimalna konfiguracja JMetera – co faktycznie jest potrzebne

Świeża instalacja JMetera kusi ogromem opcji, ale do pierwszych sensownych testów wystarczy kilka elementów:

• Test Plan – kontener na wszystkie elementy scenariusza; tutaj trzyma się zmienne globalne, configi i logikę.
• Thread Group – definicja liczby wirtualnych użytkowników, ramp-upu (czas „rozkręcania” ruchu) i czasu trwania testu.
• HTTP Request Defaults – podstawowa konfiguracja hosta, portu, protokołu, żeby nie powtarzać ich przy każdym żądaniu.
• HTTP Sampler – pojedyncze żądania (GET, POST itd.), z których składa się scenariusz użytkownika.
• CSV Data Set Config – źródło danych wejściowych: loginy, ID rekordów, parametry filtrów.
• View Results in Table / Summary Report – lekkie listenery do podstawowego podglądu wyników (ale nie przy dużych testach).

Resztę – rozbudowane raporty w UI, kilkanaście listenerów, kolorowe wykresy – lepiej zostawić na później. Każdy dodatkowy element w planie testów to dodatkowe zużycie pamięci i większe ryzyko, że narzędzie będzie „wąskim gardłem”.

Prosty scenariusz HTTP krok po kroku

Sensowny, a zarazem tani czasowo plan na pierwszy test JMetera można zrealizować w kilku krokach.

1. Utworzenie Test Planu
   • Nowy Test Plan, opcjonalnie globalne zmienne (np. adres hosta, environment) w zakładce User Defined Variables.
   • Dodanie Thread Group – np. 50 użytkowników, ramp-up 60 sekund, liczba pętli „forever” i czas trwania testu ustawiony w schedulerze (np. 5–10 minut na start).
2. Konfiguracja HTTP
   • Dodanie HTTP Request Defaults z adresem API/serwisu, ścieżki szczegółowe będą definiowane w poszczególnych samplerach.
   • Ustawienie timeoutów żądań tak, aby nie „wisieć” zbyt długo na jednym requestcie (zwykle kilka sekund). To ogranicza fałszywie dobre wyniki.
3. Dodanie scenariusza użytkownika
   • W ramach Thread Group sekwencja HTTP Samplerów: logowanie, pobranie listy, otwarcie szczegółu, zapis zmiany.
   • Między krokami umieszczenie Timers (np. Constant Timer z krótkim opóźnieniem, Uniform Random Timer) symulujących czas namysłu użytkownika.
4. Obsługa sesji i parametrów
   • Dodanie HTTP Cookie Manager, aby przeglądarka była poprawnie emulowana i sesja utrzymywała się między żądaniami.
   • Jeżeli API używa tokenu JWT – pobranie go przy logowaniu (post-processorem, np. JSON Extractor) i ustawienie w nagłówkach kolejnych requestów.
5. Źródło danych
   • CSV Data Set Config wskazujące plik z loginami, hasłami, ID rekordów. Każdy wątek dostaje swoją linię lub odczytuje je współdzieląc (zależnie od konfiguracji).
   • Dane CSV najlepiej generować prostym skryptem, np. w Pythonie czy nawet w Excelu, zamiast „klepać” ręcznie kilka rekordów.

Taki scenariusz można przygotować w ciągu kilku godzin i daje już sensowny obraz zachowania systemu, zamiast kręcić się w kółko wokół pojedynczego endpointu.

Parametryzacja i korelacja odpowiedzi

Bez dynamicznego reagowania na odpowiedzi serwera test staje się mało realistyczny. Użytkownik nie działa zawsze na tych samych ID, a aplikacja często zwraca dane, które trzeba wykorzystać w kolejnych krokach.

• Parametryzacja – wprowadzenie zmiennych w ścieżkach i body żądań (np. /orders/${orderId}) w oparciu o dane z CSV, zmienne z poprzednich kroków czy funkcje JMetera (np. generujące losowy numer).
• Korelacja – wyciąganie z odpowiedzi serwera fragmentów JSON/HTML/XML i wstrzykiwanie ich do kolejnych żądań:
  • JSON Extractor do pobrania np. userId z odpowiedzi logowania.
  • Regular Expression Extractor do wyciągania tokenów lub identyfikatorów z HTML, jeśli interfejs nie jest czystym API.

Tu przydaje się krótkie „proof of concept”: kilka requestów z włączonym listenerem View Results Tree, analiza odpowiedzi i szybkie prototypowanie ekstraktorów, zanim zacznie się odpalać pełny test z dziesiątkami użytkowników.

Uruchamianie JMetera w trybie bez GUI

JMeter w trybie GUI nadaje się do budowy i debugowania scenariuszy, ale do właściwych testów obciążeniowych lepiej przejść na tryb non-GUI. To sposób, żeby nie przepalać RAM-u i CPU na rysowanie wykresów.

Podstawowy schemat:

• Scenariusz zapisany jako plik .jmx trzymany w repozytorium.
• Uruchomienie: jmeter -n -t test-plan.jmx -l results.jtl -Jusers=100 -Jduration=600
• Parametry (np. liczba użytkowników, czas trwania) przekazywane przez -J i przypięte w planie testów jako zmienne.

Takie podejście pozwala mieć jeden scenariusz i kilka „profilów” obciążenia – osobne joby w CI z różnymi wartościami users/duration zamiast trzymania trzech różnych plików JMX, które z czasem i tak się rozjadą.

Rozdzielenie fazy debugowania i fazy obciążenia

Łączenie debugowania skryptu z właściwymi testami load to szybka droga do frustracji: trudno odróżnić błędy w scenariuszu od prawdziwych problemów wydajnościowych.

Praktyczny podział pracy:

• Faza debug:
  • 1 użytkownik, kilka pętli.
  • Włączony View Results Tree i może 1–2 inne listenery.
  • Analiza, czy sesja się utrzymuje, dane się zmieniają, a ekstraktory działają.
• Faza load:
  • Dziesiątki / setki użytkowników, dłuższy czas trwania.
  • Wyłączone ciężkie listenery (szczególnie graficzne); zbieranie tylko minimum (np. JTL do pliku, agregacja po teście).
  • Równoległy monitoring infrastruktury (APM, metryki bazy, CPU, RAM).

Dzięki temu testy obciążeniowe nie „zjadają” zasobów na UI, a problemy związane z samym skryptem wychwytywane są wcześnie, na tanim etapie pojedynczego użytkownika.

Raporty i analiza wyników z JMetera

Surowy JTL nie jest zbyt czytelny, ale JMeter oferuje mechanizm generowania raportów HTML. Można to połączyć z trybem non-GUI, bez dorzucania ciężkich listenerów do samego testu.

1. Uruchomienie testu z logowaniem do pliku results.jtl.
2. Po zakończeniu testu:
   • jmeter -g results.jtl -o report/ – generacja raportu HTML.
   • Raport zawiera rozkłady czasów odpowiedzi, throughput, błędy, percentyle.

W małych zespołach najprościej jest wrzucić taki raport jako artefakt w CI/CD lub podlinkować go w systemie ticketowym przy większych zmianach. Nie wymaga to specjalnych licencji ani dodatkowych serwerów, a pozwala wrócić do wyników po czasie.

Optymalizacja samego JMetera – jak nie przepalać zasobów

Przy większych testach wąskim gardłem bywa nie aplikacja, tylko maszyna uruchamiająca JMetera. Żeby tego uniknąć:

• Uruchamiać testy na możliwie „gołej” maszynie: bez przeglądarki, komunikatorów, IDE – każdy dodatkowy proces zabiera RAM i wpływa na stabilność obciążenia.
• Ograniczyć logowanie do minimum: wyłączyć szczegółowe logi w jmeter.properties, nie zapisywać pełnych response data, jeżeli nie jest to konieczne do analizy błędów.
• Rozbijać duże testy na kilka mniejszych instancji JMetera (tzw. distributed testing), zamiast próbować „upchnąć” tysiące wątków na jednym hostcie.
• Używać prostych samplerów i komponentów – skrypty Beanshell/Javascript czy ciężkie procesory wyrażeń wykonywane setki razy na sekundę potrafią zabić wydajność generatora obciążenia.

Dobrym nawykiem jest szybki „test testu”: uruchomienie tego samego scenariusza z rosnącą liczbą wątków i obserwacja, czy rośnie przede wszystkim obciążenie aplikacji, czy już maszyny z JMeterem. Jeśli to drugie, bardziej opłaca się dodać drugą lekką maszynę z kolejną instancją narzędzia niż inwestować czas w doktorat z tuningu jednego hosta.

Przy dłuższych kampaniach obciążeniowych nie zaszkodzi prosta automatyzacja: skrypty powłoki uruchamiające test, zrzucające wyniki, generujące raport oraz podstawowe wykresy z systemu monitoringu. Niewielki nakład pracy, a po kilku iteracjach mamy powtarzalny proces, który można odpalać nawet „po godzinach” bez ręcznego klikania.

Jeżeli JMeter zaczyna być zbyt ciężki, a nie chcemy od razu migrować całego zestawu scenariuszy, sensowny kompromis to miks narzędzi: JMeter zostaje jako „kombajn” do bardziej skomplikowanych ścieżek z korelacją i nietypowymi protokołami, a prostsze testy HTTP/S przenosi się do lżejszych rozwiązań (np. k6) uruchamianych w CI. Taki podział zwykle daje najlepszy stosunek wysiłku do efektu.

Praktyczny proces testów wydajnościowych nie wymaga drogich licencji ani tygodni przygotowań. Wystarczy kilka sensownych scenariuszy, podstawowa automatyzacja, lekkie narzędzia i konsekwencja w porównywaniu wyników po każdej większej zmianie. Dzięki temu łatwiej wychwycić problemy, zanim zrobi to produkcja – i to stosunkowo niskim kosztem.

k6 jako lekkie narzędzie do testów w pipeline CI/CD

k6 dobrze uzupełnia JMetera tam, gdzie potrzebne są szybkie, powtarzalne testy w CI/CD, pisane w prostym kodzie zamiast klikania scenariuszy. Scenariusz to zwykły plik JavaScript, który łatwo trzymać w repozytorium i code-reviewować tak jak każdą inną zmianę.

Najprostszy szkielet testu HTTP wygląda tak:

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  vus: 20,
  duration: '2m',
};

export default function () {
  const res = http.get('https://example.com/api/orders');

  check(res, {
    'status is 200': (r) => r.status === 200,
    'response < 500ms': (r) => r.timings.duration < 500,
  });

  sleep(1); // think time
}

Bez instalowania ciężkiego UI, bez dodatkowych plików konfiguracyjnych. Jeden plik JS, jedna komenda, wyniki w konsoli lub do eksportu w JSON.

Budowa scenariuszy w k6 – od prostego do używalnego

k6 dobrze skaluje się złożonością scenariusza: od prostego smoke testu po bardziej rozbudowaną ścieżkę użytkownika. Klucz to umiar i skupienie się na tym, co naprawdę wpływa na wydajność.

• Funkcje pomocnicze – lepiej wydzielić logowanie, pobranie listy, zapis zmian do osobnych funkcji niż kopiować żądania:

  function login() {
    const payload = JSON.stringify({ username: 'user', password: 'pass' });
    const res = http.post('https://example.com/api/login', payload, {
      headers: { 'Content-Type': 'application/json' },
    });
    return res.json('token');
  }

• Reuse tokenów – zamiast logować się na każdym żądaniu, logowanie raz na iterację użytkownika lub nawet raz na test (dla smoke) drastycznie zmniejsza obciążenie autoryzacji.
• Think time – funkcja sleep() pozwala wprowadzić przerwy między krokami scenariusza. Bez tego test mierzy maksymalną przepustowość API, a nie zachowanie przy realistycznym ruchu.
• Konfiguracja zewnętrzna – host, ścieżki czy czasy trwania wygodniej trzymać w zmiennych środowiskowych:

  const BASE_URL = __ENV.BASE_URL || 'https://example.com';

Parametryzacja i dane testowe w k6

Statyczne requesty w pętli szybko przestają być użyteczne. Do sensownych testów potrzebne są dane: użytkownicy, identyfikatory, payloady. k6 daje kilka tanich sposobów na ich obsługę.

• CSV / JSON wczytywany do pamięci – przy niewielkich datasetach najprościej wrzucić plik do repozytorium i załadować go na starcie:

  import { SharedArray } from 'k6/data';
  import papaparse from 'https://jslib.k6.io/papaparse/5.1.1/index.js';
  
  const users = new SharedArray('users', function () {
    const csv = open('./users.csv');
    return papaparse.parse(csv, { header: true }).data;
  });
  
  export default function () {
    const user = users[__VU % users.length]; // rozdział danych między VU
    // ...
  }

• Proste generowanie danych w locie – identyfikatory, losowe numery, parametry paginacji można generować w kodzie (np. Math.random(), inkrementacja licznika).
• Przy większych datasetach – zamiast ładować dziesiątki tysięcy rekordów z pliku, lepiej:
  • przygotować mniejszą próbkę, która i tak pokryje większość scenariuszy,
  • albo dociągać dane przez dedykowaną „seedującą” usługę/API, uruchamianą przed testem.

Korelacja i praca na odpowiedziach w k6

Przeniesienie idei korelacji z JMetera do k6 jest dość naturalne – to po prostu operacje na JSON/tekście w JavaScript.

• API JSON:

  const res = http.get(`${BASE_URL}/api/orders`);
  const body = res.json();
  const orderId = body[0].id;
  
  const detail = http.get(`${BASE_URL}/api/orders/${orderId}`);

• HTML / regex – gdy trzeba wyciągnąć token z HTML:

  const res = http.get(`${BASE_URL}/page`);
  const match = res.body.match(/name="csrf" value="([^"]+)"/);
  const csrfToken = match && match[1];

• Walidacje – check() pozwala od razu zliczać błędy korelacji jako błędy testu zamiast cichych porażek:

  check(res, {
    'csrf extracted': () => !!csrfToken,
  });

Scenariusze i profile obciążenia w k6

Jednym z mocniejszych punktów k6 są wbudowane scenariusze – różne wzorce rampowania ruchu bez dorabiania własnej logiki w kodzie testu.

Przykładowa konfiguracja kilku profili w jednym pliku:

export const options = {
  scenarios: {
    smoke: {
      executor: 'constant-vus',
      vus: 2,
      duration: '30s',
      exec: 'smokeTest',
      startTime: '0s',
    },
    load: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [
        { duration: '2m', target: 50 },
        { duration: '5m', target: 50 },
        { duration: '2m', target: 0 },
      ],
      exec: 'loadTest',
      startTime: '30s',
    },
  },
};

export function smokeTest() { /* ... */ }
export function loadTest() { /* ... */ }

Przy ograniczonym czasie najprościej trzymać osobne pliki na różne cele: smoke.js, load.js, stress.js. Mniej elastyczne, ale prostsze do utrzymania w małych zespołach, gdzie nikt nie ma etatu tylko na testy.

Integracja k6 z CI i tanie raportowanie

CLI k6 dobrze wpasowuje się w pipeline’y typu GitLab CI, GitHub Actions, Jenkins czy Azure DevOps. Najbardziej ekonomiczny wariant to uruchomienie binarki w kontenerze i zrzut wyników do zwykłych plików.

• Wyniki w JSON:

  k6 run --out json=results.json load.js

  JSON można potem:

  • wczytać do prostego skryptu (Python/Node) i wyliczyć średnie, percentyle,
  • albo wrzucić do narzędzi typu Grafana k6-dashboards (jeśli firma już używa Grafany).
• Prosty gating w CI – najtańsza kontrola jakości:
  • uruchom test p50/p95 na małym ruchu (np. 10–20 VU, 2–3 minuty),
  • po teście skryptem sprawdź, czy średnie i percentyle mieszczą się w ustalonym budżecie (np. p95 < 800 ms),
  • jeśli nie – przerwij pipeline z konkretnym komunikatem, bez dalszych analiz.
• Bez SaaS na start – wersja open source wystarcza do większości zadań; płatne k6 Cloud można rozważyć dopiero, gdy brakuje czasu na ręczną analizę lub gdy testy robi się regularnie na większą skalę.

Łączenie JMetera i k6 w jednym procesie

Kombinacja „cięższego” JMetera i lekkiego k6 rozwiązuje większość przypadków bez kupowania komercyjnych pakietów. Rozsądny podział ról wygląda tak:

• JMeter:
  • skomplikowane ścieżki z korelacją na kilku systemach,
  • testy niskopoziomowych protokołów (JDBC, JMS, FTP, legacy),
  • wstępne „kampanie” przy dużych zmianach architektury.
• k6:
  • regularne smoke/load testy API w CI,
  • szablony testów dla mikroserwisów, szybko kopiowane między repozytoriami,
  • sprawdzenie hipotez performance’owych przy pojedynczych PR-ach (np. zmiana algorytmu sortowania).

Efekt: zespół nie przepala czasu na przepisywanie istniejących scenariuszy z JMetera, a nowe rzeczy od razu lądują w lżejszym, łatwiejszym do automatyzacji narzędziu.

Inne narzędzia, które czasem robią różnicę

Zdarzają się scenariusze, w których ani JMeter, ani k6 nie są idealne. Zanim zacznie się pisać własne generatory ruchu, opłaca się sprawdzić kilka mniej popularnych opcji.

• Gatling
  • Scenariusze w Scali lub (w wersji Enterprise) w Javie/Kotlinie.
  • Dobry do ciężkich testów HTTP/HTTPS, świetne zarządzanie pamięcią.
  • Minus: próg wejścia wyższy niż w k6; do prostych testów API często overkill.
• Locust
  • Scenariusze w Pythonie – atrakcyjne dla zespołów, które i tak używają Pythona do automatyzacji.
  • Elastyczny model użytkownika „zachowującego się” w pętlach.
  • Wymaga więcej konfiguracji i dbałości o własny kod, żeby sam generator nie był wąskim gardłem.
• wrk / hey / vegeta
  • Małe narzędzia CLI do prostych testów HTTP.
  • Idealne do krótkich, jednowymiarowych testów przepustowości pojedynczego endpointu.
  • Brak złożonych scenariuszy, korelacji i zaawansowanej parametryzacji – dobra „sonda” na start, nie pełnoprawny framework.

Przy ograniczonym budżecie zdrowa strategia to jedno „narzędzie główne” i maksymalnie jedno-dwa dodatkowe, dobrze oswojone. Dziesięć różnych frameworków w organizacji zwykle kończy się tym, że nikt nie ma czasu, żeby w którymkolwiek się naprawdę wyspecjalizować.

Dobór metryk i progów akceptacji bez doktoratu z statystyki

Bez sensownie dobranych metryk testy wydajnościowe szybko zamieniają się w produkowanie wykresów bez decyzji. Nie trzeba jednak od razu stawiać całej teorii kolejek – na początek w zupełności wystarczy kilka prostych zasad.

• Czasy odpowiedzi:
  • p50 (mediana) – jak działa system dla „typowego” użytkownika,
  • p95/p99 – górny „ogon”, który użytkownicy faktycznie odczuwają jako wolne działanie.
  • Średnia bywa myląca – pojedyncze „piki” potrafią ją zawyżyć lub zaniżyć.
• Throughput (requests per second) – przydatny przy porównywaniu dwóch wersji systemu lub dwóch konfiguracji infrastruktury.
• Rate błędów – odsetek requestów z kodami 4xx/5xx; powyżej kilku promili przy stabilnym obciążeniu to zazwyczaj sygnał problemu.
• Stabilność w czasie – powolne „pełzanie” czasów odpowiedzi w górę przy dłuższym teście często oznacza wycieki pamięci, rosnące kolejki, brak indeksów w bazie.

Progi akceptacji najlepiej zdefiniować w języku biznesu: „dla scenariusza X przy ruchu Y, 95% odpowiedzi poniżej Z ms”. Dopiero z tak opisanym celem można sensownie dobrać parametry testu.

Monitoring aplikacji i infrastruktury podczas testów

Same narzędzia load-testingowe pokazują tylko objawy. Żeby wiedzieć, gdzie faktycznie leży problem, trzeba równolegle patrzeć na metryki aplikacji i infrastruktury. Nie musi to być od razu pełen APM z górnej półki.

• Minimum infrastrukturalne:
  • CPU, RAM, I/O dysku, network na serwerach aplikacyjnych i bazie.
  • Liczba połączeń do bazy, kolejki w message brokerach.
  • Dostępne są darmowe stacki (Prometheus + Grafana), ale na start wystarczą nawet wbudowane metryki chmurowe (CloudWatch, Azure Monitor, GCP Monitoring).
• Metryki aplikacyjne:
  • czas wykonania kluczowych endpointów po stronie serwera,
  • ilość timeoutów, wyjątków, retry,
  • długość i liczba zapytań do bazy w newralgicznych fragmentach.
• Minimalny APM „na start” – często wystarczy darmowy tier narzędzi typu Application Insights, Elastic APM czy Jaeger z prostym samplingiem, żeby zobaczyć, które zapytanie SQL zaczyna dławić system.

Dobry nawyk to robienie zrzutów lub eksportu dashboardów w momencie testu – po miesiącu trudno odtworzyć, co właściwie działo się na serwerach podczas tamtej iteracji.

Przy powtarzalnych kampaniach dobrze działa prosty „szablon obserwacji”: przed testem zapisany screen z kluczowych dashboardów, w trakcie szybkie notatki z godziną wystąpienia anomalii, po teście – drugi screen do porównania. Taki ręczny log często bywa cenniejszy niż idealnie zebrane, ale później już nieodtwarzalne metryki. Zwłaszcza w małych zespołach, gdzie nikt nie ma czasu budować zaawansowanych, automatycznych raportów.

Do większych iteracji opłaca się mieć jedno miejsce, w którym zbiegają się dane z narzędzia testowego, monitoringu i logów aplikacyjnych. Nie musi to być drogi APM – często wystarcza wspólny dashboard w Grafanie i kilka dopracowanych widoków w narzędziu do logów (np. Elastic, Loki, Cloud Logging). Kluczowe jest to, żeby każdy w zespole wiedział, „gdzie patrzeć”, gdy w trakcie testu p95 nagle rośnie lub system zaczyna zwracać błędy.

Jeśli infrastruktura działa w chmurze, tańszą drogą bywa maksymalne wykorzystanie tego, co już jest opłacone w abonamencie. CloudWatch, Azure Monitor czy GCP Monitoring z sensownymi alarmami i odrobiną pracy nad czytelnymi dashboardami potrafią zastąpić drogie dodatki. Dopiero gdy te podstawowe narzędzia przestają wystarczać (np. brakuje śledzenia requestu przez kilka mikroserwisów), ma sens rozglądać się za kolejnymi usługami.

Dobrze poukładane testy wydajnościowe nie wymagają wielkiego budżetu ani osobnego działu performance. Wystarczy kilka jasno opisanych scenariuszy, jedno-dwa oswojone narzędzia (JMeter, k6 lub ich odpowiednik), sensowny monitoring i nawyk dokumentowania wyników. Z takim zestawem da się wcześnie wyłapywać problemy, planować pojemność i bronić decyzji technicznych przed biznesem, zamiast gasić pożary dopiero po wdrożeniu na produkcję.

Typowe antywzorce w testach wydajnościowych

Narzędzia mogą być świetne, a mimo to testy nie przynoszą żadnej realnej wartości. Najczęściej problemem nie jest technologia, tylko sposób jej użycia. Kilka wzorców, które regularnie zabijają sens całych kampanii:

• Testy „na oko” bez celu – odpalanie scenariusza, patrzenie na wykresy, po czym konkluzja „chyba jest ok”. Bez zdefiniowanych progów i pytania, na które test ma odpowiedzieć, wyniki nadają się tylko do prezentacji, nie do decyzji.
• Mieszanie problemów funkcjonalnych i wydajnościowych – próby diagnozy błędów logiki biznesowej na podstawie testów load. Najpierw stabilne funkcjonalne QA, dopiero potem sensowny performance; inaczej większość czasu schodzi na łatanie 500-ek i walidacji, a nie na realną wydajność.
• Brak stabilizacji środowiska – start testu chwilę po deployu, gdy JVM się dogrzewa, cache pusty, a auto-scaling w trakcie ruchu adaptuje konfigurację. Wyniki są losowe, p95 pływa, nikt nie wie, co porównuje z czym.
• Przeładowane scenariusze – jeden test ma zawierać wszystkie możliwe ścieżki naraz. Analiza staje się niemożliwa, bo nie da się zrozumieć, które zapytanie zrobiło dziurę w CPU lub zaczęło topić bazę.
• Brak kontroli nad danymi – scenariusz wchodzi za każdym razem na inne dane (np. różne rozmiary koszyka, różne typy klientów), więc rozkład czasów odpowiedzi zmienia się losowo. Porównywanie iteracji jest wtedy fikcją.
• Ignorowanie błędów w narzędziu – wysokie CPU/GC na maszynie z JMeterem lub k6, a wnioski formułowane tak, jakby to była realna wydajność aplikacji. Generator pada, backend się nudzi, ale wykres wygląda groźnie.

Prosty filtr: jeśli po teście nie da się w jednym zdaniu odpowiedzieć na pytanie „co zmierzyliśmy i czy jest akceptowalne”, to scenariusz lub organizacja testu są do poprawy.

Praktyczne wzorce pisania scenariuszy w JMeterze

Przy większych projektach scenariusze JMetera szybko rosną. Bez porządku kończy się na jednym pliku .jmx z setkami elementów, którego nikt nie chce dotknąć. Kilka nawyków pozwala tego uniknąć.

Modularna struktura planu testów

Zamiast jednego monolitycznego Thread Groupa lepiej ułożyć plan jak prostą „aplikację”: moduły, które można składać i testować osobno.

• Oddzielne Thread Groupy na use case’y – np. „logowanie”, „przeglądanie katalogu”, „złożenie zamówienia”. Łatwiej sterować proporcjami ruchu oraz wyłączać fragmenty na czas debugowania.
• Reusable Controllers – Module Controller + Include Controller dla wspólnych fragmentów (logowanie, pobranie tokena, wspólne nagłówki). Jeden błąd poprawia się w jednym miejscu.
• Konwencje nazewnicze – prosty prefiks typu [SETUP], [MAIN], [CLEANUP] pozwala po pół roku nadal zrozumieć, co jest czym, bez otwierania każdego elementu.

Parametryzacja bez spaghetti

Ręczne grzebanie w adresach i liczbach użytkowników w środku scenariusza szybko prowadzi do pomyłek. Dużo taniej jest wydzielić wszystkie zmienne do jednego miejsca.

• Test Plan > User Defined Variables – podstawowe parametry: host, port, protokół, domyślne timeouty. Wystarczy jedna zmiana, żeby wskazać inny endpoint.
• Pliki .properties – konfiguracja środowisk (dev, test, preprod) w osobnych plikach, odpalanie: jmeter -q dev.properties -t test.jmx. Zmiana środowiska bez otwierania GUI.
• CSV Data Set Config – dane wejściowe (loginy, ID produktów, kombinacje parametrów) poza scenariuszem. Przy przebudowie endpointów aktualizuje się plik CSV, nie logikę testu.

Warto pilnować, żeby w scenariuszu nie było „twardych” wartości produkcyjnych (URL, hasła, klucze). W repozytorium powinno dać się opublikować testy bez ryzyka wycieku sekretów.

Korelacja odpowiedzi i unikanie kruchych regexów

Przy bardziej złożonych aplikacjach pojawia się korelacja – ID sesji, tokeny CSRF, generowane identyfikatory. Klasyczne pułapki:

• Regex Extractor na chybił trafił – pasuje do starej wersji HTML, po drobnej zmianie layoutu łapie śmieci. Lepiej, jeśli to możliwe, użyć JSON Extractor lub XPath2 Extractor z jasnym kontekstem.
• Brak walidacji korelacji – warto dodać Debug Sampler lub View Results Tree i ręcznie sprawdzić kilka losowych requestów, zanim puści się długi test. Godzina load testu na błędnym tokenie to godzina zmarnowanego czasu.

Przy API REST dobrym nawykiem jest wymuszenie JSON-a wszędzie, gdzie się da. HTML i losowe atrybuty w atrybutach robią ekstrakcję o rząd wielkości bardziej kruchą.

Dbanie o wydajność samego JMetera

JMeter potrafi zużyć sporo zasobów, szczególnie w trybie GUI. Żeby generator nie stał się wąskim gardłem, warto:

• nie używać GUI do testów właściwych – tylko do projektowania i debugowania; docelowo: jmeter -n -t test.jmx -l results.jtl,
• usuwać z planu drogie Listenery (np. View Results Tree, Graph Results) przed testem load; raport HTML wygenerować po teście z pliku JTL,
• przy większej liczbie VU używać kilku agentów (JMeter Distributed) zamiast jednej, przeładowanej maszyny,
• pisać lekkie skrypty w Groovy zamiast Beanshella, gdy trzeba coś policzyć po stronie JMetera.

Praktyczne wzorce pisania scenariuszy w k6

k6 ma niższy próg wejścia, ale przy byle jakiej strukturze skrypty szybko zamieniają się w miks copy-paste i magii w default(). Kilka zabiegów zdejmuje ten bałagan.

Strukturyzacja kodu zamiast jednego pliku

Nawet przy małych projektach API lepiej rozbić testy na moduły. JavaScript w k6 aż się prosi o prostą strukturę katalogów.

• Podział na domeny – np. auth.js, orders.js, catalog.js exportujące funkcje typu login(), createOrder(). Główny skrypt składa z nich scenariusze.
• Oddzielny plik z konfiguracją – config.js z hostem, timeoutami, podstawowymi nagłówkami. Podmiana środowiska to zmiana jednego importu albo parametru.
• Szablon projektu – jeden template-k6 w organizacji, który każdy serwis kopiuje. Ten sam układ katalogów, te same nazwy metryk, jeden sposób logowania błędów.

Scenariusze VU: od prostego smoke do złożonych ramp-upów

Deklaratywne scenariusze w k6 (sekcja scenarios) ułatwiają utrzymanie różnych typów testów w jednym skrypcie.

export const options = {
  scenarios: {
    smoke: {
      executor: 'constant-vus',
      vus: 5,
      duration: '2m',
      exec: 'smokeTest',
    },
    load: {
      executor: 'ramping-vus',
      startVUs: 10,
      stages: [
        { duration: '5m', target: 50 },
        { duration: '10m', target: 50 },
        { duration: '5m', target: 0 },
      ],
      exec: 'loadTest',
      startTime: '3m',
    },
  },
};

Do każdego typu testu osobna funkcja (smokeTest, loadTest) i osobne KPI. Smoke nie musi raportować tylu metryk co długi test obciążeniowy, dzięki czemu raport pozostaje czytelny.

Customowe metryki i proste SLA w kodzie

k6 pozwala w kodzie zamodelować prosty „kontrakt” wydajnościowy. Nie trzeba czekać na zewnętrzne raporty.

import http from 'k6/http';
import { check, Trend } from 'k6';

export const getOrderTime = new Trend('get_order_time');

export const options = {
  thresholds: {
    http_req_failed: ['rate<0.01'],
    'http_req_duration{scenario:load}': ['p(95)<800'],
    get_order_time: ['p(95)<600'],
  },
};

export function loadTest() {
  const res = http.get(`${__ENV.BASE_URL}/orders/123`);
  getOrderTime.add(res.timings.duration);

  check(res, {
    'status is 200': (r) => r.status === 200,
  });
}

Efekt uboczny: jeśli ktoś „niechcący” wprowadzi zmianę, która doda ciężki JOIN do endpointu, pipeline sam wywali się na progu p(95)<600 bez dodatkowych narzędzi.

Ograniczanie logiki aplikacyjnej w testach

Kuszące bywa wkładanie do skryptów pełnej logiki biznesowej (np. kalkulacji cen, skomplikowanego generowania payloadu). To prosta droga do spowolnienia generatora:

• cięższe przeliczenia warto przerzucić do preprocesu – wygenerować pliki JSON z requestami i w testach tylko je odczytywać,
• jeśli koniecznie trzeba wiele liczyć w locie, lepiej zwiększyć liczbę maszyn generatorów zamiast dusić jedną,
• powtarzalną logikę parametryzacji lepiej zwinąć w funkcje i trzymać w jednym module, zamiast kopiować fragmenty po całym repozytorium.

Budżetowo mądrze jest założyć, że skrypty performance’owe mają być proste, a „inteligencję” trzymać poza nimi – w generowaniu danych i dobrym doborze scenariuszy.

Organizacja testów wydajnościowych w zespole

Nawet najlepszy zestaw narzędzi niewiele daje, jeśli testy wykonuje się ad-hoc, raz na kwartał. Ułożenie prostego procesu kosztuje kilka dni, a zwraca się przy pierwszym większym problemie na produkcji.

Role i minimalne obowiązki

Nie każdy zespół ma dedykowanego „performance engineera”. Da się funkcjonować budżetowo, rozkładając odpowiedzialności:

• Dev odpowiedzialny za moduł – utrzymuje scenariusze dla „swojego” API, reaguje na czerwone progi w CI, robi pierwsze śledztwo przy regresji wydajności.
• Osoba „koordynująca” performance – 20–30% etatu:
  • pilnuje, żeby repo testów nie zamieniło się w śmietnik,
  • ustala minimalne standardy (naming, foldery, sposób odpalania),
  • organizuje co jakiś czas większą kampanię end-to-end.
• Ops / SRE – dostarcza monitoring i dostęp do logów, pomaga przy doborze parametrów środowiska testowego, pilnuje, żeby testy nie zjadły całej puli zasobów w klastrze.

Reużywalne artefakty zamiast jednorazowych kampanii

Najdroższe w testach wydajnościowych jest ich przygotowanie. Szkoda marnować to na jednorazową akcję. Kilka elementów, które warto traktować jak produkty, nie projekty:

• Biblioteka scenariuszy – folder z testami typowymi dla organizacji (logowanie, wyszukiwanie, płatność). Nowy projekt startuje od ich skopiowania, nie od białej kartki.
• Szablony pipeline’ów – gotowy YAML dla CI z krokami: smoke, load, generowanie raportu, prosty gating. Każda nowa usługa używa tego samego wzorca.
• Standardowe dashboardy – jeden „template” w Grafanie/Monitoringu, którego kopię dostaje każda aplikacja. Te same metryki, te same alerty, oszczędność czasu przy analizie.

Minimalna dokumentacja, która realnie pomaga

Rozbudowane wiki rzadko wytrzymują próbę czasu. Zamiast tego lepiej trzymać krótkie, aktualne instrukcje w repo z testami:

• README.md w katalogu z testami: jak odpalić lokalnie, jakie scenariusze są dostępne, jak interpretować podstawowe metryki,
• pliki .env.example lub config.example z opisem wymaganych zmiennych środowiskowych,
• prosty CHANGELOG z ważniejszymi zmianami w scenariuszach (np. „dodano walidację p95 dla /checkout”).

Przy rotacji w zespole oszczędza to dni wdrożenia nowej osoby w temat testów wydajnościowych.

Ekonomiczne podejście do środowisk testowych

Środowisko zbliżone do produkcji jest ideałem, ale często nie mieści się w budżecie. Zamiast kopiować całą infrastrukturę 1:1, lepiej szukać sensownych kompromisów.

Proporcjonalne skalowanie zamiast pełnej kopii

Założenie: kluczowe jest podobieństwo architektury i proporcji zasobów, a nie absolutna liczba serwerów. Przykład:

• produkcja: 6 instancji aplikacji, 3 nody bazy, 2 brokery,

• środowisko testowe: 2 instancje aplikacji, 1–2 nody bazy, 1 broker.

Klucz polega na zachowaniu zbliżonych proporcji CPU/RAM oraz limitów (np. liczby połączeń do bazy na instancję), a nie na samej ilości maszyn. Jeśli na produkcji aplikacja dusi się przy 70% CPU, to na testach też powinna się dusić w podobnym punkcie, tylko przy odpowiednio mniejszym ruchu. Ruch z testów po prostu skalujesz liniowo do różnicy w zasobach.

Izolacja testów od reszty świata

Najdroższe są „niewidoczne” koszty – test, który przypadkiem uderza w produkcyjne integracje: system płatniczy, SMS-y, zewnętrzne API. Zanim ktokolwiek zacznie generować ruch, trzeba zadbać o separację:

• stubowane lub sandboxowe integracje zewnętrzne, których limity i opóźnienia są zbliżone do produkcji,
• osobne kolejki / topiki w brokerach, żeby testy nie mieszały się z realnymi komunikatami,
• oddzielne bazy lub przynajmniej osobne schematy z testowymi danymi.

To nie musi być skomplikowane. Często wystarczy drugi zestaw zmiennych środowiskowych i prosty feature flag „PERF_MODE”, który odcina kosztowne integracje i przekierowuje ruch do stubów.

Testy w chmurze vs lokalne generatory

Komercyjne platformy do testów potrafią zjeść budżet w kilka kampanii, ale mają jedną przewagę: łatwo skalować liczbę generatorów z różnych regionów. Dobry kompromis to mieszany model:

• na co dzień: tańsze, lokalne generatory (JMeter/k6 w CI, kilka maszyn w chmurze lub VM-kach),
• kilka razy w roku: duża kampania z użyciem zewnętrznej usługi, gdy trzeba sprawdzić globalny ruch lub hardkorowy peak.

Jeśli budżet jest napięty, lepiej zainwestować w parę prostych VM-ek i sensowne monitorowanie niż w wypasioną platformę SaaS bez ludzi, którzy potrafią zinterpretować wyniki.

Monitoring testów bez dublowania produkcji

Największy zysk daje wspólny stos monitoringu dla testów i produkcji – te same metryki, inne namespace’y. Nie trzeba budować dwóch równoległych światów, wystarczy kilka prostych reguł:

• oddzielne dashboardy, ale oparte na tych samych panelach / metrykach,
• osobne alerty dla środowisk testowych, z niższym priorytetem,
• oznaczanie ruchu z testów (np. nagłówek X-Perf-Test: true), żeby łatwo go odfiltrować w logach i APM.

Efekt: każdy, kto umie czytać metryki produkcyjne, bez dodatkowego szkolenia odnajdzie się w wynikach testów wydajnościowych. To oszczędza czas, szczególnie gdy po nocy dzwoni alert z regresją.

Praktyczne testy wydajnościowe nie wymagają laboratoriów za miliony ani armii specjalistów. Wystarczy kilka rozsądnych nawyków: tani, ale stabilny stack narzędzi, sensowne scenariusze zamiast fajerwerków, lekkie, powtarzalne procesy i środowisko, które nie udaje produkcji, tylko uczciwie ją przybliża. Z takim zestawem da się wcześnie wyłapać większość bolączek, zanim klienci zrobią za zespół najbardziej kosztowny test obciążeniowy – na żywej produkcji.

Najczęściej zadawane pytania (FAQ)

Po co robić testy wydajnościowe aplikacji webowych, skoro „na devie działa szybko”?

Środowisko developerskie zwykle ma mało danych, jednego użytkownika i praktycznie zero konkurencji o zasoby. W takich warunkach prawie wszystko „działa szybko”. Problemy zaczynają się dopiero przy realnym ruchu: wielu równoległych użytkownikach, większej bazie danych, obciążonym cache’u i sieci.

Testy wydajnościowe pozwalają sprawdzić, jak aplikacja zachowa się w warunkach zbliżonych do produkcji – czy czasy odpowiedzi są stabilne, czy nie pojawiają się błędy 5xx i time‑outy oraz ile mocy serwerów faktycznie potrzebujesz. Dzięki temu unikasz gaszenia pożarów po wdrożeniu i nie przepłacasz za infrastrukturę „na wszelki wypadek”.

Kiedy testy wydajnościowe są naprawdę konieczne, a kiedy można je odpuścić?

Absolutnym „must have” są przy: premierze nowego produktu B2C, dużej kampanii marketingowej, integracji z dużym klientem (masowe zapytania do API), migracjach do chmury lub zmianach architektury (np. monolit → mikroserwisy) oraz gdy rosną koszty chmury bez jasnego powodu. W tych momentach brak testów to realne ryzyko utraty przychodu lub klienta.

W małych projektach wewnętrznych można zacząć skromniej: 2–3 scenariusze testów obciążeniowych i krótki test spike, uruchamiane od czasu do czasu lub przed większym releasem. To tani kompromis – minimalny wysiłek, a często wychodzą na wierzch poważne błędy w zapytaniach do bazy, indeksach czy konfiguracji serwera HTTP.

JMeter czy k6 – które narzędzie lepiej wybrać do testów wydajnościowych?

JMeter dobrze sprawdza się, gdy potrzebujesz rozbudowanego, „klikającego” narzędzia z interfejsem graficznym, wieloma wtyczkami i gotowymi komponentami. Sporo zespołów QA już go zna, więc próg wejścia bywa niski, szczególnie przy prostszych scenariuszach. Minusem bywa cięższa konfiguracja i gorsza integracja z nowoczesnym CI/CD, jeśli nie podejdziesz do tego świadomie.

k6 jest lżejszy, nastawiony na automatyzację i integrację z pipeline’ami. Scenariusze pisze się w JavaScripcie, co ułatwia współpracę z developerami i wersjonowanie w Git. Do szybkich, powtarzalnych testów w CI i prostych wdrożeń w chmurze k6 zwykle daje lepszy stosunek „efekt vs wysiłek”. Jeśli zespół QA siedzi głównie w narzędziach GUI – JMeter może być prostszym startem, jeśli zespół jest techniczny i mocno DevOps – k6 zazwyczaj wygrywa.

Jakie są podstawowe rodzaje testów wydajnościowych i kiedy których używać?

Najczęściej stosuje się pięć typów testów, a każdy odpowiada na inne pytanie biznesowe:

• Load – „czy wytrzymamy typowy / spodziewany ruch?”; sprawdza działanie przy normalnym lub lekko podniesionym obciążeniu.
• Stress – „gdzie jest punkt załamania i jak system się zachowuje po kryzysie?”; obciążenie rośnie ponad maksimum.
• Spike – „co jeśli ruch nagle skoczy x‑krotnie?”; krótkie, gwałtowne skoki obciążenia.
• Endurance (soak) – „czy system da radę przez wiele godzin bez restartu?”; długotrwałe, umiarkowane obciążenie.
• Capacity – „ile użytkowników i RPS realnie obsłużymy na tej infrastrukturze?”; powolne zwiększanie obciążenia do granicy akceptowalnej jakości.

Dla oszczędnego podejścia sensowny zestaw na start to: 1–2 kluczowe scenariusze load, jeden prosty spike i raz na jakiś czas test capacity. Dopiero gdy aplikacja rośnie albo pojawiają się konkretne problemy, dokładanie stress i endurance ma uzasadnienie biznesowe.

Jakie metryki są najważniejsze w testach wydajnościowych aplikacji webowych?

Podstawą są czasy odpowiedzi i stabilność działania. Najczęściej patrzy się na:

• p95 / p99 czasu odpowiedzi – ile czasu zajmuje odpowiedź dla 95% i 99% zapytań; średnia bywa myląca.
• RPS (requests per second) lub liczba równoległych użytkowników – czy system „przerabia” tyle ruchu, ile zakłada biznes.
• Odsetek błędów – szczególnie 5xx i time‑outy pod obciążeniem.

Druga grupa to metryki infrastruktury: CPU, pamięć, I/O, pule połączeń do bazy, kolejki w message brokerach. Bez monitoringu po stronie serwerów trudno zrozumieć, dlaczego czasy odpowiedzi rosną – wtedy testy stają się drogą zabawką, a nie narzędziem do realnej optymalizacji kosztów i konfiguracji.

Czy trzeba od razu stawiać rozproszoną infrastrukturę do testów, żeby miało to sens?

Nie. Na początek w wielu projektach wystarczy pojedyncza maszyna (nawet mocniejszy laptop lub niewielki serwer w chmurze), która wygeneruje obciążenie zbliżone do spodziewanego ruchu. To szybki i tani sposób, żeby złapać oczywiste problemy: wolne endpointy, brak indeksów, zbyt małe pule połączeń.

Rozproszoną infrastrukturę generatorów ruchu (kilka agentów JMetera, k6 w chmurze itp.) opłaca się budować dopiero wtedy, gdy:

• realny ruch jest wysoki i pojedyncza maszyna nie jest w stanie go zasymulować,
• potrzebujesz testować wiele usług lub regionów naraz,
• masz już uporządkowane podstawy, a kolejnym krokiem jest precyzyjne skalowanie i optymalizacja kosztów chmury.

Wcześniej to zwykle przerost formy nad treścią.

Jak w praktyce włączyć testy wydajnościowe do CI/CD bez dużych kosztów?

Najprostszy schemat to krótki test k6 lub JMetera uruchamiany na etapie pipeline’u po deployu na środowisko testowe. Scenariusze powinny obejmować 2–3 krytyczne endpointy (logowanie, koszyk, płatność, kluczowe API) i trwać 1–2 minuty, tak aby nie blokować buildów. W pipeline porównujesz p95 czasu odpowiedzi z ustalonym progiem i przerywasz wdrożenie przy pogorszeniu.

Dzięki temu masz „tanią barierę” przed regresją performance – bez dedykowanej infrastruktury i osobnego zespołu. Głębsze, dłuższe testy obciążeniowe można zostawić na nocne joby lub okresowe kampanie, kiedy faktycznie ma to uzasadnienie biznesowe.