Zátěžové testování: kontrolní seznam a selhání

Systematický přístup k zátěžovému testování: od selhání s tokeny ke stabilním metrikám

Backend jako proxy mezi frontendem a externí službou ukládal přístupový token do mezipaměti přes opcache. Při zátěži několik paralelních požadavků současně zjistilo, že token vypršel, a pokusilo se jej obnovit. Starý token přepsal čerstvý v mezipaměti, což vedlo k chybám 403.

Řešení: přidali jsme zámek pro obnovení tokenu a přesunuli mezipaměť do clusterového memcached pro jednotný stav mezi procesy. Ověření v Postmanu s paralelními požadavky potvrdilo odstranění závodů.

Metriky před: doba odezvy rostla exponenciálně, úspěšnost klesla pod 90 % při 300 RPS. Po: úspěšnost 100 %, 5xx <0,05 %, průměrná doba 99–104 ms při 226 RPS.

Příprava backendu: kontrolní seznam optimalizací

Před zátěžovým testováním (ZT) backendový vývojář prochází systematický kontrolní seznam. Tím minimalizuje úzká místa na úrovni kódu a infrastruktury.

Optimalizace databáze

• Indexace všech polí v WHERE a JOIN.
• Analýza EXPLAIN pro pomalé dotazy.
• Replikace master-slave, connection pooling (pgbouncer nebo ekvivalent).

Ukládání do mezipaměti

• Memcached pro opakující se data.
• Mezipaměť HTTP odpovědí ve Varnish nebo nginx.
• Mezipaměť Twig šablon.

Asynchronnost

• Fronty RabbitMQ nebo Redis pro úlohy na pozadí.
• Přesun emailů, generování PDF do background jobs.

PHP kód

• Odstranění N+1 dotazů.
• Optimalizace cyklů, vyhýbání se hluboké rekurzi.
• Uvolnění paměti unset() pro velké objekty.

Infrastruktura

• php-fpm: pm.max_children > 100, pm.max_requests = 500.
• MinIO pro úložiště souborů.
• HPA v Kubernetes podle CPU/RAM.
• Rate limiter (nginx nebo Traefik) pro omezení rychlosti.

Frontend: snížení příchozí zátěže

Frontend generuje hlavní provoz. Optimalizace zde snižují RPS na backendu o 30–50 %.

• Statické assety: nginx cache pro JS/CSS/obrázky.
• Klientská mezipaměť API: localStorage nebo memcached pro zřídka se měnící data (katalogy, konfigurace).
• Stránkování: limit/offset, nekonečný scroll bez plného načtení.
• SSG/ISR: Next.js pro statické vykreslování stránek.
• SSE/Webhooks: nahrazení polling push notifikacemi.

Postup zátěžového testování

ZT je povinné pro funkce měnící serverovou logiku, mezipaměť nebo DB. Provádí se na předprodukčním/produkčním prostředí v noci při minimální uživatelské zátěži.

• Plánování (týden předem): vedoucí + PM + DevOps odhadují cílové RPS (N požadavků/s).
• Role DevOps: nastavení podů (CPU/RAM), HPA, monitoring v reálném čase.
• Spuštění: k6 nebo ekvivalent, scénáře podle API endpointů.
• Monitoring: Grafana (RPS, latence, chybovost), Graylog pro logy.
• Analýza: do bodu degradace, oprava úzkého místa, opakování.

Úspěch: úspěšnost >99 %, latence <150 ms při cílovém RPS +20 % rezerva.

Co je důležité

• Závody procesů (tokeny, session) se projeví pouze při paralelní zátěži.
• Clusterová mezipaměť (memcached) místo lokálního opcache zabraňuje race conditions.
• ZT na prod-like prostředí: replikace DB, externí služby.
• DevOps v cyklu: dynamické úpravy zdrojů během testu.
• Frontendové optimalizace snižují zátěž efektivněji než backendové opravy.

Metriky úspěchu a benchmarky

Příklad z Grafana po opravách:

| Metrika | Průměr | Špička | Cíl |

|---------|---------|-----|------|

| Úspěšnost | 100% | 100% | >99% |

| 5xx chyby | 0,017% | 0,042% | <0,1% |

| RPS | 226 | 321 | 300+ |

| Latence (ms) | 99–104 | 123 | <150 |

Stabilizace na 226 RPS bez degradace. Bod selhání: ~450 RPS (rezerva 100 %).

Doporučení pro middle/senior

• Integrujte ZT do CI/CD: automatické testy při merge.
• Monitorujte p99 latenci, nejen průměr.
• Testujte worst-case: 80 % provozu na jeden endpoint.
• Logujte request ID pro trasování (Jaeger/OpenTelemetry).

Tento přístup odhaluje problémy ve fázi vývoje, čímž snižuje incidenty v produkci.

— Editorial Team