Az év legforgalmasabb kereskedelmi napjain egy webshop látogatottsága a szokásos többszörösére ugorhat, ráadásul a forgalom nem egyenletesen oszlik el: egy hírlevél kiküldése vagy egy akció indulása percek alatt is okozhat hirtelen csúcsot. A Black Friday előtti terheléses tesztelés megmutatja, hogyan viselkedik a rendszer a várt csúcsforgalom alatt. Ez tehát nem pusztán technikai finomhangolás, hanem a legfontosabb értékesítési napok üzleti biztosítéka.

A következmények azonnaliak. Egy leállást vagy lassulást nem lehet elintézni annyival, hogy „majd kijavítjuk”. Minden kiesett perc azonnali bevételkiesést jelent, a csúcsnapon elpártoló vevők pedig jó eséllyel a konkurenciánál költik el a pénzüket. A sebesség hatása egy átlagos napon is kézzelfogható. A Deloitte kutatása, amely a Google megbízásából készült, 37 európai és amerikai márka adatait vizsgálta meg. Az eredmények szerint a kiskereskedelmi mobiloldalak 0,1 másodperces gyorsulása átlagosan 8,4%-kal növelte a konverziót. Csúcsterhelés alatt ráadásul a lassulás nem tizedmásodpercekben, hanem sokszor hosszú másodpercekben, akár tíz-húsz másodperces várakozásban mérhető.

A minőség és a bevétel általános kapcsolatáról A tesztelés nem költség, hanem bevételvédelem cikkünkben írtunk. Ez a cikk a csúcsterhelésre való felkészülésről szól: hol enged először a rendszer, hogyan mérhető ez előre, és mikor késő már elkezdeni.

Hol enged először a rendszer?

A leggyakoribb tévhit, hogy csúcsforgalomkor a kezdőlap dől össze. A kezdőlap és a termékoldalak tartalma jellemzően gyorsítótárból (cache) és tartalomkiszolgáló hálózatról (CDN) érkezik, ezért jól bírja a terhelést. A szűk keresztmetszet általában ott van, ahol a rendszernek valóban dolgoznia kell:

• Kosár és fizetés: minden lépés adatbázis-műveletet, készletellenőrzést és külső hívást jelent.
• Készletkezelés: sok egyidejű vásárlás ugyanarra a termékre zárolásokat és várakozást okozhat, rosszabb esetben túlértékesítést. Itt egy fontos üzleti döntést is tesztelni kell. Ha a rendszer már a kosárba tételkor lefoglalja a készletet, a nézelődők elvihetik az árut a valódi vásárlók elől. Ha viszont csak a fizetés végén ellenőrzi a darabszámot, könnyen túlértékesítés és reklamációáradat lehet a vége.
• Keresés és szűrés: erőforrásigényes lekérdezések, amelyek csúcsidőben egymást lassítják.
• Bejelentkezés és munkamenet-kezelés: a személyre szabott adatokat nem lehet gyorsítótárból kiszolgálni.
• Külső szolgáltatók: fizetési szolgáltató, szállítási modul, ajánlómotor, marketingszkriptek. Bármelyikük megakaszthatja a teljes vásárlási folyamatot.

Képzeljünk el egy webshopot, amelynek termékoldalai a csúcsban is gyorsak, de a fizetési lépés harminc másodpercig tölt. A vásárlók egy része kivár, más része kilép, a látogatottsági statisztika pedig közben rekordot mutat. A kár csak utólag, a bevételi számokból látszik.

Terheléses, stressz- és tartóssági teszt: mi a különbség?

A teljesítménytesztelés nem egyetlen mérés. Az ISTQB (nemzetközi szoftvertesztelői minősítő szervezet) szakmai anyaga is több típust különít el, amelyek mind eltérő kérdésekre adnak választ:

• Terheléses teszt: elbírja-e a rendszer a várt csúcsforgalmat elfogadható válaszidővel?
• Stresszteszt: hol van a töréspont, és mi történik azon túl? Fokozatosan lassul a rendszer, vagy összeomlik?
• Tartóssági teszt: órákon át tartó magas forgalom alatt sem romlik-e a működés, például memóriaszivárgás vagy elfogyó adatbázis-kapcsolatok miatt?
• Tüsketeszt: hogyan reagál a rendszer egy hirtelen, meredek forgalmi ugrásra, például egy akció indulásakor?

A csúcsnapon mindegyik releváns. A terheléses teszt megmutatja, hogy a tervezett forgalom rendben lesz-e, a stresszteszt pedig azt, mekkora a tartalék arra az esetre, ha a kampány a vártnál sikeresebb. A tüsketeszt különösen azoknál fontos, akik a felhő automatikus skálázására (auto-scaling) bízzák magukat. Az új szerverek elindítása perceket vesz igénybe, miközben egy hírlevél vagy villámakció forgalma másodpercek alatt zúdul a rendszerre. Ráadásul a webes kiszolgálók számának növelése nem oldja meg az adatbázis szintű szűk keresztmetszeteket, sőt a több kiszolgáló még jobban terheli az adatbázist. A tartóssági teszt akkor kap különös súlyt, ha az akció nem csupán egy napig, hanem egy teljes hétvégén vagy héten át zajlik. Ilyenkor a rendszernek nem egyetlen rövid rohamot, hanem a napokon át fennálló, folyamatosan magas terhelést kell kibírnia.

Mitől lesz életszerű a teszt?

Egy terheléses teszt annyit ér, amennyire hasonlít a valóságra. A leggyakoribb hiba, hogy a teszt egyetlen oldalt ostromol, miközben a valódi vásárlók sokféle útvonalon mozognak. Az életszerű teszt négy feltétele:

• Valós felhasználói utak. Nem mindenki vásárol: a látogatók nagy része csak böngészik, kevesebben tesznek kosárba, és csak kisebb hányaduk jut el a fizetésig. A tesztnek ezeket a valódi arányokat kell leképeznie.
• Adatalapú csúcsbecslés. A várható terhelést a korábbi évek forgalmából és a kampánytervből kell megbecsülni, megfelelő biztonsági ráhagyással.
• Külső szolgáltatók kezelése. A fizetési és szállítási partnereket be kell vonni, vagy valósághűen szimulálni kell a válaszidejüket és a hívási korlátaikat.
• Éleshez közeli tesztkörnyezet. Valósághű adatmennyiséggel kell dolgozni, mert egy üres adatbázis mindig gyors.

A mérés is csak akkor hasznos, ha üzleti nyelven értelmezhető. Az átlagos válaszidő önmagában félrevezető, mert elrejti a szélsőségeket. Egy két másodperces átlag mögött könnyen előfordulhat, hogy minden tizedik vásárlónak tíz másodpercet kell várnia. Ezért a leglassabb kiszolgálásokat is külön vizsgálni kell. A riportokban ezt a p95 és p99 mutatók jelzik, amelyek megmutatják, mennyi időn belül teljesül a kérések 95, illetve 99%-a. Emellett folyamatosan figyelni kell a hibaarányt és az átbocsátóképességet is, vagyis a percenként feldolgozott tranzakciók számát. A tesztelés előtt érdemes konkrét üzleti küszöböket rögzíteni: például hogy a fizetés csúcsidőben is néhány másodperc alatt lezáruljon, a sikertelen tranzakciók aránya pedig ne emelkedjen. Ezekhez viszonyítva a teszt eredménye egyértelmű lesz: a rendszer vagy átmegy a vizsgán, vagy megbukik. Ha pedig nem felel meg, pontosan látszik, melyik lépés okozza a fennakadást.

Időzítés: mikor késő már?

A terheléses tesztelés valódi értéke az, hogy lehetőséget ad a feltárt hibák időbeni kijavítására. Ezért az ideális időpont hetekkel a csúcs előtt van, amikor marad idő az eredmények elemzésére, a javításra és az újramérésre. A gyorsítótárazás finomítása, egy hiányzó adatbázis-index pótlása vagy egy külső szolgáltatói korlát emelése napok alatt megoldható. Egy architekturális szűk keresztmetszet átépítése viszont nem. A külső partnerekkel is időben egyeztetni kell. Sok fizetési és szállítási rendszer korlátozza a percenkénti hívások számát, ezt a limitet pedig még a roham előtt kell megemeltetni és nem éles helyzetben szembesülni vele.

Az utolsó hetekben is van mit tenni:

• Változásbefagyasztás: a csúcs előtt már csak kritikus javítás kerüljön élesbe. Ilyenkor a jó élesítés (release) a kiszámítható élesítés, ahogy arról a Mit jelent egy sikeres release a CIO szemével? cikkünkben is írtunk.
• Kritikus útvonalak gyors újramérése: a kosár és a fizetési folyamat célzott ellenőrzése az utolsó módosítások után.
• A monitorozás és a riasztások főpróbája: annak tesztelése, hogy a csapat időben észleli-e a lassulást, és mindenki pontosan tudja-e a dolgát.
• Vészforgatókönyv: várakoztató oldal beállítása, vagy egyes kényelmi funkciók (például termékajánlók, élő keresés) ideiglenes lekapcsolása azért, hogy maga a vásárlás működőképes maradjon. Ugyanez érvényes a külső partnerekre is: ha egy csomagpont-választó vagy hűségpont-lekérdezés lelassul, esetleg leáll, a fizetés nem akadhat el miatta. A rendszer ilyenkor kínáljon fel alapértelmezett opciót, vagy pótolja a lépést később, a háttérben. Ezt nevezzük kontrollált funkcióvesztésnek (graceful degradation).

A csúcsnap után pedig érdemes rögzíteni a tanulságokat: hol volt szoros a tartalék, mi működött jól, és mire kell a következő szezonban jobban figyelni.

Összegzés

A csúcsforgalom előre látható esemény, ezért a teljesítményproblémák is előre felderíthetők. A Black Friday előtti terheléses tesztelés nem technikai luxus, hanem a legforgalmasabb napok bevételének biztosítása, és akkor ér a legtöbbet, ha marad idő a javításra.

A vezetői kérdés egyszerű: tudjuk-e pontosan, hány egyidejű vásárlót bír el a fizetési folyamatunk elfogadható válaszidővel, és mi történik akkor, ha még egy valaki belép?

Források

Deloitte és Google: Milliseconds Make Millions (2020), a mobiloldalak sebessége és a konverzió közötti összefüggés 37 márka adatain. Elérhető: deloitte.com

ISTQB: Certified Tester Performance Testing Syllabus (2018), a teljesítménytesztelés típusai. Elérhető: istqb.org