Belastningstest – vet du var din tjänst går sönder?

En lansering, en kampanj eller en säsongstopp kan på några minuter mångdubbla trafiken mot din tjänst. Frågan är inte om systemet klarar en vanlig tisdag, utan om det klarar den där stunden när alla kommer samtidigt. Ett belastningstest svarar på den frågan i förväg – i stället för att verkligheten gör det åt dig, framför ögonen på dina kunder.

Realistiska lastscenarier från affärsplanen

Ett belastningstest är bara så bra som scenariot det bygger på. Att kasta slumpmässig trafik mot en tjänst säger lite; det som ger svar är att efterlikna hur en verklig topp faktiskt ser ut. Och den bilden kommer från affärsplanen, inte från teknikavdelningen.

Utgå från den kommande händelsen. Ska ni skicka ett nyhetsbrev till hela listan klockan nio? Då kommer en stor del av trafiken i en spik just då, inte jämnt utspridd. Kör ni en rea? Då ökar inte bara antalet besökare, utan också andelen som lägger i varukorgen och går till kassan samtidigt – de tyngsta operationerna. En realistisk modell tar hänsyn till hur många som kommer, hur snabbt de kommer och vad de faktiskt gör.

Ett konkret exempel: en webbutik väntar sig 5 000 besökare den första kampanjtimmen, varav kanske 500 når kassan ungefär samtidigt. Då testar man inte “5 000 besök jämnt över en timme”, utan en spik där hundratals köpflöden – det mest resurskrävande – pågår parallellt. Det är där systemet prövas på riktigt.

Vilka mätvärden som spelar roll

När testet körs är det tre mätvärden som räknas, och rimliga mål för var och en.

Det viktigaste rådet: titta på de långsammaste anropen, inte bara genomsnittet. Ett snitt kan se fint ut medan var tjugonde kund ändå får en sida som tar tio sekunder – och det är de kunderna som lämnar. Mål sätts utifrån vad användaren tolererar och vad affären kräver, inte utifrån vad som råkar vara lätt att uppnå.

Vad testet kostar mot ett driftstopp

Frågan som avgör om ett belastningstest är värt pengarna är inte vad testet kostar, utan vad ett haveri skulle kosta.

Ett belastningstest är typiskt en avgränsad insats på några dagar till någon vecka, beroende på hur komplex tjänsten är och hur många scenarier som ska köras. Ställ det mot vad som står på spel: en tjänst som ligger nere under lanseringstimmen betyder förlorad försäljning i exakt det ögonblick allt byggts upp mot, plus förtroende som är svårt att vinna tillbaka när kunder mötts av felmeddelanden. En kampanj du betalat för att driva trafik till blir förspilld om sidan inte laddar.

I det ljuset är testet billig försäkring. Resultatet visar dessutom var flaskhalsarna sitter – ofta i databasen eller i för snålt tilltagen kapacitet – så att de kan åtgärdas i lugn och ro före lansering. Man optimerar de svagaste punkterna, skalar upp där det behövs och testar om, tills marginalen är betryggande.

Skillnaden mot ett vanligt prestandatest

Belastningstest blandas ibland ihop med att “testa att sidan är snabb”, men det är två olika saker. Ett vanligt prestandatest mäter hur snabbt en sida laddar för en besökare – viktigt, men det säger inget om vad som händer när tusen kommer samtidigt. En sida kan ladda blixtsnabbt för dig ensam och ändå vika sig totalt under tryck, eftersom det är de delade resurserna – databasen, servern, externa tjänster – som blir flaskhalsen först när många använder dem parallellt.

Belastningstestet handlar just om det samtidiga: hur systemet beter sig när last läggs på från många håll på en gång. Därför kompletterar de två varandra. Ett snabbt svar för en ensam användare är en förutsättning; att svaret håller sig snabbt även när alla är inne samtidigt är det belastningstestet finns för att bevisa. Att förväxla dem är att tro att man förberett sig för toppen när man bara mätt vardagen.

Att bygga en tjänst som håller under tryck är en del av våra tjänster, och belastningstest hör naturligt hemma sent i ett projekt, strax före lansering. Vill du reda ut om din kommande topp är testad för? Hör av dig så går vi igenom scenariot tillsammans.