Výkonnostné testy

Čo merať pri záťažovom teste okrem času odozvy

Čas odozvy je dôležitý, ale sám nevie povedať, či systém pod záťažou funguje správne. Aplikácia môže odpovedať rýchlo preto, že odmieta požiadavky, vracia neúplné dáta alebo presúva prácu do rastúceho radu na pozadí. Report s jediným priemerom potom vyzerá dobre práve vo chvíli, keď používatelia nedokončia nákup.

Zmyslom záťažového testu je opísať vzťah medzi množstvom práce, používateľským výsledkom a správaním systému. Potrebujeme preto viac vrstiev metrík a spoločnú časovú os, na ktorej sa dajú porovnať.

Najprv presne pomenujte záťaž

Metriky majú význam iba v kontexte konkrétneho modelu záťaže. Hodnota p95 pri 20 požiadavkách za sekundu neodpovedá na otázku, čo systém zvládne pri 200 požiadavkách. Pred testom treba zaznamenať:

• počet súbežných virtuálnych používateľov alebo rýchlosť príchodu nových iterácií;
• pomer scenárov, napríklad prehliadanie, vyhľadávanie, prihlásenie a objednávka;
• veľkosť a rozmanitosť dát, stav cache a použitú verziu aplikácie;
• dĺžku zahrievania, ustáleného merania a ukončenia testu;
• prostredie, limity infraštruktúry a úmyselné odlišnosti od produkcie.

Bez týchto údajov nemožno dve merania férovo porovnať. Rovnako dôležité je overiť, že generátor záťaže nebol sám preťažený. Ak mu chýba CPU, sieťová kapacita alebo voľné spojenia, nameraná hranica môže patriť generátoru, nie testovanej aplikácii.

1. Úspešnosť obchodných operácií

Prvá otázka nie je „ako rýchlo server odpovedal“, ale „koľko používateľov dokončilo zamýšľanú činnosť“. HTTP status 200 ešte nemusí znamenať úspech. API môže v tele vrátiť chybový stav, vyhľadávanie prázdny výsledok pre existujúci produkt alebo checkout potvrdenie bez vytvorenej objednávky.

Pre každý kľúčový scenár preto sledujte:

• podiel úspešných a neúspešných iterácií;
• chyby rozdelené podľa typu, endpointu a fázy scenára;
• kontrolu obsahu odpovede a vznik očakávaného záznamu;
• počet dokončených obchodných transakcií, napríklad objednávok za minútu;
• prípady, ktoré sa dokončili až po opakovaní.

V k6 slúžia na overenie konkrétnej podmienky checks, no neúspešný check sám osebe nemusí zastaviť ani zneúspešniť test. Dokumentácia k6 odlišuje checks a thresholds: kontrola zaznamená výsledok, zatiaľ čo prah rozhoduje, či je kritérium testu splnené. Rovnaký princíp platí aj pri iných nástrojoch — obchodný výsledok potrebuje meranie aj jasnú hranicu prijateľnosti.

2. Percentily odozvy namiesto jediného priemeru

Priemer skryje pomalý chvost. Sledujte aspoň medián, p90 alebo p95 a pri kritických tokoch aj p99. Percentil p95 je hranica, ktorú v danom meraní neprekročilo 95 % zaznamenaných požiadaviek. Neznamená to automaticky rovnaký podiel spokojných používateľov, pretože jeden používateľ môže vykonať mnoho požiadaviek.

Odozvu rozdeľte podľa endpointu alebo obchodného kroku. Celkové p95 zmiešava rýchle statické požiadavky s pomalou platbou a môže zakryť problém najdôležitejšej operácie. Ak nástroj poskytuje rozklad času, pomáha rozlíšiť DNS, nadviazanie spojenia, TLS, čakanie na prvý bajt a prijatie tela odpovede.

Percentily vyhodnocujte spolu s chybovosťou. Po prekročení kapacity sa čas odozvy môže paradoxne zlepšiť, pretože aplikácia začne rýchlo vracať 429 alebo 503. Viac o správnej interpretácii vysvetľuje článok p95 a priemer.

3. Priepustnosť a vykonaná práca

Priepustnosť hovorí, koľko požiadaviek, iterácií alebo obchodných transakcií systém dokončí za časovú jednotku. Musí byť jasné, čo počítame. Tisíc HTTP požiadaviek nie je tisíc objednávok, pretože jedna objednávka môže volať viacero služieb.

Porovnávajte požadovanú a skutočne dosiahnutú rýchlosť. Ak test plánuje 100 nových iterácií za sekundu, ale generátor spustí len 70, používateľská záťaž nebola vytvorená podľa plánu. Ak generátor požiadavky odosiela správne, no počet dokončených operácií prestane rásť, systém pravdepodobne dosiahol kapacitný limit alebo hromadí prácu vo fronte.

Vstavané metriky k6 napríklad oddeľujú iterácie, požiadavky, chybovosť a trvanie. Bez ohľadu na nástroj má report spájať technickú priepustnosť s obchodným výstupom.

4. Súbežnosť, čakanie a fronty

Rovnaký počet požiadaviek za sekundu môže mať rozdielny dopad podľa toho, ako dlho zostávajú rozpracované. Sledujte počet aktívnych požiadaviek, otvorených spojení a rozpracovaných úloh. Rastúca súbežnosť pri nezmenenej priepustnosti naznačuje, že práca čaká.

Osobitnú pozornosť si zaslúžia fronty:

• dĺžka radu a vek najstaršej správy;
• čas čakania pred spracovaním a samotný čas spracovania;
• počet opakovaní a správ v dead-letter queue;
• rozdiel medzi rýchlosťou prijímania a dokončovania úloh.

Krátky test môže vyzerať úspešne, hoci každú minútu pribúda nedokončená práca. Pri dlhšom behu front zaplní pamäť alebo spôsobí, že zákazník dostane e-mail o hodiny neskôr. Preto asynchrónny systém nemožno hodnotiť len podľa rýchlosti API, ktoré požiadavku prijalo.

5. Využitie a saturácia zdrojov

CPU na 80 % samo osebe nie je chyba. Dôležité je, či zdroj dosiahol limit, vzniká čakanie a zhoršuje sa používateľský výsledok. Sledujte preto využitie aj saturáciu:

• CPU, load, throttling kontajnerov a čas čakania na CPU;
• použitú pamäť, rast haldy, garbage collection a reštarty pre nedostatok pamäte;
• diskové operácie, latenciu úložiska a vyčerpanie IOPS;
• sieťovú priepustnosť, retransmisie, stratené pakety a limity spojení;
• obsadenie thread poolov, workerov a connection poolov;
• počet inštancií a reakciu automatického škálovania.

Metrika bez limitu sa interpretuje ťažko. Päťdesiat databázových spojení môže byť bezpečných pri limite 200, ale kritických pri limite 50. Do dashboardu preto pridajte kapacitu a čakajúce požiadavky, nie iba aktuálnu hodnotu.

6. Databáza, cache a externé závislosti

Výsledná odozva je súčtom práce viacerých komponentov. Pri databáze sledujte dĺžku dopytov, zamykanie, počet aktívnych spojení, čakanie na pool, skeny veľkých tabuliek a replikáciu. Pri cache je užitočný pomer zásahov a minutí, počet evikcií a čas načítania po minutí.

Pri každej dôležitej externej službe zaznamenajte počet volaní, chybovosť a percentily odozvy. Jedna používateľská požiadavka môže po chybe spustiť tri opakovania a znásobiť záťaž na už spomalenú závislosť. Bez samostatných metrík potom vidíte iba pomalý checkout, nie platobné volanie, pool spojení alebo retry storm, ktorý ho spôsobuje.

Časová zhoda ešte nedokazuje príčinu. Ak spolu rastú CPU a p99, vytvára to hypotézu. Potvrdiť ju treba logmi, tracingom, profilovaním alebo opakovaným testom po cielenej zmene. Prehľad typických kandidátov ponúkajú najčastejšie úzke miesta webu a API.

7. Stabilita v čase a zotavenie

Krátky test odhalí okamžitú kapacitu, nie pomalé úniky. Pri soak teste sledujte trend pamäte, rast databázy a frontov, počet otvorených spojení, pravidelné úlohy a postupné zhoršovanie percentilov. Stabilná priemerná hodnota môže zakryť pílovitý priebeh spôsobený garbage collection alebo periodickým vyprázdňovaním poolu.

Po skončení záťaže merajte aj zotavenie. Ako dlho trvá, kým sa fronty vyprázdnia, počet inštancií sa vráti na normálnu úroveň a chybovosť klesne? Systém, ktorý test prežije, ale ďalších 40 minút nevie obslúžiť bežnú prevádzku, potrebuje iné hodnotenie než systém s rovnakým maximom a rýchlym zotavením.

Prahy musia vyjadrovať rozhodnutie

Dashboard ukazuje, čo sa stalo. Prahy určujú, či je výsledok prijateľný. Môžu znieť napríklad: „pri cieľovej záťaži dokončí aspoň 99,5 % checkoutov, p95 kroku platby neprekročí dohodnutú hodnotu a vek najstaršej správy zostane pod limitom.“

Dokumentácia k6 k thresholds odporúča vyjadriť očakávania ako kritériá pass/fail. Prah však nemá byť skopírované všeobecné číslo. Musí vychádzať z používateľskej potreby, obchodného rizika, SLA alebo porovnateľnej produkčnej skúsenosti.

Rozlišujte cieľovú záťaž, hraničný test a úmyselný stress test. Pri stress teste očakávame degradáciu; úspechom môže byť kontrolované odmietanie bez poškodenia dát a následné zotavenie, nie splnenie rovnakých časov ako pri bežnej prevádzke.

Ako má vyzerať použiteľný report

Report by mal spojiť model záťaže, verziu systému, prahy a časové grafy. Na jednej osi zobrazte rýchlosť príchodu, úspešné transakcie, chyby a percentily. Na ďalších paneloch pridajte zdroje, fronty, databázu a závislosti. Označte zmenu fázy testu, škálovanie, nasadenie alebo incident.

Záver nemá byť iba „p95 bolo 1,8 sekundy“. Užitočnejšie je: pri akej záťaži sa začal zvyšovať rad, ktorá obchodná operácia zlyhala ako prvá, aký limit sa vyčerpal a čo treba overiť v ďalšom teste. Ak príčina nie je potvrdená, označte ju ako hypotézu.

Čo z toho tím získa

Viacvrstvové meranie premení záťažový test z grafu odozvy na podklad pre rozhodnutie. Produktový vlastník vidí, ktoré používateľské cesty sa pri cieľovej záťaži dokončia, vývojári dostanú konkrétnu hypotézu o úzkom mieste a prevádzka pozná vyčerpaný limit aj čas zotavenia.

Rovnaká sada metrík zároveň umožní porovnať dve verzie systému bez dojmov. Tím vie posúdiť, či optimalizácia zrýchlila kritickú operáciu bez zvýšenia chybovosti, presunu práce do frontu alebo neprimeranej spotreby infraštruktúry.

Ďalší krok

K existujúcemu scenáru doplňte tri vrstvy: úspešnosť obchodnej operácie, priepustnosť a aspoň jednu metriku saturácie pravdepodobného úzkeho miesta. Nastavte prahy ešte pred spustením a overte, že generátor dosiahol plánovanú záťaž. Tak z merania času vznikne test, podľa ktorého sa dá rozhodnúť o kapacite, riziku releasu aj ďalšej diagnostike.