Rozdíl mezi load, stress, spike a soak testy
„Chceme zátěžový test.“ Tato věta zní jednoznačně, ale není. Zátěžové testování zahrnuje více typů testů a každý odpovídá na jinou otázku. Pokud tým vybere nesprávný typ, může potvrdit běžný provoz, ale přehlédnout riziko při náhlém nebo dlouhodobém zatížení.
Rozdíl mezi nimi je praktický: jeden test ověří očekávaný provoz, jiný hranici systému, náhlý nárůst nebo dlouhodobou stabilitu.
Běžný problém: test odpoví na jinou otázku, než potřebujete
Krátký test při běžném provozu nepotvrdí, jak se systém chová při náhlém náporu ani po několika hodinách zátěže. Nejprve proto pojmenujte riziko a teprve potom vyberte typ testu. Jinak můžete získat správné měření, které však nepomůže při rozhodování před kampaní nebo releasem.
Čtyři otázky, čtyři testy
Load – zvládneme to, co očekáváme? Vystavíme systém zátěži, která odpovídá běžnému nebo očekávanému provozu, a sledujeme, zda odezvy a chybovost zůstávají v dohodnutých limitech. Odpovídá na otázku, zda systém plní očekávání při plánované zátěži. Opakovaný test může zároveň upozornit na zhoršení výkonu po změně.
Stress – kde je hranice? Zátěž postupně zvyšujeme, dokud systém nepřestane plnit dohodnuté limity. Sledujeme bod, ve kterém výrazně vzrostou odezvy nebo chybovost, a co se vyčerpalo jako první – například databázová spojení, paměť, vlákna nebo procesor. Stress test tak pomáhá odhadnout kapacitní hranici i chování systému za ní.
Spike – zvládneme náhlý nápor? Rozešlete newsletter a během několika minut přijde velká část adresátů. Spike test nesimuluje pomalý nárůst, ale skok – a ověřuje nejen samotný nápor, ale také to, zda se systém po jeho skončení vrátí do běžného stavu.
Soak – vydržíme to dlouho? Rovnoměrnou zátěž udržujeme několik hodin. Mohou se tak projevit pomalé úniky paměti, neuzavřená spojení nebo rostoucí logy – problémy, které krátký test nemusí ukázat.
Jak to děláme
Scénáře navrhujeme podle toho, jak se chovají vaši zákazníci. Namísto opakování jedné jednoduché stránky modelujeme skutečnou cestu: vyhledání produktu, vložení do košíku, přihlášení nebo platbu. Zátěž potom zasáhne stejné části systému jako skutečný provoz.
Skripty píšeme v k6, případně v Locustu podle prostředí; JMeter volíme u starších protokolů mimo HTTP nebo tehdy, když již máte stávající sadu. Během testu sledujeme odezvy, chybovost a propustnost. Pokud jsou dostupné také metriky aplikace, databáze a infrastruktury, porovnáváme je na společné časové ose.
Výběr testů závisí na pojmenovaném riziku. Před kampaní může být důležitý spike nebo stress test, při změně infrastruktury srovnávací load test a při dlouhodobém zatížení soak test. V praxi se často kombinuje více typů, ale rozsah má odpovídat cíli a dostupnému času.
Co z toho máte
Výsledkem je kapacita naměřená u konkrétního scénáře a dohodnutých limitů, popis chování systému při zátěži a pravděpodobná úzká místa. Doporučení lze seřadit podle rizika, očekávaného přínosu a náročnosti.
Stačí, když znáte typický uživatelský scénář a dokážete ho v systému ručně projít. Nemusíte nic skriptovat.
Další krok
Začněte otázkou, na kterou má test odpovědět: očekávaný provoz, kapacitní hranice, náhlá špička nebo dlouhodobá stabilita. Podle ní vyberte typ testu, scénář, délku měření a limity úspěchu.