En viktig framgångsfaktor vid genomförande av prestandatest är förberedelserna inför testerna. Oftast är det kort kalendertid mellan beställning och önskat genomförande. Vissa processer, som exempelvis beställning av testdata, evt vpn-inloggningar, korrigeringar i brandväggar, identifiera nyckelpersonal som kan nätverket etc etc, tar viss kalendertid att klara av.

Vi på Lights In Line AB utför hundratals prestandatester årligen och har tagit fram ett dokument , Prestandatest förberedelser,  som vi ofta använder som mall i dialogen med uppdragsgivaren av prestandatestet.

Låt oss göra en resa tillbaka för ca 400 år sedan och se vad som hänt OM regalskeppet Wasa hade prestandatestats.

Landets Industriella Lastämbete, kallat LIL, hade tagit kontakt med Gustav  II och föreslagit en prestanda och stabilitetstest  av skeppet innan jungfrufärden.

Gustav var till en början skeptisk till förslaget, alla hans experter/konstruktörer bedyrade att man hade koll på läget och att tester skulle försinka sjösättningen,  men efter ett par dagars diskussioner med sina skeppsbyggare/ övriga båtvarv så beordrade han en prestandatest, argumenten var bl.a. :

•  Visserligen skulle det kosta lite mer i början, men det skulle sättas i relation till kostnad/prestigeförlust om Wasa sjösattes och därefter sjönk.

•  Ju tidigare man upptäckte några defekter desto billigare att åtgärda.

•  Den skeppsmodell som måste byggas skulle efterlikna det riktiga skeppet Wasa så mycket som möjligt

•  Gustav kunde få relativt säkra indikationer på hur ändringarna skulle påverka  Wasas sjöegenskaper, detta genom att först utföra ändringarna på skeppsmodellen.

Sagt och gjort, LIL hade alltså från högsta håll fått rollen att utföra prestandatester och när Gustav ville se konsekvenserna av att bygga ut med  flera kanonrader så utfördes denna simulering först på skeppsmodellen.

Resultatet av prestandatesterna  visade under  kapitel sammanfattning,  att konsekvenserna av denna ändring skulle innebära att skeppet skulle kantra för vindstyrkor över 10 meter/sekund. Gustav, som bara orkade läsa denna sammanfattning, kallade genast in sina egna experter som granskade den tekniska delen i rapporten.

Man fann testerna, som utförts för skeppsmodellen, bra dokumenterade och att det enligt framräknade siffror skulle stämma att skeppet skulle kantra.

I rapporten stod det också, att om Gustav ville ha den där extra kanonraden, så rekommenderade LIL att kölsvinet skulle göras djupare för att bereda plats för 40 ton extra bly och därmed höja stabiliteten.

Beslut togs att dessa ändringar först skulle utföras i på skeppsmodellen och därefter testas.

Efter ett par dagar hade tester utförts och i kompletterande prestandarapport stod det att nu var det ingen risk att skeppet skull kantra men prestanda var bedrövlig, farten i båten var ca 6 sekunder för 10m. Om Gustav önskade prestanda 2 sekunder för 10m så krävdes en uppgradering av segelytan med 20% kvadratmeter extra segel.

Gustav beordrade skeppsbyggarna att följa rekommendationerna i rapporten och skeppet sjösattes. Vid stabilitetstesten (30 personer sprang fram och tillbaka tvärskepps) så visade det sig att skeppet ändå var instabilt.

Hur kunde detta vara möjligt, man hade ju följt rekommendationerna från rapporten?

Efter många dagars letande så kom man på orsaken. Man hade enbart lagt 10 ton bly i kölsvinet istället för stipulerade 40 ton. Orsaken till denna fadäs var stressen på hela byggteamet, man hade helt enkelt glömt bort det!

När blyet väl hade kommit på plats riggades fartyget och jungfrufärden ut igenom Stockholm blev en stor triumf. Skeppet Wasa var i kronans tjänst i många år och var väldigt framgångsrikt i de stora sjöslagen.

Gustav var mycket nöjd och införde konceptet prestandatest på alla båtar som byggdes av kronan.

- – - – - – - – - – - – - – - – - -

Idag händer det att webbplatser sjösätts och kantar vid många besök.

Kontakta Lights In Line och vi kan hjälpa dig med prestandatest av din webbplats.

Inledning.

SLA (service level agreement) är ofta med som paragraf i avtal mellan leverantör och kund avseende leverans av IT-tjänster.

Men hur ofta går man igenom i avtalet och kollar hur väl det uppfylls?, Och hur många gånger är leverantören och kunden överens om vad som skall mätas och vad stipulerade siffror står för? Och vem skall mäta detta, leverantören?

Med rätt metodik och processer genererar en SLA överenskommelse/avtal att leverantören och kunden under avtalets gång har full koll på hur pass väl leverantören uppfyller avtalet/överenskommelsen.

Metodiken.

Här beskrivs en väl beprövad metodik som vi på Lights In Line AB hjälper våra kunder att komma igång med.

• Överenskommelse och beskrivning av processerna
• Avtal mellan kund och leverantör
• Processen uppföljning

Överenskommelse och beskrivning.

I detta dokument beskrivs vilka processer som behövs för att exempelvis kunna mäta svarstider och tillgänglighet på IT-systemet. Beskrivning av när prestandatest skall ske och vilka parametrar som skall användas. Se vidare LIL SLA Exempel överenskommelse processerna.

I LIL SLA Processerna visas processerna översiktligt.

Avtal mellan kund och leverantör.

När kunden och leverantören är överens om vad som förväntas av respektive part är det dags att skriva avtalet och exempel på ett sådant är LIL SLA Exempel avtal.

Processen uppföljning.

I denna process följs resultaten av mätningarna i produktion upp. Genom exempelvis en månatlig sammanställning och genomgång av denna så blir det en kontinuitet i kollen på att utlovad SLA levereras. Se LIL SLA uppföljning.

Sammanfattning.

Vi på Lights In Line har sedan många år tillbaka haft förmånen att hjälpa våra kunder med att införa denna metodik och resultatet har blivit högre tillgänglighet på IT-tjänsterna.

Kontakta oss gärna för referenser.

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.

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.