Testowanie obciążenia i analiza wydajności

Twój endpoint kasy działa bez zarzutu na stagingu, a potem wykłada się przy pierwszej akcji marketingowej. Latencja p95 skacze ze 120 ms do 4 s, połączenia do Postgresa się wyczerpują i nikt nie potrafi wskazać zmiany, która to spowodowała. Potrzebujesz testu obciążenia, który odtworzy ten skok, odczytu, która warstwa nasyca się jako pierwsza, oraz bramki regresji w CI, żeby kolejny deploy nie zaskoczył Cię o 21:00.

Ten przewodnik pokazuje, jak prowadzić tę pętlę z pomocą AI: wygenerować realistyczny skrypt k6, uruchomić go, dać modelowi przeczytać wynik i log wolnych zapytań, a następnie wpiąć bramkę progową do pipeline’u. Te same prompty działają w Cursorze, Claude Code i Codeksie — różni się tylko sposób uruchamiania każdego narzędzia.

Co z tego wyniesiesz

• Prompt gotowy do wklejenia, który generuje uruchamialny skrypt k6 z narastającym profilem VU oraz thresholds dla konkretnego endpointu
• Oficjalny serwer MCP k6 (grafana/mcp-k6) wpięty we wszystkie trzy narzędzia, plus k6 x agent init do bootstrapu jedną komendą
• Prompt, który zamienia podsumowanie k6 i log wolnych zapytań Postgresa w uszeregowaną listę wąskich gardeł „najpierw najważniejsze”
• Prompt Playwright + Lighthouse, który mierzy Core Web Vitals (LCP, INP, CLS) pod równoległym obciążeniem
• Bramka regresji w CI, która oblewa build, gdy p95 ulega regresji, korzystając z kodów wyjścia k6 run
• Tryby awarii, które sprawiają, że liczby z testów obciążenia kłamią — i jak je wyłapać, zanim zaufasz dashboardowi

Wpięcie narzędzi

Warto zainstalować oficjalny serwer MCP k6 od Grafany (grafana/mcp-k6). Pozwala on agentowi walidować skrypty, uruchamiać testy i czytać dokumentację k6 bez przeklejania outputu CLI w tę i z powrotem. Dostarczany jest jako binarka Go lub obraz Dockera — nie jako pakiet npm, więc zignoruj wszelkie „k6 MCP” oparte na npx, które znajdziesz; to nieoficjalne nakładki.

Najszybsza droga to k6 x agent init (wymaga k6 v2.0+ na PATH), które wrzuca odpowiednie pliki skilli do Twojego edytora i rejestruje serwer MCP dla narzędzia, którego używasz:

# Bootstrap skilli k6 + konfiguracji MCP dla jednego edytora...
k6 x agent init claude-code   # or cursor, codex

# ...albo wepnij każdy obsługiwany edytor naraz
k6 x agent init --all

Jeśli wolisz wpiąć serwer MCP ręcznie, instalacja jest identyczna we wszystkich narzędziach — różni się tylko komenda rejestracji.

Cursor

Zainstaluj binarkę, a następnie dodaj ją w Settings → MCP → Add, podając mcp-k6 jako komendę (stdio). Albo wrzuć to do .cursor/mcp.json:

{
  "mcpServers": {
    "k6": { "command": "mcp-k6" }
  }
}

Najpierw zainstaluj binarkę: brew tap grafana/grafana && brew install mcp-k6 (lub docker pull grafana/mcp-k6:latest).

Claude Code

brew tap grafana/grafana && brew install mcp-k6
claude mcp add --scope user --transport stdio k6 -- mcp-k6

# Brak lokalnej binarki? Uruchom przez Dockera:
claude mcp add --scope user --transport stdio k6 -- docker run --rm -i grafana/mcp-k6

Codex

Dodaj to do ~/.codex/config.toml:

[mcp_servers.k6]
command = "mcp-k6"
# or run via Docker:
# command = "docker"
# args = ["run", "--rm", "-i", "grafana/mcp-k6"]

Zainstaluj binarkę przez brew install mcp-k6 po brew tap grafana/grafana.

Do wydajności po stronie przeglądarki przyda Ci się też Playwright MCP (@playwright/mcp), którego konfiguracja jest taka sama w każdym narzędziu:

claude mcp add playwright -- npx -y @playwright/mcp@latest

W Cursorze dodaj go przez Settings → MCP; w Codeksie dodaj blok [mcp_servers.playwright] wskazujący na tę samą komendę npx.

Notatka

Serwery MCP k6 i Playwright wystawiają te same narzędzia niezależnie od tego, który asystent je wywołuje — MCP to warstwa przenośna. Wybieraj narzędzie według tego, jak lubisz prowadzić przepływ pracy (panel agenta w Cursorze, terminal Claude Code, wielopowierzchniowe przebiegi Codeksa), a nie według dostępności MCP.

Przepływ pracy

Pętla jest taka sama w każdym narzędziu: wygeneruj skrypt, uruchom go, oddaj wyniki do analizy, a potem wepnij go w bramkę w CI. Zmienia się sposób wywołania.

1. Wygeneruj skrypt na podstawie prawdziwego endpointu, docelowej liczby VU, profilu narastania i jawnych progów — a nie „napisz test obciążenia”.
2. Uruchom go względem stagingu (k6 run script.js), gdzie serwer MCP pozwala agentowi bezpośrednio wykonywać go i czytać output.
3. Przeanalizuj wyniki, przekazując modelowi podsumowanie k6 oraz log wolnych zapytań i prosząc o uszeregowaną listę wąskich gardeł.
4. Wepnij bramkę w CI, żeby regresja p95 oblała build, zanim trafi na produkcję.

Oto jak odpalić krok 1 i 2 w każdym narzędziu. Prompt jest identyczny — wklej do dowolnego z nich prompt generowania testu obciążenia poniżej.

Cursor

Otwórz panel agenta (Cmd+I), wklej prompt i pozwól mu napisać tests/load/checkout.js. Z podłączonym serwerem MCP k6 agent może sam uruchomić k6 run i iterować nad oblanymi progami w trybie inline. Użyj checkpointu przed przebiegiem, żeby móc wycofać skrypt, jeśli wygenerowany profil VU jest nierealistyczny.

Claude Code

claude "Generate a k6 load test at tests/load/checkout.js for POST /api/checkout:
ramp 0->200 VUs over 2m, hold 5m, ramp down 1m. Add thresholds:
http_req_duration p95<300 p99<800, http_req_failed rate<0.01. Then run it
against $STAGING_URL and summarize threshold pass/fail."

Z zarejestrowanym serwerem MCP k6 Claude Code uruchamia test przez serwer i odczytuje podsumowanie bez przeklejania.

Codex

Uruchom go jednorazowo z CLI albo odpal w Codex Cloud, żeby długotrwały test wykonał się poza Twoją maszyną:

codex "Generate a k6 load test at tests/load/checkout.js for POST /api/checkout
(ramp 0->200 VUs over 2m, hold 5m), add p95<300/p99<800 thresholds, run it
against $STAGING_URL, and report which thresholds failed."

Do nienadzorowanych przebiegów w stylu CI dodaj --full-auto, żeby Codex mógł wykonać k6 run bez zatrzymywania się na zatwierdzenie.

Wygenerowany skrypt powinien wyjść mniej więcej tak — konkretne etapy VU i progi, a nie szkielet ścieżki happy path:

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

export const options = {
  stages: [
    { duration: '2m', target: 200 }, // ramp to peak
    { duration: '5m', target: 200 }, // hold
    { duration: '1m', target: 0 },   // ramp down
  ],
  thresholds: {
    http_req_duration: ['p(95)<300', 'p(99)<800'],
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  const res = http.post(`${__ENV.STAGING_URL}/api/checkout`, JSON.stringify({
    cartId: 'c_load_test', paymentMethod: 'pm_test',
  }), { headers: { 'Content-Type': 'application/json' } });

  check(res, { 'status is 200': (r) => r.status === 200 });
  sleep(1); // think time so 200 VUs != 200 RPS
}

k6 run kończy się kodem niezerowym, gdy próg zostaje przekroczony, i to właśnie sprawia, że bramka CI z ostatniego kroku jest banalnie prosta.

Prompty do wklejenia

Wskazówka

Wygeneruj uruchamialny test obciążenia k6 dla konkretnego endpointu:

Write a k6 script at tests/load/checkout.js that load-tests POST /api/checkout on a Node/Express + Postgres backend.

• Ramp 0→200 VUs over 2m, hold at 200 for 5m, ramp down over 1m.
• Send a realistic JSON body (cartId, paymentMethod) and a Bearer ${__ENV.TOKEN} auth header.
• Add thresholds: http_req_duration p(95)<300ms and p(99)<800ms, http_req_failed rate<1%.
• Add a check() for status === 200 and 1s sleep() think time so VUs don’t equal RPS.
• Read the target host from __ENV.STAGING_URL. Then run it with k6 run and tell me which thresholds failed and the actual p95/p99.

Wskazówka

Zamień surowe wyniki w uszeregowaną listę wąskich gardeł „najpierw najważniejsze”:

Here is the k6 summary [paste] and the Postgres slow-query log [paste] from the same run.

1. Rank the top 5 bottlenecks by contribution to p95 latency.
2. For each, say whether it’s app code, a query, connection-pool exhaustion, or an external call, and cite the evidence (the specific query or metric).
3. Give me the single change with the best latency-per-effort ratio, with the exact code or index DDL. Do not suggest schema changes that require downtime.

Wskazówka

Zmierz Core Web Vitals pod równoległym obciążeniem z Playwrightem:

Using the Playwright MCP, write a script that loads /dashboard in 10 parallel browser contexts while a k6 run hits the API at 100 VUs. Capture LCP, INP, and CLS via the web-vitals library injected on each page, throttled to a “Fast 3G” network profile. Report the p75 of each metric across all sessions and flag any LCP > 2.5s, INP > 200ms, or CLS > 0.1. Generate a Lighthouse report for the worst-performing session.

Wepnij bramkę regresji w CI

Ponieważ k6 run zwraca niezerowy kod wyjścia, gdy któryś próg zostanie przekroczony, krok CI sprowadza się do uruchomienia skryptu — bez własnej logiki porównań. Użyj oficjalnej grafana/setup-k6-action, a nie ręcznie sklejonej instalacji przez curl:

.github/workflows/load-test.yml

- uses: actions/checkout@v5
- uses: grafana/setup-k6-action@v1
- run: k6 run tests/load/checkout.js
  env:
    STAGING_URL: ${{ secrets.STAGING_URL }}
    TOKEN: ${{ secrets.LOAD_TEST_TOKEN }}

Żeby pójść dalej, podłącz Sentry MCP, aby agent mógł skorelować przekroczenia progów z błędami i wolnymi transakcjami, które Sentry zarejestrował podczas przebiegu. Zdalny serwer to najprostsza konfiguracja i jest identyczny we wszystkich narzędziach:

# Official Sentry remote MCP (recommended)
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp

# Local stdio alternative, if you need it
claude mcp add sentry -- npx -y @sentry/mcp-server

Potem zapytaj: „Dla okna testu obciążenia 14:00–14:08 UTC wyciągnij najwolniejsze transakcje i wszelkie nowe błędy z Sentry i zestaw je z przekroczeniami progów k6.” To zamienia czerwony przebieg CI w konkretną listę transakcji do naprawy.

Notatka

Unikaj pakietu npm o nazwie dosłownie sentry-mcp — to niepowiązana zaślepka 0.0.1, a nie serwer Sentry. Oficjalne pakiety to zdalny endpoint https://mcp.sentry.dev/mcp oraz pakiet stdio @sentry/mcp-server. To samo dotyczy monitorowania: oficjalny Grafana MCP (grafana/mcp-grafana) dostarczany jest jako obraz Dockera / binarka Go, a nie jako jeden ze społecznościowych pakietów npm *-grafana.

Kiedy to się psuje

Liczby z testów obciążenia kłamią w przewidywalny sposób. Oto tryby awarii, które wysyłają zespoły w pogoń za niewłaściwą naprawą.

Uwaga

VU to nie RPS. 200 wirtualnych użytkowników z czasem myślenia 1 s to mniej więcej 200 RPS tylko wtedy, gdy każde żądanie wraca natychmiast. Gdy latencja rośnie, przepustowość spada — VU piętrzą się w locie, a Twoje rzeczywiste RPS maleje. Jeśli musisz utrzymać stały współczynnik żądań, użyj egzekutora constant-arrival-rate w k6 zamiast narastania VU, bo inaczej Twój test „na 200 VU” po cichu staje się testem na 40 RPS, gdy tylko serwer zwolni.

Uwaga

Generator obciążenia nasyca się jako pierwszy. Pojedyncza maszyna k6 dobija własny CPU albo wyczerpuje porty efemeryczne na długo przed Twoją usługą, a Ty „odkrywasz” wąskie gardło, które tak naprawdę jest po stronie klienta. Obserwuj CPU generatora i sprawdzaj dropped_iterations w podsumowaniu k6 — jeśli jest niezerowe, ograniczeniem jest maszyna testowa, a nie Twoja aplikacja. Rozłóż obciążenie na wiele runnerów albo użyj Grafana Cloud k6 do prawdziwych obciążeń szczytowych.

Uwaga

p95 ukrywa ból; patrz na p99. Średnie, a nawet p95, wyglądają w porządku, podczas gdy użytkownicy z p99 dostają timeouty. p95 na poziomie 0,8 s przy p99 na poziomie 12 s oznacza, że 1 na 100 żądań jest katastrofalne — często te, które trzymają blokadę bazy danych lub nasyconą pulę połączeń. Zawsze ustawiaj i odczytuj progi p99, nie tylko p95.

Uwaga

Staging ma niewłaściwy wolumen danych. Zapytanie, które jest natychmiastowe na 10 tys. zaseedowanych wierszy, robi skan sekwencyjny po 10 mln wierszy produkcyjnych. Jeśli tabele na stagingu nie są reprezentatywne, Twój test obciążenia przepuszcza zapytanie, które na produkcji się stopi. Zaseeduj realistyczne wolumeny albo uruchamiaj test względem oczyszczonej repliki w rozmiarze produkcyjnym.

Gdy wynik wygląda na niemożliwy, przekaż swojemu narzędziu AI pełne podsumowanie k6 i metryki zasobów generatora i poproś, żeby odróżniło prawdziwe wąskie gardło serwera od artefaktu testu, zanim eskalujesz.

Co dalej

• Architektura mikroserwisów — śledzenie wąskiego gardła przez granice usług
• Pipeline’y CI/CD — wpięcie bramki regresji w pełny przepływ deploymentu
• Framework jakości testowania — gdzie testowanie obciążenia mieści się w szerszej strategii testowania
• Zarządzanie dużymi bazami kodu — rozważania wydajnościowe w skali korporacyjnej
• Infrastructure as Code — prowizjonowanie reprezentatywnych środowisk testowania obciążenia