Lasttest: Vet du hvor tjenesten din bryter sammen?
En lasttest simulerer mange samtidige brukere for å vise hvor tjenesten din begynner å bli treg eller bryter sammen før de virkelige besøkende finner det ut for deg. Du stiller krav til testen ved å utlede realistiske lastscenarioer fra forretningsplanen og sette mål for responstid og feilrate. Deretter veier du testkostnaden mot hva en driftsstans under lanseringen ville koste.
En lansering, en kampanje eller en sesongtopp kan på noen minutter mangedoble trafikken mot tjenesten din. Spørsmålet er ikke om systemet klarer en vanlig tirsdag, men om det klarer det øyeblikket når alle kommer samtidig. Lasttesting (på engelsk load testing) svarer på det spørsmålet på forhånd, i stedet for at virkeligheten gjør det for deg, rett foran øynene på kundene dine.
Realistiske lastscenarioer fra forretningsplanen
En lasttest er bare så god som scenarioet den bygger på. Å sende tilfeldig trafikk mot en tjeneste sier lite. Det som gir svar, er å etterligne hvordan en reell topp faktisk ser ut. Og det bildet kommer fra forretningsplanen, ikke fra IT-avdelingen.
Ta utgangspunkt i den kommende hendelsen. Skal dere sende et nyhetsbrev til hele listen klokken ni? Da kommer en stor del av trafikken i én kraftig topp akkurat da, ikke jevnt fordelt. Har dere et utsalg? Da øker ikke bare antallet besøkende, men også andelen som legger varer i handlekurven og går til kassen samtidig. Det er de tyngste operasjonene. En realistisk modell tar hensyn til hvor mange som kommer, hvor raskt de kommer, og hva de faktisk gjør.
Et konkret eksempel: En nettbutikk forventer 5 000 besøkende den første kampanjetimen, og kanskje 500 av dem kommer frem til kassen omtrent samtidig. Da tester man ikke «5 000 besøk jevnt fordelt over en time», men en topp der hundrevis av kjøpsprosesser, den mest ressurskrevende delen av trafikken, pågår parallelt. Det er der systemet blir satt på prøve for alvor.
Hvilke målinger som betyr noe
Når testen kjøres, er det tre målinger som teller, med et fornuftig mål for hver av dem.
| Måling | Fornuftig mål |
|---|---|
| Responstid (de tregeste forespørslene) | Sider og handlinger svarer raskt også ved full last, ikke bare i snitt |
| Feilrate | Nær null mislykkede forespørsler under den planlagte toppen |
| Gjennomstrømning | Systemet klarer den forventede toppen med margin til overs |
Det viktigste rådet: Se på de tregeste forespørslene, ikke bare gjennomsnittet. Et snitt kan se fint ut selv om hver tjuende kunde får en side som tar ti sekunder å laste, og det er de kundene som forsvinner. Målene settes ut fra hva brukeren tolererer, og hva virksomheten krever, ikke ut fra hva som tilfeldigvis er lett å oppnå.
Hva testen koster mot en driftsstans
Spørsmålet som avgjør om en lasttest er verdt pengene, er ikke hva testen koster, men hva et sammenbrudd ville koste.
En lasttest er typisk en avgrenset innsats på noen dager til en ukes tid, avhengig av hvor kompleks tjenesten er, og hvor mange scenarioer som skal kjøres. Sett det opp mot det som står på spill: En tjeneste som er nede i lanseringstimen, betyr tapt salg i akkurat det øyeblikket alt er bygget opp mot, pluss tillit som er vanskelig å vinne tilbake når kundene har møtt feilmeldinger. En kampanje du har betalt for å drive trafikk til, er bortkastet hvis siden ikke laster.
Sett i det lyset er testen en billig forsikring. Resultatet viser dessuten hvor flaskehalsene sitter, ofte i databasen eller i for knapp kapasitet. Da kan de utbedres i ro og mak før lansering. Man optimaliserer de svakeste punktene, skalerer opp der det trengs og tester på nytt til marginen er betryggende.
Forskjellen på lasttest og vanlig ytelsestest
Lasttesting blandes noen ganger sammen med å «teste at siden er rask», men det er to forskjellige ting. En vanlig ytelsestest måler hvor raskt en side laster for én besøkende. Det er viktig, men sier ingenting om hva som skjer når tusen kommer samtidig. En side kan laste lynraskt for deg alene og likevel bryte fullstendig sammen under press fordi det er de delte ressursene (databasen, serveren, eksterne tjenester) som blir flaskehalsen først når mange bruker dem parallelt.
Lasttesten handler nettopp om det som skjer samtidig: hvordan systemet oppfører seg når lasten kommer fra mange kanter på én gang. Derfor utfyller de to hverandre. Et raskt svar for én enkelt bruker er en forutsetning. At svaret fortsatt kommer raskt når alle er inne samtidig, er det lasttesten finnes for å bevise. Å forveksle dem er å tro at man har forberedt seg på toppen når man bare har målt hverdagen.
Å bygge en tjeneste som tåler press, er en del av tjenestene våre, og lasttesting hører naturlig hjemme sent i et prosjekt, rett før lansering. Vil du finne ut om tjenesten er testet for den kommende toppen? Ta kontakt, så går vi gjennom scenarioet sammen.
Ofte stilte spørsmål
Hva er en lasttest?
En lasttest simulerer mange samtidige brukere mot tjenesten din for å se hvordan den oppfører seg under press. Man øker den kunstige trafikken trinnvis og måler når responstidene begynner å stige, når feil dukker opp, og til slutt hvor systemet gir opp. Formålet er å finne grensene i en kontrollert situasjon i stedet for å oppdage dem når virkelige kunder prøver å handle samtidig.
Når bør jeg kjøre en lasttest?
Først og fremst når en hendelse kan mangedoble trafikken sammenlignet med en vanlig dag: en lansering, en kampanje, et utsalg eller en sesongtopp. Er trafikken din jevn til vanlig og langt under kapasitetstaket, er risikoen mindre. Men så snart du venter en trafikktopp der mange kommer samtidig, er en test en billig forsikring mot at akkurat det øyeblikket ender i et sammenbrudd.
Hvilke målinger er viktigst i en lasttest?
Responstid (hvor lenge brukeren venter), feilrate (hvor stor andel av forespørslene som mislykkes) og gjennomstrømning (hvor mange forespørsler systemet klarer per sekund). Se særlig på responstiden for de tregeste forespørslene, ikke bare gjennomsnittet: Det er de som avgjør om enkeltkunder får en ubrukelig opplevelse. Fornuftige mål settes ut fra hva brukeren tolererer, og hva virksomheten krever.
Hva koster en lasttest?
Det avhenger av hvor kompleks tjenesten er, og hvor mange scenarioer som skal testes, men det er typisk en avgrenset innsats på noen dager til en ukes tid. Den relevante sammenligningen er ikke kronebeløpet i seg selv, men kostnaden ved en driftsstans under akkurat den toppen du har forberedt deg på. Tapt salg, svekket tillit og en mislykket lansering veier som regel tungt mot prisen på testen.
Hva gjør jeg med resultatet fra en lasttest?
Resultatet viser hvor flaskehalsene sitter, ofte i databasen, i en bestemt tjeneste eller i for knapp kapasitet. Ut fra det utbedrer man de svakeste punktene, optimaliserer eller skalerer opp og tester på nytt. Poenget er å ha gått den runden i ro og mak før lansering slik at du vet at tjenesten holder før trykket kommer for alvor.