Performance Testing

Proč performance testing¶

Vaše aplikace funguje perfektně s 10 uživateli. Co se stane s 10 000? Co s 50 000 během Black Friday? Co když marketingový tým spustí kampaň a traffic se zdesetinásobí za hodinu?

Performance problémy jsou zákeřné. Neprojeví se v development prostředí. Neprojeví se v code review. Neprojeví se v unit testech. Projeví se v produkci, pod reálnou zátěží, kdy je pozdě cokoliv opravovat.

Každá sekunda navíc stojí peníze. Amazon zjistil, že 100ms přidané latence snižuje sales o 1%. Google ukázal, že stránka načítající se 3 sekundy ztrácí 53% mobilních návštěvníků. Netflix investuje do performance testování miliony — protože alternativa je ztráta zákazníků.

Performance testing není luxus. Je to pojistka proti nejdražšímu typu incidentu — pomalé nebo nedostupné aplikaci.

Typy performance testů¶

Každý typ testu odpovídá na jinou otázku. Kompletní performance strategie kombinuje všechny.

Load testing¶

Otázka: Zvládne systém očekávaný provoz?

Load test simuluje reálnou zátěž — typický počet uživatelů, typické operace, typické datové objemy. Měříme response time, throughput, error rate, resource utilization.

Příklad: E-commerce platforma očekává 5 000 concurrent users v denní špičce. Load test simuluje 5 000 virtual users provádějících mix operací: 60% browse, 25% search, 10% add to cart, 5% checkout. Běží 30 minut. Response time p95 pod 500ms? ✅ Nad 2s? 🔴 Hledáme bottleneck.

Stress testing¶

Otázka: Kde je limit a co se stane, když ho překročíme?

Stress test postupně zvyšuje zátěž nad očekávanou úroveň. 100% → 150% → 200% → 300% normálního provozu. Hledáme bod zlomu — kde systém začne degradovat? Kde spadne? A hlavně: jak se zotaví?

Graceful degradation je klíčová. Systém pod extrémní zátěží by měl zpomalit, ne spadnout. Rate limiting, queue backpressure, circuit breakers — stress test ověří, že tyto mechanismy fungují.

Spike testing¶

Otázka: Zvládne systém náhlý nárůst provozu?

Simulujeme prudký spike — z 500 na 5 000 uživatelů za 30 sekund. Typické pro: push notifikace (všichni otevřou app najednou), virální obsah, flash sales, sportovní výsledky. Auto-scaling reaguje dostatečně rychle? Connection pool se nevyčerpá? Cache se neinvaliduje?

Soak testing (endurance)¶

Otázka: Vydrží systém konstantní zátěž dlouhodobě?

Běží hodiny nebo dny s normální zátěží. Odhaluje memory leaky, connection pool exhaustion, disk space issues, log rotation problémy, garbage collection degradaci. Problémy, které se neprojeví za 5 minut, ale za 5 hodin ano.

Breakpoint testing¶

Otázka: Jaká je maximální kapacita systému?

Automaticky inkrementujeme zátěž, dokud nesplníme SLA — response time překročí limit, error rate překročí threshold. Výsledek: přesné číslo maximální kapacity. „Systém zvládne 8 200 concurrent users při p95 < 500ms.” Kapacitní plánování na základě dat, ne odhadů.

k6 — náš primární nástroj¶

k6 od Grafana Labs kombinuje snadné psaní testů v JavaScriptu s výkonem Go runtime. Ideální pro moderní API-first architektury a CI/CD integraci.

Proč k6¶

JavaScript/TypeScript: Testy píšete v jazyce, který váš tým zná. Žádný DSL, žádný nový jazyk. Import modulů, TypeScript typy, IDE podpora.

Výkon: Go runtime zvládne tisíce virtual users na jednom stroji. 10 000 concurrent connections bez problémů. Pro vyšší zátěž distribuovaný mód přes k6-operator na Kubernetes.

CI/CD native: CLI tool, exit codes na základě thresholds. k6 run --threshold 'http_req_duration{p(95)<500}' — test selže, když p95 překročí 500ms. Integruje se do GitHub Actions, GitLab CI, jakéhokoliv CI systému.

Grafana integrace: Výsledky přímo do Grafana dashboardu. Real-time vizualizace během testu. Historické porovnání — byl tento build rychlejší nebo pomalejší?

Příklad k6 testu¶

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

export const options = {
  stages: [
    { duration: '2m', target: 100 },   // ramp up
    { duration: '5m', target: 100 },   // steady state
    { duration: '2m', target: 0 },     // ramp down
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'],
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  const res = http.get('https://api.example.com/products');
  check(res, {
    'status 200': (r) => r.status === 200,
    'response < 500ms': (r) => r.timings.duration < 500,
  });
  sleep(1);
}

Srozumitelné, verzovatelné, spustitelné v CI. Žádné GUI, žádný vendor lock-in.

Gatling pro enterprise scénáře¶

Gatling exceluje v komplexních scénářích s session handling, korelací a datově řízených testech. Scala/Java/Kotlin DSL, silný v enterprise Java ekosystému.

Kdy Gatling: Komplexní workflow s autentizací, CSRF tokeny, session-based state. Enterprise systémy s Java backendem, kde tým preferuje JVM ekosystém. Scénáře vyžadující sofistikovanou korelaci a parametrizaci.

Kdy k6: API testing, microservices, JavaScript/TypeScript tým, CI/CD integrace, rychlý start. Většina moderních projektů.

Performance budgets¶

Performance budget je limit, který nesmíte překročit. Jako finanční rozpočet — ale pro rychlost.

Definice budgetů¶

Response time budgets: - API endpoint: p95 < 200ms, p99 < 500ms - Page load (LCP): < 2.5s - Time to Interactive: < 3.5s - First Contentful Paint: < 1.5s

Resource budgets: - JavaScript bundle: < 200KB gzipped - Total page weight: < 1MB - Number of requests: < 50 - Web font size: < 100KB

Infrastructure budgets: - CPU per pod: < 70% sustained - Memory per pod: < 80% - Database query time: < 50ms p95 - Cache hit rate: > 90%

Enforcement¶

Performance budgets bez enforcement jsou jen přání. Vynucujeme je:

• CI/CD gates: k6 thresholds, Lighthouse CI, webpack bundle analyzer — překročení budgetu = failed build
• Monitoring alerts: Prometheus alerty při překročení production budgetů
• Review process: Performance impact assessment pro architekturální změny

Bottleneck analýza¶

Performance test odhalí symptom (pomalý response). Bottleneck analýza najde příčinu.

Běžné bottlenecky¶

Databáze: N+1 queries, missing indexy, full table scany, lock contention, connection pool exhaustion. Řešíme: query optimization, indexing, connection pooling, read replicas, caching.

Paměť: Memory leaky, GC pressure, oversized caches, unbounded buffers. Řešíme: profiling, heap dumps, memory-efficient datové struktury.

Síť: DNS resolution, TLS handshake, chatty microservices, large payloads. Řešíme: connection pooling, gRPC, payload compression, CDN.

Concurrency: Thread pool exhaustion, async bottlenecks, lock contention, event loop blocking. Řešíme: async/await, non-blocking I/O, lock-free struktury.

Jak spolupracujeme¶

1. Baseline — změříme současný výkon, identifikujeme kritické flow
2. Testovací scénáře — navrhneme load profiles na základě produkčních dat
3. Execution — spustíme battery of tests (load, stress, spike, soak)
4. Analýza — identifikujeme bottlenecky, navrhneme optimalizace
5. Optimalizace — implementujeme fixes, re-testujeme, porovnáme
6. CI/CD integrace — performance testy jako součást pipeline, budgets jako gates
7. Kapacitní plán — kolik uživatelů zvládnete, kdy potřebujete škálovat

Stack¶

Load testing: k6, Gatling, Artillery, Locust, JMeter (legacy).

Frontend performance: Lighthouse, WebPageTest, Core Web Vitals.

Profiling: async-profiler (Java), py-spy (Python), pprof (Go), Chrome DevTools.

Monitoring: Prometheus + Grafana pro real-time vizualizaci během testů.

CI/CD: GitHub Actions, GitLab CI — performance gates v pipeline.

Souvisí s