Proč je téma důležité
Výkonové testování často začíná výběrem nástroje a vytvořením velkého množství virtuálních uživatelů. Bez obchodní otázky však není jasné, zda naměřený výsledek znamená úspěch nebo problém.
Výkon zahrnuje odezvu, propustnost, stabilitu, využití zdrojů a schopnost zotavit se. Test musí napodobit očekávaný způsob používání, nikoli pouze generovat co nejvyšší zátěž.
Jak postupovat správně
Definujte cíle a prahy
Uveďte očekávaný počet uživatelů nebo dávek, přijatelnou odezvu, chybovost a obchodní dopad zpomalení.
Vytvořte realistický workload model
Poměr operací, velikost dat, think time, špičky a souběh mají odpovídat skutečnému provozu.
Připravte reprezentativní prostředí a data
Menší prostředí lze použít, ale rozdíly musí být známé. Testovací data musí zahrnovat realistické objemy a distribuce.
Proveďte baseline, load, stress a soak podle potřeby
Baseline ukáže výchozí stav, load běžnou a špičkovou zátěž, stress hranici a soak dlouhodobou stabilitu.
Monitorujte celý řetězec
Sledujte aplikaci, databázi, fronty, cache, síť a externí závislosti. Samotný čas HTTP odpovědi příčinu neukáže.
Analyzujte a opakujte po změně
Každý tuning ověřte stejným scénářem. Výsledek porovnávejte s verzí, konfigurací a zdroji.
Čemu se naopak vyhnout
- Výkonovému testu až den před spuštěním, kdy už není čas na změnu návrhu.
- Nerealistickému scénáři bez think time a se stejnými daty pro všechny uživatele.
- Hodnocení pouze podle průměrné odezvy.
- Testu na prostředí, jehož rozdíly od produkce nikdo nezná.
- Generování zátěže bez monitoringu databáze, front a závislostí.
Praktický příklad
Před kampaní se očekává import 500 souborů během jedné hodiny a současná práce běžných uživatelů. Test proto kombinuje importy různých velikostí s editací a reportingem. Sledují se 95. a 99. percentil, fronta zpracování, databázové zámky a chybovost externího API.
Soak test odhalí, že po třech hodinách roste počet otevřených spojení. Problém se opraví ještě před ostrou špičkou.
Ponaučení pro praxi
Výkonový test je experiment odpovídající na konkrétní otázku. Realistický model, předem stanovené prahy a monitoring celého systému jsou důležitější než samotný počet virtuálních uživatelů.
Správný postup nemusí být složitý. Důležité je, aby byl vědomý, opakovatelný a aby tým dokázal vysvětlit, proč zvolil právě tento způsob kontroly. Kvalita nevzniká jedním nástrojem ani jednou rolí; vzniká kombinací dobrých otázek, důkazů a následné zpětné vazby.
