Christian Gerdes

Om Christian Gerdes

Grundare och Vice VD för Lights In Line, har bl.a. följande bakrund: "Jag har jobbat med IT och Operations sedan 1997 då jag började på Ericsson med management system för telekomnätverk. Min bakgrund är både från utveckling, tekniskt projektledning och systemadministration och har sedan 2000 jobbat uteslutande med prestanda optimering och teknisk kvalitetssäkring. Jag drivs av att kontinuerligt förbättra processer, metoder och arbetssätt inom det som idag kallas Performance Engineering, och jag håller även en hel del föreläsningar, workshops och utbildningar i ämnet".

Prestandatest av Swedbank Mobilbanken 3.0

Senaste uppdateringen för HP Loadrunner 11, kallad Patch 4, innehåller lite godis för oss som testar de nya Web 2.0 sajterna. Bland annat stöd för både GWT och JSON REST applikationer i web protokollet med hjälp av den nya DFE tekniken (Data Format Extensions), nya mobila protokoll och stöd för inspelning direkt på nätverket, nya funktioner i Ajax TruClient, stöd för de senaste webbläsarna och mycket mer.

LIL har haft möjligheten i ett av de senaste projekt på Swedbank att dra nytta av dessa funktioner när vi prestandatestade den nya Mobilbanken 3.0. Vi gjorde även en presentation om projektet och hur vi nyttjade dessa nya tekniker i Loadrunner för HUGS (HP User Group Sweden) för två veckor sedan, vilken var mycket uppskattad. Vi kommer även att hålla den internt för Skatteverket idag under deras prestandatestdag och du kan nu även ta del av den här genom att ladda ner den här;

Länk till presentationen
Prestandatest Mobilbanken 3.0

Microsoft Load Testing Virtual Lab

Microsoft har släppt ett nytt sätt att komma igång med testverktygen i Visual Studio. Du får tillgång till en komplett förinstallerad server i Azure molnet, nyuppstartad bara för dig. Du har tillgång till maskinen via en webbaserad remote desktop session i upp till 3 timmar. En guide startar upp automatiskt som leder dig igenom de olika stegen för att göra prestandatester om du vill, eller så utforskar du verktyget helt på egen hand. Komplett med test applikation och testdata, och du kan prova på allt från manuella tester, GUI tester och prestanda tester samt ASP.NET Profilering under belastning.

Helt klart det smidigaste sättet hittills att testa en ny produkt på eller bara snabbt testa av något i en egen virtuell maskin. Även klockren för utbildningar! Jo, helt kostnadsfritt dessutom!

Följ länken nedan för att få en egen maskin.

http://go.microsoft.com/?linkid=9762338

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.

Nytt utseende, samma goda själ

Idag går LIGHTS IN LINE AB igång med en helt ny fräsch sajt. Då vi är väldigt agila som företag kan du vänta dig att den kommer ändras en hel del närmaste tiden framöver. Och troligtvis blir vi aldrig klara med den heller. Precis som det sig bör 🙂