Testy obciążenia, stresu i benchmarków

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. Wykres czasu odpowiedzi wygląda jak kij hokejowy, a Twój CEO obserwuje dashboard uptime. Testowanie wydajności nie jest opcjonalne dla systemów produkcyjnych — a AI sprawia, że budowanie kompleksowych zestawów testów wydajnościowych jest dramatycznie łatwiejsze.

Czego się nauczysz

• Generowanie testów obciążenia k6 i Artillery z promptów AI
• Wzorce testów stresu znajdujących punkt załamania Twojego systemu w bezpieczny sposób
• Ciągły benchmarking w CI wyłapujący regresje wydajności
• Analizę wąskich gardeł wydajności wspomaganą AI na podstawie wyników testów
• Realistyczną symulację wzorców ruchu dla Twojego konkretnego przypadku użycia

Generowanie testów obciążenia

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

Wskazówka

Prompt do skopiowania — generowanie testu stresu:

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.

Ciągły benchmarking w CI

Automatyczne wykrywanie regresji wydajności

Wskazówka

Prompt do skopiowania — benchmarki wydajności w CI:

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

Analiza wyników wydajności z AI

Po uruchomieniu testów obciążenia narzędzia AI mogą pomóc zinterpretować wyniki.

Wskazówka

Prompt do skopiowania — analiza wydajności:

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

Testowanie wydajności bazy danych

Wskazówka

Prompt do skopiowania — benchmarki wydajności bazy danych:

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.

Gdy coś się zepsuje

“Testy obciążenia przechodzą lokalnie, ale system produkcyjny jest wolniejszy.” Twoje lokalne środowisko nie odpowiada produkcji. Uruchamiaj testy wydajności na środowisku stagingowym odzwierciedlającym infrastrukturę produkcyjną (ten sam rozmiar bazy danych, to samo opóźnienie sieciowe, te same limity połączeń). Nigdy nie używaj lokalnych baz danych do testów obciążenia.

“Testy dają niespójne wyniki między uruchomieniami.” Testy wydajności są z natury szumne. Uruchom każdy scenariusz trzy razy i użyj mediany. Ustal akceptowalne pasma wariancji (plus minus 15%). Failuj tylko gdy mediana przekracza próg, nie poszczególne uruchomienia.

“Nie możemy uruchamiać testów obciążenia w CI, bo trwają zbyt długo.” Użyj podejścia warstwowego: smoke testy (30 sekund) na każdym PR, testy obciążenia (10 minut) w nocy, pełne testy stresu co tydzień. Smoke test łapie oczywiste regresje; dłuższe testy łapią subtelne.

“AI wygenerowało testy obciążenia nieodpowiadające prawdziwym wzorcom ruchu.” Daj AI Twoje faktyczne dane o ruchu. Wyeksportuj próbkę z analityk: “Our traffic peaks at 2pm EST, 60% of requests are GET /api/products, and the average user session makes 12 API calls over 8 minutes.”

Co dalej

Monitoring and Observability Set up production monitoring to validate performance test predictions.

API Testing Functional API testing to complement performance testing.

CI/CD Pipelines Integrate performance gates into your deployment pipeline.