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.
