Skapa användarscenarier
Som med alla typer av test så är kan ett lasttest aldrig garantera att ett system är felfritt och kommer att fungera i alla situationer, utan enbart verifiera att det att de testfall eller användarscenarier som faktiskt körs fungerar som tänkt.
Om man vill få ett någorlunda komplett lasttest av sin e-handelssajt räcker det inte att enbart simulera användare som surfar runt på sajten och tittar på produkterna, utan man behöver också simulera att användare registrerar sig, loggar in, besöker kundvagnen, och även genomför köp. För enkelhets skull tänker vi oss här enbart två användarscenarier: (i) produktbrowsing, och (ii) inlogg och köp.
I det första scenariet surfar vi enbart runt på sajten och tittar på produkterna. Ett sådant användarfall är väldigt enkelt att spela in med hjälp av ett lasttestverktyg som t ex OctoPerf, men för att resultatet från lasttestet skall bli rättvisande är det helt avgörande att det inspelade scenariet stämmer överens med de verkliga användarnas beteende både vad gäller vilka sidor som besöks och hur länge användaren stannar på varje sida. Verktyg som Google Analytics kan vara en bra utgångspunkt, men en svårighet med att lasttesta inför t ex kampanjer är att användarnas beteende i samband med en kampanj ofta skiljer sig radikalt från deras vanliga beteende. Det bästa är därför om man har statistik från tidigare kampanjer som man kan använda sig av. Användarscenarierna sparas i form av ett script vilket gör det möjligt att även i efterhand gå in och ändra på väntetider samt vilka sidor som besöks. Den avancerade användaren kan även anpassa scripten så att de slumpvis väljer vilka produkter som skall besökas och hur länge varje sida skall visas, och därigenom både få en högre täckningsgrad i testet och ett mer verklighetsnära beteende vad gäller väntetider.
Även det andra scenariet går att enkelt att spela in med lastverktyget. Här är det dock alltid nödvändigt att justera det inspelade scriptet i efterhand, om man nu inte vill att exakt samma användare simultant loggar in och lägger ordrar från ett stort antal olika browsersessioner. Detta kan lösas genom att man i förväg skapar upp ett flertal testanvändare och att scriptet slumpvis hämtar upp inloggningsuppgifterna för någon av dessa.
Köra lasttestet
När man skall köra ett lasttest behöver man, förutom användarscenarierna, också ta fram en lastprofil. Lastprofilen beskriver hur många simulerade användare som skall köra ett visst användarscenarie vid varje tidpunkt under testet. Precis som för varje användarscenarie är det även viktigt att fördelningen mellan de olika användarscenarierna stämmer överens med de verkliga användarnas beteende, och även här kan beteendet under en kampanj skilja sig från det normala. Det är t ex vanligt att konverteringsgraden är högre än normalt under en kampanj så utgår man från statistik från en normal dag så behöver andelen användare som faktiskt lägger ordrar alltså troligtvis att ökas.
När det gäller antalet samtidiga användare som man vill lasta med så vill man normalt starta på en låg nivå och sedan successivt öka lasten upp till ett givet tak för att se hur detta påverkar t ex laddtiden. Maxtaket bestäms av de krav man har på sajten gällande antal samtidiga besökare. Ibland saknas dock dessa krav och man vill istället se var gränsen går för hur mycket systemet orkar med. Som vi skrev i den första artikeln så är det här egentligen per definition ett stresstest, men den enda skillnaden är egentligen att man ökar på så mycket att någon resurs slår i taket och inte längre klarar av att leverera resultatet i samma takt som anropen strömmar in.
Vill man stresstesta sajten är det naturligtvis lämpligt att göra detta vid en tidpunkt när så få normala användare som möjligt är inne på sajten, t ex på natten.
Under lasttestet genereras sedan ett önskat antal instanser av varje användarscenarie enligt den lastprofil som tagits fram, och laddtiderna för varje sidexekvering samlas in i samband med att dessa körs. Förutom laddtiderna sett ur användarens perspektiv kan det också vara bra att hålla en koll på webbservrarna för sajten, databasserver, och lastbalanserare under testets gång för att få en samlad bild av vad det är som bromsar upp om laddtiderna ökar.
Utvärdera resultatet
Det resultat som man typiskt förväntar sig i samband med ett lasttest är att man har en konstant laddtid fram till en viss last vid vilken laddtiden börjar öka proportionellt mot lasten. Denna brytpunkt innebär att någon resurs utnyttjas fullt ut och att användarna därför måste börja köa och vänta på att få ta del av resursen. Så länge laddtiderna inte ökar så mycket att användarupplevelsen börjar påverkas så behöver inte det här i sig vara alarmerande. Dock bör man naturligtvis utreda vad som utgör flaskhalsen och som gör att användarna behöver vänta. Om en viss resurs, t ex bandbredd tar slut långt innan övriga resurser så utnyttjar man t ex inte sina servrar särskilt bra. Vid sådana fall kan lasttestverktyget t ex ge information om hur stor del av bandbredden som går åt till olika bildtyper, javascript. Detta kan sedan ge information om man behöver öka sin egen bandbredd, eller om man helt enkelt kan flytta en del statiskt innehåll till någon molnlösning som Akamai.
Ett lite mer oroväckande resultat är om laddtiden ökar exponentiellt istället för proportionellt. Detta betyder att systemet är väldigt nära en bristningsgräns. I den nedanstående grafen visas resultatet av ett lasttest där CPU-lasten (gul kurva) har i taket. Laddtiden (blå kurva) ökar då betydligt mer än lasten (grön kurva). Anledningen till detta är att när servern börjar närma sig 100 % CPU-last så levererar den helt enkelt mindre än när den ligger en bit under. Detta kan ses på att även den levererade bandbredden (röd kurva) börjar minska. I det här fallet hade man alltså fått ut mer ur systemet om man helt enkelt ströp bandbredden så att användarna köades upp innan CPU-lasten gick i taket.
Genom att lasttesta kan man alltså både få ett mått på systemets begränsningar, samt värdefull information om hur man bäst använder sina befintliga resurser. I den sista och avslutande delen om lasttest kommer vi att titta på hur man kontinuerligt kan använda sig av lasttester som en del av sin QoS-testing.
