Testy obciążenia, stresu i benchmarków

Testowanie wydajności mierzy, jak system zachowuje się pod obciążeniem: k6 i Artillery symulują realistyczny ruch, zwiększają liczbę wirtualnych użytkowników do punktu załamania i oblewają przebieg na jawnych progach. AI generuje skrypty, czyta podsumowanie razem z logiem wolnych zapytań, by uszeregować wąskie gardła, i wpina bramkę regresji w CI.

Twoje API obsługuje 500 zapytań na sekundę na stagingu i wszyscy świętują. Potem przychodzi Black Friday, ruch skacze do 3000 rps, a pula połączeń z bazą danych wyczerpuje się w ciągu minut. Latencja p95 skacze ze 120 ms do 4 s, wykres czasu odpowiedzi wygląda jak kij hokejowy 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 prowadzi tę pętlę z pomocą AI: wygeneruj realistyczny skrypt, uruchom go, daj modelowi przeczytać wynik i log wolnych zapytań, a potem wepnij 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 daje ten przepływ pracy testowania wydajności

• Oficjalny serwer MCP k6 (grafana/mcp-k6) wpięty we wszystkie trzy narzędzia, plus k6 x agent init do bootstrapu jedną komendą
• Gotowe prompty generujące uruchamialne skrypty k6: narastanie typu flash sale, test stresu per endpoint znajdujący punkt załamania oraz smoke test poniżej 60 sekund
• Dwa prompty analityczne — jeden czyta tabelę krzywej obciążenia, drugi podsumowanie k6 wraz z logiem wolnych zapytań Postgresa — i produkuje 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
• Benchmarki bazy danych porównujące zapytanie z indeksem i bez niego, przy produkcyjnej liczbie wierszy
• Dwie bramki CI wyłapujące różne regresje: progi bezwzględne przez kody wyjścia k6 run oraz porównanie z bazą odniesienia oblewające PR przy zjeździe p95 o 20%
• 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

Notatka

Zainstaluj k6 jako samodzielne binarium z grafana.com/k6 lub menedżera pakietów (brew install k6, choco install k6) — to binarium w Go, które uruchamia skrypty testowe w zwykłym JavaScripcie, a nie zależność npm. Pakiet k6 na npm to niepowiązany placeholder 0.0.0, więc npm install k6 nie da ci niczego użytecznego. Pliki .k6.js poniżej to po prostu skrypty, które podajesz poleceniu k6 run.

Na wierzchu 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 k6 skills + MCP config for one editor...
k6 x agent init claude-code   # or cursor, codex

# ...or wire up every supported editor at once
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

# No local binary? Run it through Docker instead:
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.

Pętla: wygeneruj, uruchom, przeanalizuj, zabramkuj

Pętla jest taka sama w każdym narzędziu. 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ć kroki 1 i 2 w każdym narzędziu:

Cursor

Otwórz panel agenta (Cmd+I), wklej prompt generujący 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 --sandbox workspace-write -c approval_policy=on-request \
"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 zaufanego przebiegu unattended w CI użyj codex exec --sandbox workspace-write -c approval_policy=never i jawnie przyznaj dostęp sieciowy do stagingu w izolowanej konfiguracji CI. never wyłącza monity, ale nie rozszerza sandboxa; używaj poświadczeń staging o minimalnych uprawnieniach i nigdy nie kieruj tego zadania na produkcję.

Generowanie testu obciążenia

Po prompt na pojedynczy endpoint sięgasz jako pierwszy: daje skrypt, który przeczytasz w minutę i któremu zaufasz, bo każda liczba w nim jest liczbą, którą sam podałeś.

Gotowy prompt: uruchamialny test k6 dla jednego 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.

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 poniżej jest banalnie prosta.

Jeden endpoint to początek; prawdziwy przepływ to kilka, a kształt ruchu ma znaczenie nie mniejsze niż jego wolumen. Te trzy prompty skalują ten sam przepis w górę — wieloetapowa podróż użytkownika ze skokiem, cały zestaw z helperami i skryptami npm oraz przebieg po całym repozytorium, który sam wybiera endpointy.

Cursor

Generate a k6 load test for our checkout API:

Scenario: Simulate a flash sale with ramping traffic
- Ramp from 0 to 100 virtual users over 2 minutes
- Hold at 100 VUs for 5 minutes (steady state)
- Spike to 500 VUs for 1 minute (flash sale moment)
- Return to 100 VUs for 2 minutes (recovery)
- Ramp down to 0 over 1 minute

API calls per virtual user iteration:
1. POST /api/auth/login (use test credentials from env)
2. GET /api/products?category=sale (browse sale items)
3. POST /api/cart/items (add random product)
4. POST /api/checkout (complete purchase with test payment)

Thresholds:
- p95 response time < 500ms during steady state
- p99 response time < 2000ms during spike
- Error rate < 1% at all times
- Checkout success rate > 99%

Save to /tests/performance/checkout-load.k6.js

Claude Code

claude "Create a comprehensive k6 performance test suite:

1. /tests/performance/checkout-load.k6.js - Checkout flow load test
   - Ramping traffic pattern: 0 -> 100 -> 500 -> 100 -> 0 VUs
   - Realistic user journey (login, browse, cart, checkout)
   - SLA thresholds for response time and error rate

2. /tests/performance/api-stress.k6.js - API endpoint stress test
   - Test each critical endpoint individually
   - Find the breaking point (ramp until errors > 5%)
   - Report max throughput per endpoint

3. /tests/performance/helpers/auth.js - Shared auth helper
   - Login and cache tokens
   - Token refresh handling

4. package.json scripts:
   - test:perf:load - Run load tests
   - test:perf:stress - Run stress tests
   - test:perf:smoke - Quick 30-second smoke test

Include realistic test data generation for each scenario."

Codex

Create a performance testing suite for this project:
1. Analyze the API routes to identify critical endpoints
2. Generate k6 load tests for the top 5 most important flows
3. Create stress tests that find breaking points
4. Add performance smoke tests for CI integration
5. Create a PR with the test suite and documentation

Include realistic traffic patterns based on typical SaaS usage.

Testy stresu: znajdowanie punktu załamania

Test obciążenia pyta „czy wytrzyma przy ruchu, jakiego się spodziewamy?”. Test stresu pyta „przy jakiej liczbie przestaje wytrzymywać?” — a odpowiedź trafia do dokumentu planowania pojemności. Zdefiniuj punkt załamania przed przebiegiem, żeby test raportował liczbę, a nie wrażenie.

Gotowy prompt: test stresu znajdujący punkt załamania

Generate a k6 stress test that finds our API's breaking point:

Strategy: Ramp virtual users linearly from 10 to 1000 over 15 minutes.
For each VU, execute this loop:
1. GET /api/products (list endpoint)
2. GET /api/products/{randomId} (detail endpoint)
3. POST /api/orders (write endpoint with validation)

Track these metrics at each load level:
- Requests per second achieved
- p50, p95, p99 response times
- Error rate (HTTP 5xx responses)
- TCP connection errors
- Iterations completed vs. failed

Define the breaking point as when EITHER:
- p95 response time exceeds 5 seconds, OR
- Error rate exceeds 5%, OR
- Iterations start failing

Output the results in a format I can paste into a Markdown table for our capacity planning doc.
Include checks that fail the test if we cannot handle at least 200 concurrent users.

Analiza wyników

Czerwony próg mówi, że coś jest wolne. Nie mówi, która warstwa się nasyciła, a to właśnie pytanie warto oddać modelowi. Dwa prompty, zależnie od tego, jakim materiałem dysponujesz.

Gdy masz tylko krzywą obciążenia, samym dowodem jest kształt degradacji — czyste liniowe narastanie wskazuje na coś zupełnie innego niż urwisko:

Gotowy prompt: odczytaj wąskie gardło z krzywej obciążenia

Analyze these k6 load test results and identify bottlenecks:

Endpoint: POST /api/checkout
- At 50 VUs: p95=120ms, p99=250ms, error_rate=0%
- At 100 VUs: p95=180ms, p99=450ms, error_rate=0%
- At 200 VUs: p95=850ms, p99=2100ms, error_rate=0.5%
- At 300 VUs: p95=3200ms, p99=8500ms, error_rate=12%
- At 400 VUs: p95=timeout, error_rate=45%

Our stack: Node.js Express, PostgreSQL (connection pool max: 20),
Redis for sessions, Stripe API for payments.

Based on these results:
1. What is the likely bottleneck? (connection pool, CPU, external API, memory)
2. Why does performance degrade non-linearly between 200 and 300 VUs?
3. What specific code or infrastructure changes would increase capacity?
4. What is our realistic production capacity with current architecture?
5. Suggest a monitoring dashboard that would show this bottleneck in real-time

Gdy możesz dołożyć log wolnych zapytań bazy z tego samego okna, diagnoza przestaje być wnioskowaniem. Ten drugi prompt wymaga dowodu przy każdym twierdzeniu i kończy się jedną priorytetową zmianą, a nie listą możliwości:

Gotowy prompt: uszereguj wąskie gardła z podsumowania i logu wolnych zapytań

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.

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

Core Web Vitals pod równoległym obciążeniem

Serwerowe p95 może być zdrowe, a strona i tak sprawiać wrażenie zepsutej, bo przeglądarka wykonuje pracę, której API nigdy nie widzi. Mierz front end, gdy API jest pod obciążeniem, a nie na bezczynnej maszynie.

Gotowy prompt: zmierz LCP, INP i CLS pod obciążeniem

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.

Benchmarki wydajności bazy danych

Większość urwisk w testach obciążenia okazuje się zapytaniem, które było w porządku przy skali danych zaseedowanych. Benchmarkuj zapytania bezpośrednio, przy produkcyjnej liczbie wierszy, z indeksem, o który się spierasz, i bez niego.

Gotowy prompt: zbenchmarkuj krytyczne zapytania

Generate database performance benchmarks for our critical queries:

1. User search (full-text search on name + email):
   - Benchmark with 100K, 500K, 1M, and 5M rows
   - Test with and without the GIN index
   - Measure query time and rows scanned

2. Order listing with joins (orders + items + products):
   - Benchmark the paginated query (page 1 vs. page 100 vs. page 1000)
   - Test with 1M orders and 5M order items
   - Measure with and without covering indexes

3. Dashboard aggregation (total revenue by day for last 90 days):
   - Benchmark with 1M and 10M orders
   - Test with raw query vs. materialized view
   - Measure time and memory usage

Create a seed script that generates the test data using faker.
Save to /tests/performance/database-benchmarks.ts
Output results as a comparison table.

Bramkowanie regresji w CI

Dwie bramki wyłapują dwie różne awarie i chcesz mieć obie. Pierwsza jest bezwzględna: thresholds w samym skrypcie definiują „za wolno”, a 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 }}

Druga bramka jest względna i wyłapuje to, czego pierwsza nie potrafi: zmiana, która podwaja p95 z 90 ms do 180 ms, przechodzi próg p(95)<300, po cichu zjadając połowę twojego zapasu. Do tego potrzebujesz zapisanej bazy odniesienia i porównania procentowego.

Gotowy prompt: zbuduj bramkę porównującą z bazą odniesienia

Create a performance regression detection pipeline:

1. A smoke-level k6 test that runs in under 60 seconds:
   - 10 VUs for 30 seconds
   - Test the 3 most critical endpoints
   - Strict thresholds: p95 < 200ms, error rate = 0%

2. A GitHub Actions workflow step that:
   - Runs the smoke test on every PR
   - Compares results against the baseline from main branch
   - Fails the PR if p95 regressed by more than 20%
   - Posts a comment with performance comparison table

3. A baseline update mechanism:
   - After merging to main, save the performance results as the new baseline
   - Store in a JSON file committed to the repo

Save the test to /tests/performance/smoke.k6.js
Save the workflow addition to a snippet I can add to .github/workflows/ci.yml

Uruchomienia testów obciążenia i stresu są długie i głodne CPU, więc to, gdzie je uruchamiasz, ma znaczenie nie mniejsze niż sam skrypt. Każde narzędzie ma naturalne miejsce dla zadań k6:

Cursor

Pisz i debuguj skrypty k6 lokalnie w trybie Agent na URL stagingowym, a potem zacommituj plik workflow. Cursor to miejsce, gdzie iterujesz nad progami i scenariuszami; nie chcesz, by długie uruchomienia testów stresu blokowały edytor, więc trzymaj uruchomienia w edytorze na poziomie 30-sekundowego smoke testu.

Claude Code

Uruchamiaj benchmark smoke w trybie headless jako bramkę PR: claude -p "run k6 run tests/performance/smoke.k6.js, compare p95 against perf-baseline.json, and fail if it regressed more than 20%" wewnątrz zadania GitHub Actions. Połącz to z hookiem PostToolUse, by komentarz z porównaniem był publikowany automatycznie.

Codex

Przerzuć długie uruchomienia testów obciążenia i stresu na Codex Cloud lub zaplanowaną automatyzację, by wykonywały się na sprzęcie w chmurze, a nie na runnerze PR — a następnie niech otworzy PR (lub komentarz) z tabelą wyników. Dzięki temu wielominutowe uruchomienia nie obciążają krytycznej ścieżki CI, a merge nadal jest bramkowany wynikiem z chmury.

Praktyczny podział jest warstwowy: 30-sekundowy smoke test na każdym PR, pełny test obciążenia w nocy, test stresu co tydzień. Smoke test łapie oczywiste regresje; dłuższe przebiegi łapią subtelne, nie wstrzymując merge’a.

Kiedy liczby z testów obciążenia kłamią

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 albo niewłaściwe wszystko. Zapytanie, które jest natychmiastowe na 10 tys. zaseedowanych wierszy, robi skan sekwencyjny po 10 mln wierszy produkcyjnych, a lokalna baza nie ma ani opóźnienia sieciowego produkcji, ani jej limitów połączeń. Nigdy nie testuj obciążenia na lokalnym stacku: uruchamiaj testy na środowisku stagingowym odzwierciedlającym infrastrukturę produkcyjną albo na oczyszczonej replice w rozmiarze produkcyjnym.

Uwaga

Wyniki skaczą między identycznymi przebiegami. Testy wydajności są z natury szumne. Uruchom każdy scenariusz trzy razy i weź medianę, ustal akceptowalne pasmo wariancji (plus minus 15%) i oblewaj na przekroczeniu progu przez medianę, a nie przez pojedynczy przebieg.

Uwaga

Wygenerowany wzorzec ruchu to nie twój ruch. Model poproszony o „test obciążenia” wymyśla wiarygodny rozkład, a wiarygodny to nie twój. Podaj mu prawdziwy kształt z analityki: „traffic peaks at 2pm EST, 60% of requests are GET /api/products, the average session makes 12 API calls over 8 minutes”.

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.

Dokąd dalej z testowaniem wydajności

Monitoring i obserwowalność Skonfiguruj monitoring produkcyjny, by zweryfikować przewidywania testów wydajności.

Testowanie API Funkcjonalne testowanie API uzupełniające testowanie wydajności.

Pipeline'y CI/CD Zintegruj bramki wydajności z pipeline'em wdrożeniowym.

Architektura mikroserwisów Śledzenie wąskiego gardła przez granice usług.

Zarządzanie dużymi bazami kodu Rozważania wydajnościowe w skali korporacyjnej.

Infrastructure as Code Prowizjonowanie reprezentatywnych środowisk testowania obciążenia.