Omsätta verksamhetens krav till mätbara mål.
En av utmaningarna vid prestandatester är att omsätta verksamhetens prestandamål vad applikationen skall klara av till mätbara mål som kan användas vid prestandatesterna.
Bristfälliga prestandatester
Jag vill påstå att inte ha koll på ovan nämnda är den största anledningen till många bristfälliga prestandatester. Fina diagram om vad som prestandatestats, men klarar dom av prestandamålen ?
Hur gör man ?
Genom en dialog med verksamheten i kombination med nuvarande produktionsdata och nuvarande konfigurationsuppsättningar så kan man komma ner till en modell för mätbara mål.
Viktigt i processen är att dokumentera resonemanget så att det blir transparent för verksamheten och de som skall utföra prestandatesterna och skriva rapporten.
Verksamheterna använder oftast termer som att applikationen exempelvis skall klara av 5000 samtidiga användare.
Det är nu som vi prestandatestare tillsammans med verksamheten i flera moment skall bryta ner detta krav till mätbara mål.
Första momentet är att definiera vad användarna gör och omforma detta till användningsfall. Här har naturligtvis verksamheten koll och du kommer att översvämmas av förslag. Jag kan garantera att om du tar med alla tänkbara användningsfall som verksamheten vill ta med och skall mäta dessa så kommer notan att bli dyr och du kommer att få mycket svårt att genomföra hela prestandatesten.
Alltså välj ut ett till tre användningsfall som till delar uppfyller kriterierna :
- går relativt djupt i infrastrukturen,
- används ofta
- inte har för många steg
Exempel på ett användningsfalls steg kan vara :
- steg 1,logga in,
- steg 2, sök på status på mitt ärende,
- steg 3, logga ut.
Andra momentet är att omsätta ”Klara av ” till mätbara mål, exempelvis får svarstiden i 98 procent av stegen aldrig överstiga 3 sekunder och svarstiden får aldrig vara över 10 sekunder.
Tredje momentet är att få koll på hur många ggr per dag dessa 5000 kommer att utföra användningsfallet som nämns i moment 1. Samtidighet mäts alltid i termen tid, i detta fall så definierar vi samtidigheten under kontorstid kl 09 00 – 17 00.
Vi antager att dessa 5000 samtidiga användare under 8 timmar utför ett användningsfall. Belastningen blir per sekund 5000 * 1/(8* 3600) = 0,17 användningsfall.
Denna strikt matematiska modell utgår ifrån det perfekta med jämn belastning över dagens alla minuter och så är ju inte fallet i verkligheten. Vi tar oss igenom fortsatt resonemang i nästa moment.
Fjärde momentet är att få koll hur stor belastningen är under de mest intensiva timmarna, minuterna sekunderna. Strikt matematiskt så kan naturligtvis samtliga 5000 under samma sekund försöka utföra användningsfallet, sannolikheten är dock så liten att vi inte räknar med det. Nu kommer resonemanget med verksamheten
Under vilken eller vilka timmar används applikationen ?
- Finns det volymmätningar, exempelvis från webbloggarna, när trafiken är som intensivast
Exempelvis kommer vi fram till att de mest intensiva timmarna är mellan 10 – 11 och 14-15 och att 70 procent av användarna utför sitt användningsfall vid dessa 2 timmar. Efter dessa siffror blir belastningen 0,70*5000*1/(2*3600) = 0,49 användningsfall per sekund.
Det blir troligen inte här heller någon jämn belastning varje minut och sekund. Genom att multiplicera belastningen med 4 så får vi den värsta sekunden under denna timme. (denna siffra härrör sig approximativt från poisonfördelningen, jag förklarar detta en annan gång)
Vi får en belastning på 4 * 0,49 , ca 2 användningsfall per sekund.
Nu har vi omsatt verksamhetens mål till mätbara mål.
Genom dessa fyra moment har vi alltså brutet ner verksamhetens mål till mätbara mål , 5000 samtidiga användare genererar en last på 2 användningsfall per sekund och svarstiden för de enskilda stegen i användningsfallet får inte överstiga 3 sekunder i 98 procent av fallen.
Vi har dokumenterat vårt resonemang, stämt av med verksamheten, nu finns det bra förutsättningar att utföra en prestandatest.
