Belastningstest: Ved du hvor din tjeneste bryder sammen?
En belastningstest simulerer mange samtidige brugere for at vise hvor din tjeneste begynder at blive langsom eller bryder sammen, før rigtige besøgende finder ud af det for dig. Du stiller krav til den ved at udlede realistiske belastningsscenarier af forretningsplanen, sætte mål for svartid og fejlrate og veje testens omkostning op mod hvad et nedbrud under lanceringen ville koste.
En lancering, en kampagne eller en sæsontop kan på få minutter mangedoble trafikken mod din tjeneste. Spørgsmålet er ikke om systemet klarer en almindelig tirsdag, men om det klarer det øjeblik hvor alle kommer på samme tid. En belastningstest besvarer det spørgsmål på forhånd. Ellers gør virkeligheden det for dig, for øjnene af dine kunder.
Realistiske belastningsscenarier ud fra forretningsplanen
En belastningstest er kun så god som det scenarie den bygger på. At sende tilfældig trafik mod en tjeneste siger ikke meget. Det der giver svar, er at efterligne hvordan en virkelig top faktisk ser ud. Og det billede kommer fra forretningsplanen, ikke fra IT-afdelingen.
Tag udgangspunkt i den kommende begivenhed. Skal I sende et nyhedsbrev til hele listen klokken ni? Så kommer en stor del af trafikken som en spids lige på det tidspunkt og ikke jævnt fordelt. Kører I et udsalg? Så stiger ikke kun antallet af besøgende, men også andelen der lægger varer i kurven og går til checkout på samme tid, og det er de tungeste operationer. En realistisk model tager højde for hvor mange der kommer, hvor hurtigt de kommer og hvad de faktisk gør.
Et konkret eksempel: En webshop forventer 5.000 besøgende i den første kampagnetime, hvoraf måske 500 når til checkout omtrent samtidig. Så tester man ikke “5.000 besøg jævnt fordelt over en time”, men en spids hvor hundredvis af købsforløb (den mest ressourcekrævende del) kører parallelt. Det er dér systemet for alvor bliver sat på prøve.
Hvilke målinger der betyder noget
Når testen køres, er der tre målinger der tæller, og hver af dem har et rimeligt mål.
| Måling | Rimeligt mål |
|---|---|
| Svartid (de langsomste forespørgsler) | Sider og handlinger svarer hurtigt selv ved fuld belastning, ikke kun i gennemsnit |
| Fejlrate | Tæt på nul mislykkede forespørgsler under den planlagte top |
| Throughput | Systemet klarer den forventede top med margin til overs |
Det vigtigste råd: Se på de langsomste forespørgsler, ikke kun på gennemsnittet. Et gennemsnit kan se fint ud mens hver tyvende kunde alligevel får en side der tager ti sekunder. Det er de kunder der forsvinder. Mål fastsættes ud fra hvad brugeren tolererer og hvad forretningen kræver, ikke ud fra hvad der tilfældigvis er let at nå.
Hvad testen koster sammenlignet med et nedbrud
Det spørgsmål der afgør om en belastningstest er pengene værd, er ikke hvad testen koster, men hvad et nedbrud ville koste.
En belastningstest er typisk en afgrænset indsats på nogle dage til en uges tid, afhængigt af hvor kompleks tjenesten er og hvor mange scenarier der skal køres. Stil det op mod hvad der står på spil. En tjeneste der er nede i lanceringstimen, betyder tabt salg i præcis det øjeblik alt har været bygget op mod, plus tillid der er svær at vinde tilbage når kunderne er blevet mødt af fejlmeddelelser. En kampagne du har betalt for at drive trafik til siden, er spildt hvis siden ikke indlæses.
I det lys er testen en billig forsikring. Resultatet viser desuden hvor flaskehalsene sidder (ofte i databasen eller i for knapt dimensioneret kapacitet). Dermed kan de udbedres i ro og mag før lanceringen. Man optimerer de svageste punkter, skalerer op hvor det er nødvendigt og tester igen indtil marginen er betryggende.
Forskellen på belastningstest og almindelig performancetest
Belastningstest bliver nogle gange forvekslet med at “teste at siden er hurtig”, men det er to forskellige ting. En almindelig performancetest måler hvor hurtigt en side indlæses for én besøgende. Det er vigtigt, men det siger intet om hvad der sker når tusind kommer på samme tid. En side kan indlæses lynhurtigt for dig alene og alligevel bryde helt sammen under pres. Det er nemlig de delte ressourcer (databasen, serveren, eksterne tjenester) der bliver flaskehalsen, og det sker først når mange bruger dem parallelt.
Belastningstesten handler netop om det samtidige: hvordan systemet opfører sig når der lægges belastning på fra mange sider på én gang. Derfor supplerer de to hinanden. Et hurtigt svar til en enkelt bruger er en forudsætning. At svaret også forbliver hurtigt når alle er inde samtidig, er det belastningstesten findes for at bevise. At forveksle dem er at tro at man har forberedt sig på toppen når man kun har målt hverdagen.
At bygge en tjeneste der holder under pres, er en del af vores ydelser, og belastningstest hører naturligt hjemme sent i et projekt, lige før lanceringen. Vil du have afklaret om din tjeneste er testet til din kommende top? Kontakt os, så gennemgår vi scenariet sammen.
Ofte stillede spørgsmål
Hvad er en belastningstest?
En belastningstest simulerer mange samtidige brugere mod din tjeneste for at se hvordan den opfører sig under pres. Man øger den kunstige trafik trinvis og måler hvornår svartiderne begynder at stige, hvornår der opstår fejl og til sidst hvor systemet giver op. Formålet er at finde grænserne i en kontrolleret situation i stedet for at opdage dem når rigtige kunder forsøger at handle på samme tid.
Hvornår har jeg brug for en belastningstest?
Især når en begivenhed kan mangedoble trafikken i forhold til hverdagen: en lancering, en kampagne, et udsalg eller en sæsontop. Hvis din hverdagstrafik er jævn og ligger langt under kapacitetsloftet, er risikoen mindre. Men så snart du forventer en trafiktop hvor mange kommer på én gang, er en test en billig forsikring mod at netop det øjeblik ender i et nedbrud.
Hvilke målinger er vigtigst i en belastningstest?
Svartid (hvor længe brugeren venter), fejlrate (hvor stor en andel af forespørgslerne der fejler) og throughput (hvor mange forespørgsler systemet klarer pr. sekund). Se især på svartiden for de langsomste forespørgsler, ikke kun på gennemsnittet. Det er dem der afgør om enkelte kunder får en ubrugelig oplevelse. Rimelige mål fastsættes ud fra hvad brugeren tolererer og hvad forretningen kræver.
Hvad koster en belastningstest?
Det afhænger af hvor kompleks tjenesten er og hvor mange scenarier der skal testes, men det er typisk en afgrænset indsats på nogle dage til en uges tid. Den relevante sammenligning er ikke beløbet i sig selv, men omkostningen ved et nedbrud under netop den top du har forberedt dig på. Tabt salg, tabt tillid og en mislykket lancering vejer som regel tungt mod testens pris.
Hvad gør jeg med resultatet af en belastningstest?
Resultatet viser hvor flaskehalsene sidder: ofte i databasen, i en bestemt tjeneste eller i for knapt dimensioneret kapacitet. Ud fra det udbedrer man de svageste punkter, optimerer eller skalerer op og tester igen. Pointen er at have gennemført den runde i ro og mag før lanceringen. Så ved du at tjenesten holder før presset kommer for alvor.