Prestandatest kan spara enorma summor pengar

Många tänker nog att syftet med prestandatester är som mycket annat inom test, validera krav och säkerställa att applikationen presterar som det kommer förväntas av den. Och visst är det så, prestandatester ger en trygghet att veta och inhämta kunskap om hur en applikation kommer att bete sig under belastning av många besökare eller användare, samt att infrastrukturens kapacitet räcker till.

Men lika mycket nytta gör prestandatest när den används för optimering och kapacitetsplanering. Relativt nyligen gjorde en av våra största kunder en större resa där infrastrukturen byttes ut avseende processorarkitektur, man gick från SPARC baserad teknologi till Intel x86 på samtliga servrar. I samband med detta gjordes såklart noggranna prestandatester för att validera att den nya infrastrukturen inte presterade sämre än den förra, och förhoppningen var dessutom att mäta upp en förbättring avseende prestanda.

Resultaten av de initiala testerna visade på en potential att ytterligare förbättra prestandan  genom optimering av konfigurationen för applikationsservern, avseende antal processer, trådar och minneskonfiguration per virtuell maskin. Lights In Line rekommenderade därför fler tester efter att det var bekräftat att den nya infrastrukturen höll måttet, med syfte att hitta den optimala konfigurationen. Efter ytterligare 1 veckas intensiva tester av alternativa konfigurationer, hittade vi en som gav maximal prestanda och utnyttjade kapaciteten optimalt, med resultatet att antalet fysiska maskiner i klustret kunde halveras med bibehållen kapacitet och prestanda av applikationen.

Förutom den skära kostnadsbesparingen av antalet fysiska servrar i datahallen, kunde vi påvisa en enorm besparing avseende licenser, förvaltning och underhållskostnader, på närmare 2 miljoner kronor för denna kund, per år. Inte nog med det, men på grund av det mindre antal servrar blev bonus effekten att tiden det tar att göra en ny deploy av koden även minskades vid varje release.

Performance Engineering är inte ett nytt ord för prestandatester. Det är konsten att optimera och förvalta applikationer och tjänsters tillgänglighet, prestanda och kapacitetsutnyttjande, men även att effektivisera processerna runtomkring, i hela lifscykeln.

Är det dyrt att prestandatesta webbplatser eller applikationer ?

Prestandatester kan jämföras som försäkringspremier. Om din villas tak  inte håller för stormen och den inte är försäkrad så torde försäkringspremien vara billig i jämförelse med skadorna på villan. Om din webbplats inte håller för en anstormning av besökare så är kostnaden för prestandatest INNAN anstormningen troligtvis billig …..

Att prestandatesta alla webbplatser i samma omfång och samma ambitioner gör att det kan bli både dyrt och tragiskt. Om holländarna inte genomför omfångsrika provtryckningar på sina vallar så kan det bli tragiskt för invånarna. Därför är provtryckningarna av vallarna i Holland billiga även om dom kostar miljoner per år. Om regalskeppet Wasa hade testats (alltså genomförd stabilitetstest och analys hade det troligen medfört  mera barlast i kölsvinet och därmed mindre krängning) så hade det varit tragiskt för Polen.

Därför så sätter vi på Lights In Line oss alltid in i kundens situation och ambition innan vi kommer med ett förslag på prestandatest. Vi resonerar med kunden, hur mycket värt är det att webbplatsen/applikationen håller för anstormningen och lämnar därför rätt pris i förhållande till vad kunden vill uppnå. Det händer ofta att kunden vill utföra omfångsrika prestandatester och vi säger ”börja i liten skala först”, utvärdera därefter och återkom.

Genom att vi dessutom levererar prestandatesten som en tjänst vet kunden alltid slutpriset, lika självklart som att köpa ett tak till sitt hus till fast pris.

Hemligheten med att ha fast pris som dessutom är billigt är väldigt enkelt. Många av oss på Lights In Line  har hållit på med prestandatester i över 20 år och vet vad som kan vara fördyrande, exempelvis :

-Hyr in en konsult låt oss säga i 6 månader för prestandatest heltid, i de flesta fall är över 50  procent väntan, vem betalar 🙁

-Ha stora ambitioner och man testar så mycket att verksamheten inte kan ta åt sig resultatet, om man kommer i mål 🙁

Samma prestandatestare hos oss kan från vårt kontor vara prestandatestare åt flera kunder samtidigt och genom att alltid ha minst 2 medarbetare på varje kund har vi redundans, våra medarbetare kan bli sjuka och dom får ta semester 🙂

Prestandatest av din webbplats eller applikation och att ha koll på tillgängligheten är vår passion, kontakta Bosse på 070-5940948 eller Christian på 070-2209828.

 

Prestandatest rapport

 

.
Bakgrund

Under de senaste 15 åren har jag deltagit i ett antal prestandatester och frapperats av den skiftande kvalitén rörande de skriftliga rapporterna av testernas resultat.

Prestandatestare har olika fallenhet för framställan av en prestandatestrapport, detta kan vi inte ändra på.
Min erfarenhet är dock att själva slutrapporten av prestandatesterna i många fall kan förbättras med mycket små medel, se längre ned ”De tio budorden vid framtagning av prestandatestrapport”.

Jag har inte föreslagit en exakt mall om de olika avsnitten i en prestandarapport, här är det de olika omständigheterna som spelar in. Exempelvis är det skillnad på en rapport som tas fram för applikationer som prestandatestas kontinuerligt varje månad jämfört med en applikation som efter flera månaders utvecklingsarbete skall prestandatestas.

En gammal kollega inom prestandatestområdet menade att om du efter ett dygn efter rapportens framställande öppnar den och upplever ljuv musik när du läser den, då vet du att mottagaren kommer att få en bra rapport.

Och visst är det så, du ger något till din uppdragsgivare och vet att han/hon kommer att uppskatta rapporten, det kallas yrkesstolthet.

Likheter mellan besiktningsprotokoll av bilar och rapport för prestandatester.

Vissa likheter finns i framtagningen av en besiktningsrapport och prestandatestrapport.

•    Du vill genom kontroll, ok det är lagstadgat :), få reda på konditionen på    din bil.
•    Resultaten är baserade på ett antal tester av de verktyg besiktningsmannen förfogar över.
•    Analysen av resultaten är besiktningsprotokollet.
•    Sammanfattningen, som är muntlig och skriftlig, utgörs av en noggrann skala allt från körförbud till inga anmärkningar.

•    Visst finns det olikheter, rekommendation är väl snarast ersatt med direktiv, exempelvis är körförbud ingen rekommendation utan snarast att betrakta som ett verkställande direktiv :).

De tio budorden vid framtagning av prestandatestrapport

1. Dela upp i tre delar, sammanfattning, analysen av testerna, resultaten av testerna, förklara uppdelningen.

Kommentarer: Förklara i början av rapporten att den är uppdelad på detta sätt. Resultaten av testerna tillsammans med dagbok/kommentarer till testerna finns i kapitlet resultatet av testerna. Analysen, här är det egentliga arbetet att tyda siffrorna från de olika mätarna. Sammanfattningen, här tas resultatet från analysen och jämförs med uppdragsbeskrivningen/målet med prestandatesterna. Observera att det naturligtvis finns flera kapitel i prestandatestrapport, exempelvis avgränsningar, prestandamål, etc. etc.

2. Sammanfattningens resultat skall kunna refereras till vilka analyser som gjordes och som i sin tur till refererar till resultaten av testerna.

Kommentar: Tangerar mycket punkt 1, det skall poängteras att det inte får finnas några lösa referenser. Allt material i rapporten har syfte att vara underlag för sammanfattningen och rekommendation.

3. Resultat i form av grafer/ eller tabeller läggs i kapitlet resultat av testerna.

Kommentar: Om det är en tabell/graf som är oerhört viktig för rekommendationen, lägg en direkt referens till denna och kommentera.

4. Fokusera alltid på uppdragsbeskrivningen, dvs. vad är det uppdragsgivaren vill ha svar på.

Kommentar: Det händer att uppdragsgivaren har angivet exakt vad prestandamålen är, men i de flesta fall ligger snarare uppdragsbeskrivningen att exempelvis ”applikationen skall klara av dagens trafik på webben”. Då är det viktigt att i uppdraget ange på vad detta innebär i prestandamål, detta görs med fördel tillsammans med uppdragsgivaren.

5. En rekommendation skall alltid göras, oavsett storleken på uppdraget.

Kommentar: Du kan och skall alltid ange en rekommendation, jfr med bilprovningen om besiktningsmannen skulle säga jag vet inte…, du har betalat för testen och vet inte vad rekommendationen är .. Däremot kan en rekommendation alltid vara med vissa förbehåll. Jfr med bilprovningen, ”din bil blev godkänd, men det är värt att notera visst glapp i övre styrleden höger sida som du bör åtgärda närmaste tiden”.

6. Stavfel och uppenbar dålig svenska, skall och kan undvikas.

Kommentar; Det är ju uppenbart, en slarvig hopsatt prestandatestrapport ger ett intryck av att kanske testerna också var slarviga. En prestandatestrapport, skall kunna läsas av både tekniker och beslutsfattare som inte är tekniskt lagda. Det finns bra stavningsprogram och lämna gärna till en kollega som får läsa igenom rapporten.

7. Underlaget till prestandatestrapporten består naturligtvis av dokumenterade resultat med kommentarer.

Kommentar: Kanske helt självklart, men ibland dokumenterar vi inte händelser i rapporten, vi tycker att den händelsen visste ju alla om. Och så kommer det direkt i sammanfattningen utan att vi förklarat att just dessa siffror berodde på …

8. Om du vill berätta att det var mycket omkörningar, berätta inte detta genom att ta med diagram som är oväsentliga för resultaten.

Kommentar: Det är inte ovanligt att man efter ett antal prestandatester av olika anledningar finner att testerna utfördes under felaktiga förutsättningar, ex du var inte ensam i målmiljön. Det enda riktiga är att göra om dessa, ta då inte med resultaten av de felaktiga testerna i rapporten. Nämn detta dock i analysen, och ev. även i sammanfattningen.

9. Förklara innebörden i de begrepp du använder.

Kommentar: Allt sedan prestandatester började bli vanliga för IT-system använder prestandatestare ibland olika namn på samma begrepp. Innan vi inom prestandatestsfären fått en sådan ”begreppskalender”, skriv vad du menar med de olika begreppen, använd med fördel referens till en  bilaga av begrepp i din rapport.

10. Blanda inte begreppen, använd samma enheter i rapporten.

Kommentar: Det är lätt hänt att man som prestandatestare blir ”hemmablind” och använder olika namn på samma sak. För den som skall läsa rapporten skapar det onödig förvirring och drar ner betyget.

Samla in svarstider från användarens webbläsare

Det finns i dagsläget många sätt att samla in svarstider för en webbsajt eller webbapplikation. Allt från enkelt och billigt till avancerat och extremt dyrt. En av utmaningarna har även varit att det finns lika många sätt att mäta svarstider på som det finns produkter och tjänster som utför detta.

Först lite bakgrund;

Man kan grovt dela in alla dessa olika sätt att mäta svarstider på i 2 kategorier; Det ena är aktiv mätning, i form av virtuella användare som besöker sajten eller applikationen enligt ett förutbestämt sätt (en testautomatisering). Det andra är passiv mätning, som istället analyserar den trafik och de besök och transaktioner som riktiga användare utför.

Aktiv mätning är ett mycket kraftfullt och enkelt sätt att mäta svarstider och prestanda på i en produktionsmiljö, dels kan vi mäta på exakt samma sätt i drift som vi gjorde under prestandatester (och därmed återanvända skript och jämföra mot resultat), dels kan vi mäta exakt så som vi vill i form av transaktioner och mätpunkter, och vi mäter med regelbundna intervaller vilket underlättar analysen och ger ett jämnt statistiskt underlag. Andra fördelar är att vi kan spara undan snapshots av fel, stacktracar och felmeddelanden och tom hela screenshots (eftersom vi utför tester med förväntade resultat) och spara undan värdefull information och testdata som kan skickas med i larm och felmeddelanden till driftpersonal för att de så snabbt som möjligt kan återskapa felet och åtgärda problemet. Detta är vad tex vår E2E Light tjänst gör.
Det finns dock några nackdelar, vi måste tex ha testdata eller testpersoner i driftmiljön, vilket inte är möjligt för alla. Andra nackdelar när det gäller att mäta prestanda ur ett användarperspektiv, är att vi mäter från ett fåtal punkter och alltid på samma sätt, medan de riktiga besökarna kommer från tusentals olika platser, med många olika förutsättningar som webbläsare, operativsystem, nätverk, enheter mm. En annan nackdel är just testautomatiseringen, vi måste i förväg skapa ett beteende som vi mäter. Vi begränsas av ekonomiska- och tids- skäl till att inte kunna testautomatisera allting som går att göra på en sajt, och dessutom ändrar besökarna eller användarna sitt beteende oftare än sällan.

Passiv mätning har traditionellt varit en större utmaning, och det har till stor del varit på tekniska grunder. Informationen som funnits tillgänglig utan att skapa förutsättningar för detta har fram tills idag endast varit loggar och mätvärden som operativsystem och infrastruktur ger (i form av performance counters och accessloggar). Det finns några olika angreppssätt, där produkter analyserar loggar, nätverkstrafik och vissa produkter t.o.m. kopplar in sig i applikationens kod (en form av profilering) vilket är möjligt på tex .NET eller Java baserade lösningar. Men den stora utmaningen har varit att mappa tillbaks denna information till användarnas beteenden, dvs till en funktion som utförs av en användare, eller under vilka förutsättningar som tex felen inträffar.
Passiv mätning har dock en större potential än aktiv mätning, just för att den potentiellt kan mäta allt som sker på sajten och kan även mäta själva beteendet av användarna på sajten. Vissa applikationer som utvecklas har dock välsignats med en arkitekt som tänkt på detta i förväg, och som skapar en mätbar applikation, som loggar eller tillhandahåller mätvärden som visar hur många användare som gör vad, hur lång tid det tar och hur ofta vad går fel. Har man dessutom valt att publicera denna data med ett standardiserat sätt, som Performance Counters, WMI, JMX, SNMP eller något annat API, finns det flertalet övervakningslösningar som kan samla in och trendanalysera detta. Alla dessa alternativ kan även användas under prestandatester för att mäta och analysera detta proaktivt innan drift.

På senare tid har passiv mätning även förflyttats till klienterna, för att kunna mäta beteendet av användarna på sajten. Detta har gjorts mycket enkelt att införa på webbapplikationer i form av internetbaserade tjänster som tar emot statistiken och trendanalyserar denna. Detta är tjänster som tex Google Analytics, WebTrends och WebTuna. Utmaningen som dessa har haft är dock att det är relativt lätt att mäta beteendet, dvs vad en besökare gör, men mycket svårare att mäta svarstiden. Ännu svårare är det att mäta vad som går fel eller hur ofta något går fel eller slutat att fungera, eftersom dessa tjänster inte känner till det förväntade korrekta svaret och heller inte sparar det svar användaren fick. Det man ser i dessa verktyg är att lasten minskar och vet man med sig att den borde vara högre kan man misstänka att något slutat fungera. Inte bra. Det är nämligen ofta så, att fungerar inte en sida eller sajten, slås den passiva mätfunktionen ofta ut helt och hållet, eftersom den baserar sig på kod och information som finns i svaret från servern. Man kan möjligen se att lasten på felsidorna ökar, om sajten är konstruerad att skicka användaren till en sådan. Men det är om.
När det gäller svarstider för att mäta prestanda har några försök gjorts genom att mäta detta på olika sätt med hjälp av javascript, men det har gett tvivelaktiga och varierande resultat, främst då för att de endast kan mäta en del av renderingstiden, vilket visar tiden att ladda ner sidan samt alla dess delar, som reklam mm. För att kunna analysera ett prestandaproblem i drift, behöver man kunna bryta ner svarstiden för tex DNS, Connect, Response och Network time, så som man även gör under prestandatester eller vid aktiv mätning (se ovan).

Den nya världen

Vad som har hänt nyligen, och som denna artikel egentligen handlar om (efter mycket bakgrundsinformation) är en ny standard i webbläsarna att mäta och tillhandahålla svarstidsinformation i DOM’en. Detta håller på standardiseras av W3C under den s.k. Navigation Timing Specification. Kort och gått specifierar denna att och hur webbläsare ska mäta svarstider för nedladdade sidor (ej individuella resurser) samt hur den ska vara tillgänglig. Det innebär att vem som hellst med ett litet javascript på sidan kan börja mäta svarstiderna som varje användare får, allt från DNS tiden, till anslutningstiden till servern, serverns svarstid samt tiden det tar att ladda sidan över nätverket, tills den slutligen är renderad och klar med alla ingående resurser (som bilder, stylesheets och inlänkad reklam). Denna information använder dels webbläsarna själva, och man kan se den i grafisk form genom de inbyggda utvecklarverktygen som finns. De stora webbläsarna följer redan denna standard (Internet Explorer 9, Firefox 7 och Chrome 6).

Bilden ovan visar ett exempel av hur mätvärdena kan visas i grafisk form av ett javascript på en sida. Bilden kommer från Webtiming Demo på Appspot, vilken i realtid visar vilken svarstid du fick när du besökte sidan och bryter ner den i en bild som ovan. Utan att gräva ner sig djupare i vad man kan göra själv med hjälp av dessa nya tekniker så finns det redan ett par trendanalysverktyg på marknaden som använder denna information från webbläsarna, först ut var WebTuna och snart följde Google Analytics efter, samt har Piwik det i sin roadmap för version 1.8. Om du använder Googles tjänst, hittar du efter inloggning numera en sektion i portalen som heter Site Speed där denna information visas;

Bilden ovan är tagen för en medelstor webbplats i sverige och visar dels Site Speed värdet för Avg. Page download time per dygn senaste månaden samt i samma graf även antalet Page Views för samma dygn. Tabellen nedanför grafen visar samtliga mätvärden för de mest besökta sidorna på sajten (jag klippte endast med de första två). Man ser tydligt i statistiken vilken skillnad det är i page load time versus tex Server response time samt Download time (vilket är de tider som påverkas av prestandan på webbsajten) medans den totala tiden att ladda sidan (Avg Page Load Time) till stor del påverkas av klientens och användarens val av dator, internetanslutning, plugins i webbläsare mm. Grafen i detta fall visar även att svarstiden från servrarna inte påverkas av lasten i form av page views, vilket beror på att på denna sajt har vi hjälpt kunden att sätta upp en webbaccelerator framför webbsidorna (Varnish Webcache). Det är även anledningen till de mycket låga svarstiderna (Connect samt Server Response Time).

Summa summarum, det har hänt en del avseende tekniken för att mäta just svarstider. Den bästa övervakningslösningen kombinerar så klart dessa två element av både aktiv mätning och övervakning för att mäta prestanda samt tillgängligheten på webbsidan, samt passiv mätning för att mäta och trendanalysera beteenden och användarupplevda svarstider. Om denna artikel gjorde dig nyfiken och du vill veta mer eller ha hjälp att komma igång med E2E mätningar, hör av dig till oss så bjuder vi på en god kopp kaffe eller en lunch på vårt kontor samt en inspirerande diskussion 🙂

Skicka ett mail till kontakt@lightsinline.se eller se alternativa kontaktvägar här.

Att prestandatesta en webbsajt

En av utmaningarna med prestandatester av webbsidor är bland mycket annat att korrekt simulera besökarnas beteenden. Inom prestandatest kallar man detta för scenarion och skript, men det är egentligen en anpassad form av testautomatisering. Ett verktyg som utför ett (eller ofta flera) fördefinierat test används för att med automatik enligt ett visst mönster och beteende besöka en webbsida eller en webbapplikation och utföra ett antal moment, som valideras för dess funktionalitet, samt för syftet av prestandatester, mäter vi svarstiden för hur lång tid det tar att utföra dessa moment.

Men till skillnad mot testautomatisering med syfte att validera funktionerna på webbplatsen är syftet under prestandatester att på något sätt simulera riktiga besökare, och här blir det ofta lite klurigt. För vad gör de riktiga besökarna på webbsidan egentligen?

Här kan man nyttja dels de analysverktyg som finns tillgängliga, som tex genom att analysera webbserverns access loggar. I dessa loggas vad varje användare har hämtat ner för resurser från vår webbserver. Men för att få ut nånting vettigt av dessa, som svarstider eller i vilken ordning vilka sidor besöks oftast, måste vi slå på ganska mycket extra loggning vilket i sin tur kan slöa ner webbservern, då det kostar en del CPU och disk IO att logga allt detta. Som alternativ finns då några gratis tjänster på nätet man kan använda, som via ett enkelt litet javascipt loggar besökarnas trender till ett separat webbsystem. Google Analytics är ett exempel på dessa.

Men prestandatester vill man ju göra innan man går live med en ny sajt, så vad får man ut av detta då? Man kan ju önska att alla som redan är i drift med sina sajter kunde dela med sig lite av sin statistik. Just detta försöker Google åstadkomma. Jag fick nyligen en första rapport av Google, där de även hade jämfört trenderna för 2010 och 2011, vilket pekar på några intressanta resultat;

2010 2011 Diff
Pages/Visit 4,9 4,5 -0,4
Bounce Rate 48.2% 47.0% -1,20%
Avg. Time on Site 05:49 05:23 -0:26
Think Time (s) 71,22 71,77 0,55

Tabellen visar några intressanta mätvärden som vi har nytta av under prestandatester av en sajt vilka vi får från statistikverktyget. En första anblick säger att skillnaden mellan just 2010 och 2011 inte är så stora, och det ger lite mera tyngd för att kunna använda dessa data som en form av baseline för andra sajter. Värdena ovan är genomsnitt för alla sajter på Google Analytics vilka deltar i Shared Data programmet (ett antal hundra tusen i dagsläget).

De första 3 värderna kommer direkt från Google Analytics och det fjärde, Think Time har vi räknat fram genom att dela totala tiden på sajten med antalet sidor som har besökts.

Det första värdet Pages per visit visar i snitt hur många sidbesök vi bör genomföra per iteration av ett skript under våra tester. Det andra, Bounce Rate visar hur ofta en besökare endast laddar ner en enda sida (oftast en artikel eller startsidan) och sedan lämnar sajten.  Detta inträffar mer frekvent på sajter som låter sig indexeras, och är oftast ett besök på endast startsidan, men kan även vara en besökare som hittat en sida som sökresultat på tex Google eller Bing och läser endast den hittade sidan. En bounce är mycket tyngre i det avseendet att det ofta leder till en så kallad complete page download (inget är cachat i webbläsaren) samt att det i vissa fall kan vara en slumpmässig vald sida eller artikel på sajten (dvs webservern har den troligen inte i sin cache heller utan måste läsa från disk). Detta mäts såklart också under så kallad ”Referrer statistics” där vi ser hur besökare hittar till sajten. ”Direct” innebär att de mer eller mindre knappade in adressen i webbläsaren eller har ett bokmärke och därmed hamnar troligen på startsidan. Kommer de däremot från Google eller Bing är det via en sökning.

Dessa olika beteenden simulerar man enklast med 2 olika skript, det ena som simulerar bounce rate (tex startsidan och/eller 1 slumpmässig sida) och det andra som simulerar i snitt 4,5 sidbesök. Enligt statistiken ovan för 2011 ska då alltså cirka 47% köra vårt bounce rate skript och resterande vårt klicka runt skript (med i snitt 4,5 sidor). Hur besöker man då 0,5 sidor? Jo, varannan gång. Alternativt gör vi två skript av detta med, ett med 3 sidor och ett med 6 sidor som körs av lika många användare (3+6)/2 = 4,5.

Average Time on site samt framför allt Think Time är viktiga parametrar då dessa är nödvändiga att specifiera i ett prestandatest, då detta återspeglar den simulerade betänketiden som vi ska ha mellan klick eller sidbyten i ett skript. Självklart varierar detta rejält från besökare till besökare, och därför kan de flesta verktyg utföra en normalfördelning eller en slumpmässig variation på denna betänketid för att på så sätt även simulera spikar/toppar och dalar under testet.

Vi kan även använda denna betänketid för att transformera andra mätvärden som ett prestandatestverktyg samlar in. Tex mäter man ofta lasten som genereras under ett test i form av Sidor per sekund som laddas ner av virtuella användare. Om vi tex under ett test påvisar att en webbapplikation klarar som max 160 sidor per sekund innan tex nätverket eller CPU blir en flaskhals, kan vi alltså räkna fram ett besökarantal som skulle krävas för att generera denna last, nämligen 160 * betänketiden (vilket med snittvärdet för 2011 ovan innebär 11 483 samtidiga besökare).

72 sekunder betänketid kan tyckas vara en hög siffra, och denna varierar så klart från användare till användare (första gångs besökare, ovana och vana besökare mm) samt även sajtens struktur och design. Ju mer det finns att läsa och begrunda på en sida, ju högre blir betänketiden. En webbapplikation för aktiehandel eller en internetbank kommer tex att ha ett annat mönster (tex neråt 45-50 sekunder) än tex ett digitalt magasin eller en tidning.

Slutligen, nu när vi vet ungefär hur många besökare och hur ofta de gör något på en sajt, återstår att spegla vad de faktiskt tittar på eller gör på en sajt. Är sajten redan i drift eller kanske en äldre version av sajten är det, kan verktyg som Google Analytics såklart även visa hur ofta besökare gör vad på sajten. Det var det ursprungliga syftet med dessa verktyg. Har man inte tillgång till detta, kan man ändå använda genomsnitts statistik, som bounce rate ovan, för att bygga ett rimligt mönster. Det är inte ovanligt att startsidan på en sajt står för över hälften av alla sidbesök. För att sedan fylla på med ytterligare 3,5 klick (för att komma upp i 4,5) så får man leka lite beteendevetare, och titta på startsidan och bedömma vad som kan vara rimligt.

Avslutningsvist listar jag några alternativa produkter till Google Analytics;

WebTrends (http://webtrends.com/) är en av de marknadsledande produkterna som man kör helt och hållet själv, antingen direkt på webbservern eller på en separat server. Allt insamlat data behålls därmed in den egna infrastrukturen. Banker, försäkringsbolag och statliga myndigheter använder ofta en sådan lösning då den även har mycket kraftfulla funktioner för att kunna anpassas till sin egna webbapplikation, för att tex mäta User Stories eller Användningsfall istället för endast sidorna.

Ett opensource alternativ till WebTrends och Google Analytics är Piwik (http://piwik.org/) vilken man liksom WebTrends driftar själv och har därmed full tillgång till datat och integrationer men även källkoden för att kunna göra anpassningar.

Slutligen finns det även produkter som inte kräver en javascript kod på websidan (vilket de ovannämnda gör) utan ger sig på webbloggarna på servern istället. Några sådana är tex opensource baserade webalizer (http://www.mrunix.net/webalizer/) samt Windows programmet Web Log Expert (http://www.weblogexpert.com/) vilken även har bra stöd för att skapa egna filter och analyser av beteenden och de vanligaste flöden som besökare genomför.

Förutom dessa finns det en uppsjö av liknande produkter och färdiga tjänster på internet och många CMS leveratörer tillhandahåller även en egen anpassad sådan till sina produkter.

En av nyheterna i de nya webbläsarna (IE9 och FF9) är att javascript numera även kan komma åt svarstider, både DNS tid, nätverk, server svarstider samt renderingstider på ett standardiserat sätt. Några av de större analysverktygen som Google Analytics och WebTuna har redan börjat använda dessa mätvärden i sina tjänster. Men det förtjänar en egen artikel som kommer snart!

Uppdatering: Artikeln är nu skriven och heter Samla in svarstider från användarens webbläsare.

Prestandatest förberedelser faktainsamling

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.

Prestandatest av regalskeppet Wasa

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.

 

Prestandatest och SLA

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.

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.