Výkonnostní testy

Co měřit při zátěžovém testu kromě doby odezvy

Doba odezvy je důležitá, ale sama neřekne, zda systém pod zátěží funguje správně. Aplikace může odpovídat rychle proto, že odmítá požadavky, vrací neúplná data nebo přesouvá práci do rostoucí fronty na pozadí. Report s jediným průměrem potom vypadá dobře právě ve chvíli, kdy uživatelé nedokončí nákup.

Smyslem zátěžového testu je popsat vztah mezi množstvím práce, uživatelským výsledkem a chováním systému. Potřebujeme proto několik vrstev metrik a společnou časovou osu, na které je lze porovnat.

Nejprve přesně pojmenujte zátěž

Metriky mají význam jen v kontextu konkrétního modelu zátěže. Hodnota p95 při 20 požadavcích za sekundu neodpovídá na otázku, co systém zvládne při 200 požadavcích. Před testem je třeba zaznamenat:

• počet souběžných virtuálních uživatelů nebo rychlost příchodu nových iterací;
• poměr scénářů, například prohlížení, vyhledávání, přihlášení a objednávka;
• velikost a rozmanitost dat, stav cache a použitou verzi aplikace;
• délku zahřívání, ustáleného měření a ukončení testu;
• prostředí, limity infrastruktury a záměrné odlišnosti od produkce.

Bez těchto údajů nelze dvě měření férově porovnat. Stejně důležité je ověřit, že generátor zátěže nebyl sám přetížený. Pokud mu chybí CPU, síťová kapacita nebo volná spojení, naměřená hranice může patřit generátoru, ne testované aplikaci.

1. Úspěšnost obchodních operací

První otázka není „jak rychle server odpověděl“, ale „kolik uživatelů dokončilo zamýšlenou činnost“. HTTP status 200 ještě nemusí znamenat úspěch. API může v těle vrátit chybový stav, vyhledávání prázdný výsledek pro existující produkt nebo checkout potvrzení bez vytvořené objednávky.

Pro každý klíčový scénář proto sledujte:

• podíl úspěšných a neúspěšných iterací;
• chyby rozdělené podle typu, endpointu a fáze scénáře;
• kontrolu obsahu odpovědi a vzniku očekávaného záznamu;
• počet dokončených obchodních transakcí, například objednávek za minutu;
• případy, které se dokončily až po opakování.

V k6 slouží k ověření konkrétní podmínky checks, ale neúspěšný check sám o sobě nemusí zastavit ani zneúspěšnit test. Dokumentace k6 rozlišuje checks a thresholds: kontrola zaznamená výsledek, zatímco práh rozhoduje, zda bylo kritérium testu splněno. Stejný princip platí i u jiných nástrojů — obchodní výsledek potřebuje měření i jasnou hranici přijatelnosti.

2. Percentily odezvy místo jediného průměru

Průměr skryje pomalý chvost. Sledujte alespoň medián, p90 nebo p95 a u kritických toků také p99. Percentil p95 je hranice, kterou v daném měření nepřekročilo 95 % zaznamenaných požadavků. Neznamená to automaticky stejný podíl spokojených uživatelů, protože jeden uživatel může provést mnoho požadavků.

Odezvu rozdělte podle endpointu nebo obchodního kroku. Celkové p95 míchá rychlé statické požadavky s pomalou platbou a může zakrýt problém nejdůležitější operace. Pokud nástroj poskytuje rozklad času, pomáhá rozlišit DNS, navázání spojení, TLS, čekání na první bajt a přijetí těla odpovědi.

Percentily vyhodnocujte společně s chybovostí. Po překročení kapacity se doba odezvy může paradoxně zlepšit, protože aplikace začne rychle vracet 429 nebo 503. Více o správné interpretaci vysvětluje článek p95 a průměr.

3. Propustnost a vykonaná práce

Propustnost říká, kolik požadavků, iterací nebo obchodních transakcí systém dokončí za časovou jednotku. Musí být jasné, co počítáme. Tisíc HTTP požadavků není tisíc objednávek, protože jedna objednávka může volat několik služeb.

Porovnávejte požadovanou a skutečně dosaženou rychlost. Pokud test plánuje 100 nových iterací za sekundu, ale generátor spustí jen 70, uživatelská zátěž nevznikla podle plánu. Pokud generátor požadavky odesílá správně, ale počet dokončených operací přestane růst, systém pravděpodobně dosáhl kapacitního limitu nebo hromadí práci ve frontě.

Vestavěné metriky k6 například oddělují iterace, požadavky, chybovost a trvání. Bez ohledu na nástroj má report spojovat technickou propustnost s obchodním výstupem.

4. Souběžnost, čekání a fronty

Stejný počet požadavků za sekundu může mít rozdílný dopad podle toho, jak dlouho zůstávají rozpracované. Sledujte počet aktivních požadavků, otevřených spojení a rozpracovaných úloh. Rostoucí souběžnost při nezměněné propustnosti naznačuje, že práce čeká.

Zvláštní pozornost si zaslouží fronty:

• délka fronty a věk nejstarší zprávy;
• doba čekání před zpracováním a samotná doba zpracování;
• počet opakování a zpráv v dead-letter queue;
• rozdíl mezi rychlostí přijímání a dokončování úloh.

Krátký test může vypadat úspěšně, i když každou minutu přibývá nedokončená práce. Při delším běhu fronta zaplní paměť nebo způsobí, že zákazník dostane e-mail o hodiny později. Asynchronní systém proto nelze hodnotit jen podle rychlosti API, které požadavek přijalo.

5. Využití a saturace zdrojů

CPU na 80 % samo o sobě není chyba. Důležité je, zda zdroj dosáhl limitu, vzniká čekání a zhoršuje se uživatelský výsledek. Sledujte proto využití i saturaci:

• CPU, load, throttling kontejnerů a dobu čekání na CPU;
• použitou paměť, růst haldy, garbage collection a restarty kvůli nedostatku paměti;
• diskové operace, latenci úložiště a vyčerpání IOPS;
• síťovou propustnost, retransmise, ztracené pakety a limity spojení;
• obsazení thread poolů, workerů a connection poolů;
• počet instancí a reakci automatického škálování.

Metrika bez limitu se obtížně interpretuje. Padesát databázových spojení může být bezpečných při limitu 200, ale kritických při limitu 50. Do dashboardu proto přidejte kapacitu a čekající požadavky, ne pouze aktuální hodnotu.

6. Databáze, cache a externí závislosti

Výsledná odezva je součtem práce několika komponent. U databáze sledujte délku dotazů, zamykání, počet aktivních spojení, čekání na pool, skeny velkých tabulek a replikaci. U cache je užitečný poměr zásahů a minutí, počet evikcí a doba načtení po minutí.

U každé důležité externí služby zaznamenejte počet volání, chybovost a percentily odezvy. Jeden uživatelský požadavek může po chybě spustit tři opakování a znásobit zátěž na již zpomalenou závislost. Bez samostatných metrik potom vidíte jen pomalý checkout, ne platební volání, pool spojení nebo retry storm, který jej způsobuje.

Časová shoda ještě nedokazuje příčinu. Pokud společně rostou CPU a p99, vytváří to hypotézu. Potvrdit ji je třeba logy, tracingem, profilováním nebo opakovaným testem po cílené změně. Přehled typických kandidátů nabízejí nejčastější úzká místa webu a API.

7. Stabilita v čase a zotavení

Krátký test odhalí okamžitou kapacitu, ne pomalé úniky. U soak testu sledujte trend paměti, růst databáze a front, počet otevřených spojení, pravidelné úlohy a postupné zhoršování percentilů. Stabilní průměrná hodnota může zakrýt pilovitý průběh způsobený garbage collection nebo periodickým vyprazdňováním poolu.

Po skončení zátěže měřte i zotavení. Jak dlouho trvá, než se fronty vyprázdní, počet instancí se vrátí na normální úroveň a chybovost klesne? Systém, který test přežije, ale dalších 40 minut nedokáže obsloužit běžný provoz, potřebuje jiné hodnocení než systém se stejným maximem a rychlým zotavením.

Prahy musí vyjadřovat rozhodnutí

Dashboard ukazuje, co se stalo. Prahy určují, zda je výsledek přijatelný. Mohou znít například: „při cílové zátěži dokončí alespoň 99,5 % checkoutů, p95 kroku platby nepřekročí dohodnutou hodnotu a věk nejstarší zprávy zůstane pod limitem.“

Dokumentace k6 k thresholds doporučuje vyjádřit očekávání jako kritéria pass/fail. Práh však nemá být zkopírované obecné číslo. Musí vycházet z uživatelské potřeby, obchodního rizika, SLA nebo srovnatelné produkční zkušenosti.

Rozlišujte cílovou zátěž, hraniční test a záměrný stress test. U stress testu očekáváme degradaci; úspěchem může být kontrolované odmítání bez poškození dat a následné zotavení, nikoli stejné časy jako při běžném provozu.

Jak má vypadat použitelný report

Report by měl spojit model zátěže, verzi systému, prahy a časové grafy. Na jedné ose zobrazte rychlost příchodu, úspěšné transakce, chyby a percentily. Na dalších panelech přidejte zdroje, fronty, databázi a závislosti. Označte změnu fáze testu, škálování, nasazení nebo incident.

Závěr nemá být jen „p95 bylo 1,8 sekundy“. Užitečnější je: při jaké zátěži začala růst fronta, která obchodní operace selhala jako první, jaký limit se vyčerpal a co je potřeba ověřit v dalším testu. Pokud příčina není potvrzena, označte ji jako hypotézu.

Co z toho tým získá

Vícevrstvé měření promění zátěžový test z grafu odezvy v podklad pro rozhodnutí. Produktový vlastník vidí, které uživatelské cesty se při cílové zátěži dokončí, vývojáři dostanou konkrétní hypotézu o úzkém místě a provoz zná vyčerpaný limit i dobu zotavení.

Stejná sada metrik zároveň umožní porovnat dvě verze systému bez dojmů. Tým dokáže posoudit, zda optimalizace zrychlila kritickou operaci bez zvýšení chybovosti, přesunu práce do fronty nebo nepřiměřené spotřeby infrastruktury.

Další krok

Ke stávajícímu scénáři doplňte tři vrstvy: úspěšnost obchodní operace, propustnost a alespoň jednu metriku saturace pravděpodobného úzkého místa. Nastavte prahy ještě před spuštěním a ověřte, že generátor dosáhl plánované zátěže. Z měření času tak vznikne test, podle kterého lze rozhodnout o kapacitě, riziku releasu i další diagnostice.