Rätt fokus vid prestandatester och övervakning av IT-system.

 

Vid övervakning och prestandatester av IT-system finns en tendens att först välja verktyg och sedan inleds processerna hur det skall användas i verksamheten.

Börja istället och ställ  frågorna:

1. Vilken ambitionsnivå skall vi ha på prestandatester, skall det göras vid varje release av ny kod eller infrastruktur, eller kanske bara när det anses nödvändigt?

2. Omfattningen på prestandatester, skall vi testa många användningsfall/scenarier eller koncentrera oss på få användningsfall?

3. Vilka kriterier skall vi ha för att prestandatestets resultat anses godkänt eller ej, eller inga?

4. Till vilken eller vilka skall resultatet av prestandatesterna presenteras, är det enbart till tekniker eller till verksamheten eller kanske till båda?

5. Vilken ambitionsnivå skall vi ha på övervakningsverktygen, skall vi mäta hur servrarna mår infrastrukturellt, skall vi mäta hur många som använder systemen och dess olika funktioner, skall vi mäta svarstider utifrån användarens perspektiv, eller allt?

6. Hur skall presentationen vara och till vem, skall vi skicka rapporter eller skall alla kunna gå in och ta ut rapporter, skall en ansvarig grupp samlas och någon som föredrar resultatet?

7. Vilken upplösningsnivå och nåbarhet skall det vara på resultaten i övervakningen?

8. Skall övervakningen baseras på uppmätta siffror i produktion (passiv övervakning) eller skall det vara aktiv övervakning (en robot simulerar en användare och genomför mätning med jämna mellanrum), eller skall vi ha båda?

9. Avser vi att ha långsiktlighet i processerna prestandatest och övervakning eller är detta något som vi avser att göra under en kort tid?

10. Vilka skall få larm om tröskelvärden överskrids vid övervakningen och hur skall larmen eskaleras.

11. Vill vi ha in resultatet av prestandatesterna och övervakningen i något SLA avtal (service level agreement) eller det är inte intressant?

12. Hur viktigt är det att IT-systemen fungerar och har godtagbara svarstider?

Ovan nämnda frågor renderar i att man bestämmer ambitionsnivån och även hur prestandamätning och övervakning blir en del i organisationen.

Observera att det finns ingenting som är rätt eller fel i ambitionsnivån på prestandatesterna/övervakningen, det viktiga är att du är medveten att ambitionsnivå/kostnad/bättre proaktivitet hänger ihop

Efter detta välj verktyg och välj också om du behöver extern part att hjälpa till eller om du klarar det själv.

Vi på Lights In Line har under många är byggt upp en erfarenhet inom områdena prestandatest, övervakning och framför allt hur kombinationen av dessa processers resultat kan bidraga till bättre koll på dina IT-system.

Kontakta oss så kan vi prata om det som vi brinner av på Lights In Line.

Bo Svensson

070-5940948

 

Prestandan på IT-system

Antingen det gäller applikatorisk övervakning (mäta svarstid/tillgänglighet utifrån användarens upplevelse) eller teknisk övervakning (mäta resursförbrukning på servrar, exempelvis cpu utnyttjande och minnesutnyttjande) så finns det stor förbättringspotential i presentationen av mätningarna och sättet att mäta hos många verktyg.

Under mina år som konsult inom kvalitetssäkring har jag upplevt några  klassiska scenarier:

  • ”Exempelvis systemet kraschar plötsligt och du sätter först nu in övervakning med exempelvis performance monitor. Du vet inte vilka parametrar som skall mätas och tar till i överkant och startar mätningen och orkar kanske hålla på en vecka, försöker analysera och hittar inget. Om vi tänker efter så inser vi att det är ju information före och under kraschen som är intressant i analysen så därför hittar vi vanligtvis inget.”
  • ”Ett annat scenario är att du har övervakning med något verktyg som visserligen mäter, låt oss säga var 5 minut. Men de flesta verktyg på marknaden konkatenerar ihop dessa data per timme och per dag för äldre data för att spara lagringsplats. Att förlora så mycket i upplösning medför svårigheter att analysera vissa mönster över tid. ”

Vi på Lights In Line gjorde en inventering på marknaden för några år sedan och såg att det inte fanns vettiga verktyg till vettiga priser att använda till övervakning.
Vi gick därför vår egen väg och har nu skapat tjänster för övervakning som är kostnadseffektiva, mäter kontinuerligt och lagras i databaser flera år tillbaka med en upplösningsnivå på 5 minuter. Eftersom datalagring bara blir billigare så bekymrar vi oss inte över datamängden. Vår långa erfarenhet av IT-systems resursbehov gör att vi frågar inte kunden vad som skall mätas utan föreslår istället vad som skall mätas utifrån den information vi får om kundens IT-system.
Vidare anpassar vi rapporteringen till kundens behov, vissa vill ha rapport (på pdf via epost) en gång per månad, andra vill ha rapport veckovis och själva kunna gå in i vår portal och analysera i online informationen. Andra kunder vill bara att vi kontaktar dom om det är problem, ja det finns ett flertal varianter. Naturligtvis finns larm vid olika tröskelvärden och som skickas via epost eller sms.
För att gå tillbaka till mina exempel i början:

  • Våra kunder har nu större chans med vårt verktyg att kunna analysera vad som hände/orsakade kraschen eftersom vi mäter kontinuerligt.
  • Våra kunder har nu större chans att över lång tidsaxel analysera vissa skeenden ner på en upplösning av 5 minuter.

Det är inte säkert att man lyckas knäcka vad som orsakade exempelvis kraschen, men sannolikheten har ökat. Jämför med andra dela inom industrin, exempelvis svarta lådan.
Vi berättar gärna mera om vårt sätt att paketera våra tjänster för övervakning som passar just dina behov.
bo.svensson@lightsinline.se eller ring 070-5940948

APM Verktyg och lättviktsprofilering med MEAM APM Insight

Bild Prestandaforum Stockholm 2013-10-09

Bild Prestandaforum Stockholm 2013-10-09

Igår höll vi en kortare föreläsning på Prestandaforum i Stockholm, denna gång sponsrat av Prolore och i deras lokaler. Föreläsningen gav lite insikter i Application Performance Monitoring (APM), varför det är ett hett ämne idag, en snabb översikt över fördelar och varför det behövs, några av de verktyg som finns på marknaden idag samt en presentation och demo av verktyget Manage Engine Applications Manager (MEAM) och dess lättviktsprofileringsmöjligheter i produktion och prestandatest, APM Insight.

Presentationsmaterialet hittar ni här: APM och MEAM APM Insight

Användaren anpassar inte sin webbläsare för din webbplats

Internet är fantastiskt, du tillverkar en webbplats, blogg eller applikation/tjänst och vips så kan tusentals individer ta del av detta.

Du har naturligtvis prestandatestat din webbplats /tjänst och vet att den klarar av flera samtidiga användare. Det är bra …..  🙂

MEN, du får ändå klagomål från vissa användare om att webbplatsen är långsam , man kan inte logga in etc etc.

Du kanske har ett program/robot som med jämna mellanrum kollar svarstiderna på din webbplats, det är bra ….  🙂

MEN informationen du får är att din webbplats fungerar och har acceptabla svarstider för en viss typ av webbläsare,  INTE att den fungerar för alla användare.

Förklaringen ligger i att användarna har ett antal kombinationer av datorer, surfplattor, smartphone operativsystem , webbläsare, samt olika inställningar till de sistnämnda.

Ovannämnda kombinationer i kombination med att du troligtvis ständigt uppdaterar din webbplats med nya tjänster/tredjepartsprodukter gör att vissa användare upplever webbplatsen som seg eller i värsta fall otillgänglig.

Men hav tröst, det finns metoder/verktyg tjänster numera som gör att du kan se svarstiderna utifrån användarens perspektiv. Detta i kombination med användarens webbläsare, typ av dator etc etc  gör att du får en bild av hur din webbplats uppfattas av användarna.

Och har du bilden så har du ett bra beslutsunderlag för eventuella förändringar på din webbplats till gagn för användarupplevelsen.

Vi på Lights In Line ställer naturligtvis upp och hjälper dig med metoderna och tjänsterna som behövs utifrån dina förutsättningar.

Vårt verktygsoberoende borgar för att du får tjänsterna/verktygen som är anpassat för dina behov.

Vill du veta mera om tekniken bakom de nya tjänsterna som nu kommer läs

https://www.lightsinline.se/samla-in-svarstider-fran-anvandaren/

Lights in Line håller koll på Bisnodes affärskritiska system

Bisnode_skärm

Ovan en bild på skärmen i Bisnodes operation center som visar status på alla monitorerna, de senaste larmen samt dagens tillgänglighet.

När man nämner företagsnamnet Bisnode så skakar nog de flesta på huvudet. Men när man blir klar över vilka tjänster som de faktiskt levererar är det dess fler som nickar igenkännande. I tjänstemenyn hittar man välbekanta produkter som till exempel kreditupplysningar och finansiell information från Soliditet och Dun & Bradstreet, adresser från PAR, CRM-system, pressreleaser, direktmarknadsföring, nyhetsbrev och mycket, mycket annat.

Det som en gång startade som Bonniers Affärsinformation har idag 4,3 miljarder i omsättning, 3000 anställda och verksamhet i 17 länder. Idag handlar Bisnodes verksamhet om avancerad informationshantering, vidareförädling och leverans i realtid. Företagets egen framtidsutsikt är att bli den ledande leverantören av affärsinformation i Europa och erbjuda de bästa produkterna och lösningarna. Sammanfattningsvis handlar det om att samla in data, sortera, aggregera och förpacka information som sedan levereras som en paketerad tjänst till kunden.

I en verksamhet som i stort sett enbart handlar om informationshantering är det givet att övervakning av tillgänglighet är A och O och det är här Lights In Line har kommit in i bilden och sedan 2006 har man jobbat tillsammans.

Bisnode_Sven_Täveby

Bisnodes Sven Täveby

Sven Täveby arbetar på Bisnodes interna IT-avdelning i Sundbyberg och ansvarar för övervakningen av de affärskritiska systemen.

”- Vi har jobbat ihop med Lights In Line ett bra tag nu och mitt intryck är att det är ett mycket högkompetent gäng som är både rappa och smidiga att jobba med, säger Sven. Att övervaka IT kan man givetvis göra internt men det är en helt annan sak när en tredje part gör det. Det ger en helt annan seriositet och en helt annan trygghet. Jag känner hela tiden att jag har full koll på vad som händer.”

Lights In Lines tjänst består i att kör ett antal script som simulerar vanliga användare och som loggar på tjänsterna var 5:e minut. Sedan rapporteras status kring tillgängligheten till den som just för stunden har ansvar för beredskapen hos Bisnode, som även med hjälp av Lights In Lines mobil-app kan ha koll på att systemen är uppe. Går något fel så skickas omedelbart ett SMS från Lights In Line till Bisnode.

”Övervakningen har också resulterat i att Bisnode kunnat se att deras Internet-leverantörer plötsligt ändrat i sina routers, något som får betraktas som en överaskande bonusinformation.”

Bisnode LILMA Mobil App

Bisnode LILMA Mobil App

Ett annat spännande teknikområde är övervakning av IP-telefoni, något som Lights In Line skall börja titta på tillsammans med Bisnode i en nära framtid. Eftersom IP-telefoni i princip kräver samma typ av övervakning och prestandaoptimering som Lights In Line redan idag arbetar med är det här ett område där det är sannolikt att man kan bidra med kompetens och expertis.

”Fler och fler i Bisnode-koncernen efterfrågar också Lights In Lines tjänster i takt med att man succesivt siktar på att i höst gå från 18/7 beredskap till 24/7. Fler övervaknings-script är på gång att installeras och Lights in Line tar en roll som ”domare” över tekniken. Statistik över de olika systemens tillgänglighet har nu också börja dyka upp på interna möten hos koncernens olika tjänsteansvariga vilket naturligtvis är helt rätt. Säljer man tjänster på nätet är ingenting viktigare än att allt fungerar utan dröjsmål. Annars är kunden borta på tre röda sekunder…”


Fotnot

Bisnode är en av våra första större implementationer av övervakningslösningar. De gjorde från början en mycket seriös upphandling, där flera leverantörer fick visa upp sina lösningsförslag samt genomfördes även en PoC (Proof of Concept) med två utvalda leverantörer. Vi valde att basera lösningen på ett verktyg från ManageEngine, Applications Manager, och byggde ut denna med en egen implementation av en script motor för testautomatisering som vi kallar LILSE. Tack vare våra erfarenheter att tillverka skript som klarar förändringar på sajten utan att felaktigt larma, samt vår styrka att kunna anpassa och förädla produkter till kundens behov, fick vi förtroendet att implementera lösningen.

Idag har vi även anpassat lösningen till att kunna mäta tillgänglighet under flera parallella tidsperioder då Bisnodes kunder har olika SLA på en och samma tjänst. Vi har även lagt mycket tid på att minimera falska larm som beror på tillfälliga störningar, samt processer och systemstöd för att snabbt kunna avgöra vad felen beror på. Vi trendanalyserar även feltyperna månad för månad för att kunna hjälpa vår kund att kontinuerligt förbättra sin tillgänglighet.

Prestandatest i kombination med övervakning

Vi ser i tidningarnas exempel på rubriker, ”långa svarstider på företag  x webbplats”, ”företag y webbplats kraschade klarade, inte av belastningen”

Rubrikerna skulle inte finnas om företagen kontinuerligt utförde prestandatester samt applikatorisk– och belastningsövervakning. De skulle veta prestandan, veta svarstiderna utifrån användarens perspektiv och samtidigt veta hur många användare som använt applikationen under ett intervall. Och framför allt de skulle med denna information snabbare kunna agera för att förbättra svarstiderna.

En del företag utför enbart en eller max 2 av ovan nämnda processer och det är naturligtvis bättre än inget alls.

Hur ser det ut på ditt företag/organisation ?

Visar med några exempel fördelen av att ha alla 3 processerna på plats, att inte utföra någon av processerna är naturligtvis det sämsta.

Exempel 1:  Du utför enbart Prestandatest
Vid dina kontinuerliga prestandatester vet du att din applikation klarar av 500 användare som under en timme utför 2000 ärenden och svarstiden utifrån användarens perspektiv är högst 3 sek. Bra !

Dock, dina användare klagar på att svarstiderna är långa! Utan applikatorisk övervakning och belastningsövervakning vet du inte vad svarstiderna egentligen varit, samt när dessa var dåliga och du vet inte hur många ärenden som utfördes under den värsta timmen eller hur många användare som utfört dessa.

Exempel 2: Du utför enbart applikatorisk övervakning
Du vet att svarstiderna ofta blir över 3 sekunder. Bra med denna koll ! Dock, eftersom prestandatest inte utförts vet du inte hur många användares/antal ärenden som applikationen klarar av. Och du vet inte hur många ärenden som användarna registrerade.

Exempel 3: Du utför enbart belastningsövervakning.
Du vet att 700 användare utfört under en timme utfört 3000 ärenden. Bra ! Dock,  du vet inte svarstiderna vid detta tillfälle eftersom applikatorisk övervakning saknas och du vet inte heller hur mycket svarstiderna borde vara eftersom prestandatester inte utförts.

Exempel 4: Grattis du utför prestandatester, applikatorisk- och belastningsövervakning!
Du vet att din applikation klarar av 500 användare som under en timme utför 2000 ärenden och att svarstiden utifrån användarens perspektiv är 3 sek.
Du vet att svarstiderna är 5 sekunder under vissa perioder och när det inträffar så har du över 700 användare som utför över 3000 ärenden per timme.

Invändningarna mot att inte utföra alla processerna brukar vara, vi har inte tid, tar för mycket resurser från oss, det är dyrt, etc etc

Ovan nämnda processer kan du köpa som tjänster numera, vilket innebär minimum av egen insats, samtidigt som du får koll och ett fast pris per månad.

Vi på Lights In Line AB har mycket lång erfarenhet inom alla branscher att hjälpa till att införa ovannämnda processer i organisationer.

Kontakta oss för en förutsättningslös diskussion.

 

Succé för Lights In Line s E2E tjänster på Piab

Sedan drygt ett år tillbaka har Piab använt sig av Lights In Lines E2E tjänster för övervakning, trendanalyser, larm och SLA-rapportering.

”Vi har nu bättre koll på vår tillgänglighet tack vare lättlästa SLA-rapporter och dessutom så får vi direkt larm om våra tjänster på hemsidan skulle få problem” säger Manuel  Donoso, IT-chef på Piab.

Från Piabs hemsida kan den presumtive kunden efter inloggning ”plocka ihop” sin produkt, E2E tjänsten övervakar att dessa rutiner fungerar och larmar om något problem.

Just att övervaka mera komplexa skeenden upplever vi som styrkan i E2E tjänsten , säger Manuel och fortsätter:

”Vi är helnöjda med LIL s tjänster och känner ett stort förtroende  i deras serviceanda och flexibilitet”

 

Om Piab

Piab grundades 1951 och har tagit fram innovativa lösningar som förbättrar energieffektiviteten, produktiviteten och arbetsmiljön hos vakuumanvändare runt om i världen. Som en tillförlitlig partner till många av världens ledande tillverkare utvecklar och tillverkar Piab en komplett uppsättning av vakuumpumpar, vakuumtillbehör, vakuumtransportörer och sugkoppar för ett stort antal processer inom automatiserad materialhantering och fabriksautomatisering. Piab har en världsomspännande organisation med dotterföretag och distributörer i fler än 50 länder, med huvudkontor i Sverige.

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.