Prestandatest och samtidiga användare.

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.

 

Prestandatester genom tiderna.

Bakgrund
Prestandatester på IT-system har utförts från sextiotalet och fram till nu. I början var maskinerna dyra och arbetskraften billig. Numera är maskinerna billiga och arbetskraften dyrare. Detta faktum samt den enorma explosionen av IT-system har förändrat prestandatesterna de senaste femtio åren.

Generation 1.
Under sextio- och sjuttiotalet utfördes prestandatester genom teoretiska kalkyler. Genom matematiska kalkyler, köteorier  och leverantörens uppgifter om tekniska data utfördes teoretiska simuleringar rörande prestanda. De första kommersiella testerna var atm –maskiner (bankomater). Detta var innan Internet, men plötsligt så skulle bankerna via uttagstransaktioner klara av x samtidiga uttag. Bensinbolagens automattankningar med tillhörande kredit/betalkort medförde också belastningar på bensinbolagen datorcenters.

Generation 2.
Tekniska Verifieringar av IT-system började utföras i större omfattning i slutet på åttiotalet. Testerna utfördes oftast av utvecklare som med hjälp av egentillverkade program kunde belasta IT-systemen med last och därefter räkna ut systemets prestanda. I början var det mest batchkörningar med tillhörande trimningar som var mest intressanta att utföra, det gällde att få ned  tiden för ”nattkörningarna” så att dessa var klara till kontorstid.

Generation 3.
När framför allt bankerna och försäkringsbolagen började öppna sig mot Internet i mitten på nittiotalet fanns på marknaden ett antal verktyg just anpassade för att utföra dessa prestandatester. I takt med att Internet och även Intranät växte insåg företagen hur viktigt det var att veta ett IT-systems prestanda innan det sjösattes.
Dedikerade prestandaenheter byggdes upp framför allt inom de större företagen.

 Generation 4.
Vi på Lights In Line har sedan 2005 infört tjänstebaserade prestandatester vilket innebär att kunden betalar ett fast pris för en given prestandatests omfattning. Hårdvara, mjukvara, uppsättning av prestandautrustning ingår, dessutom kan kunden välja om prestandautrustningen skall placeras hos våra prestandacenters på molnet eller i kundens egen Infrastruktur.

Genom denna valfrihet och standardiserade lösningar så :

  • Kan vi utföra tester åt flera kunder under samma tidsperiod, inga väntetider för våra prestandatestare.
  • Minimal ställkostnad per prestandatest
  • Vi väljer att utföra prestandatesten med de verktyg som vi anser vara lämpligast

För kunden innebär detta

  • Flexibilitet i val av omfång av prestandatest och avropar alltså en tjänst där kostnaden och uppnådd kvalitet är förutsägbar.
  • Fokus på verksamheten istället för att själv införskaffa verktyg och hårdvara.
  • Betalar inte för de timmar då prestandatestaren väntar på att kunden skall bli klar med testmiljö, eller andra specifikationer.