att mäta latens korrekt kräver att du har kvalitetsdata. Det finns en anledning till att KPMG: s ”2016 Global CEO Outlook” fann att 84% av VD: n är oroade över kvaliteten på de data de baserar beslut på och det beror på att alltför ofta data kan vilseleda.
skillnaden mellan företag som bryr sig om sina data och inte är enorm. MIT-forskare fann att företag som har antagit en datadriven design har en produktion som är 5-6% högre än vad som förväntas med tanke på deras andra investeringar och användning av informationsteknologi. Enbart denna anledning gör förståelsen av latens avgörande för affärsframgång.
på bara 7 minuter lär du dig allt du behöver veta om mätning av latens
hur man mäter latens
varför korrekt mätning av det betyder
vanliga fallgropar när du tittar på dina latensdata
kritiken av omedelbar feedback
varför krävs osamplade data
så vad är latens?
Dictionary.com definierar latens som”fördröjningsperioden när en komponent i ett hårdvarusystem väntar på att en åtgärd ska utföras av en annan komponent”. I enklare termer betyder detta tiden mellan att ringa en funktion och dess faktiska utförande. Latens är inneboende i alla system; även om vi hade ett perfekt system(som inte existerar), skulle det vara latent den tid det tar för elektronerna i datorn att växla transistorerna från på till av eller vice versa.
Latency i små operationer är inte en stor sak, men när man hanterar miljontals operationer finns det miljontals latenser som lägger sig snabbt. Latency definieras inte av en arbetsenhet / tid utan istället hur den beter sig. Övervakningsverktyg rapporterar hur lång tid det tar från början av en funktion till slutet av funktionen.
Latency kan ha stor inverkan på ditt företag, till exempel ”när det gäller mobilhastighet är varje sekund viktig — för varje ytterligare sekund tar det en mobilsida att ladda, konverteringar kan sjunka med upp till 20%”(källa). Så det är kritiskt viktigt att förstå din latens så bra du kan.
vanliga fallgropar när du tittar på dina Latensdata:
Latency följer nästan aldrig en Normal, Gaussisk eller Poisson-distribution. Även om din latens följer en av dessa fördelningar på grund av hur vi observerar latens gör det medelvärden, medianer och till och med standardavvikelser värdelösa! Om du till exempel mäter sidbelastningar kan 99,9999999999% av dessa belastningar vara sämre än din median. (Klicka för att tweeta denna statistik) det här är en del av anledningen till att slumpmässig provtagning av din latens orsakar felaktiga data, men mer om detta senare.
vid denna tidpunkt frågar du förmodligen dig själv om vi inte använder någon standardavvikelse, hur kan vi meningsfullt beskriva latenser? Svaret är att vi måste titta på percentiler och Maximum. De flesta tänker på sig själva, okej så jag tittar på P95 och jag förstår det ”vanliga fallet”. Problemet med detta är att P95 kommer att dölja alla dåliga saker. Som Gil Tene, CTO för Azul Systems, säger ”Det är ett ”marknadsföringssystem”, blir någon lurad.”
ta till exempel Denna graf:
Redaktörens anmärkning: beeinstant-produkten som producerade denna skärmdump är inte längre tillgänglig, men dess funktioner är en del av Instanas APM-och Observerbarhetsplattform.
när du ser den här grafen kan du tydligt se varför det är medianen och genomsnittet har ingen verklig betydelse, de visar inte problemområdet. När du ser den 95: e percentilen skjuta upp till vänster tror du att du ser hjärtat av problemet.
Detta är naturligtvis inte sant men när du går för att undersöka varför ditt program hade en hicka misslyckas du med att se de värsta 5% av vad som hände. För att få denna typ av spik kräver att topp 5% av data är betydligt sämre.
titta Nu på samma graf som också visar 99.99: e percentilen:
Redaktörens anmärkning: beeinstant-produkten som producerade denna skärmdump är inte längre tillgänglig, men dess funktioner är en del av Instanas APM-och Observerbarhetsplattform.
den röda linjen är 95: e percentilen medan den gröna är 99,99: e percentilen. Som du tydligt kan se visar 95: e percentilen bara 2 av 22 av dina problem! Det är därför du måste titta på hela spektrumet av dina data.
trots att många kanske tror att de sista 5% av data inte har så stor betydelse. Visst, det kan bara vara en virtuell maskin omstart eller en hicka i ditt system, eller något liknande, men medan det är sant genom att ignorera det, du säger att det bara inte händer när det kan vara en av de viktigaste sakerna för dig att rikta!
Gil Tenel gillar att göra det djärva påståendet att ” den främsta indikatorn du aldrig ska bli av med är det maximala värdet. Det är inte buller, det är signalen. Resten är buller.”Medan maximum verkligen är en stor singel i ett system i stor skala är det ofta inte praktiskt att driva bara det maximala fallet. Inget system är perfekt och hicka förekommer, i ett storskaligt praktiskt system som uteslutande strävar efter det maximala fallet är ofta ett bra sätt att bränna ut ditt utvecklingsteam.
när du tittar på 99.99: e percentilen ser du vad som händer med den stora majoriteten av dina kunder och eventuella spikar du ser där vet du är faktiska problem, medan eventuella spikar i ditt maximala kan bara vara en hicka i ditt system. När dina devops-team fokuserar sina ansträngningar på dessa små hicka gör de det till stor möjlighetskostnad, eftersom de istället inte kan arbeta med mer viktiga frågor.
det är värt att notera att om din 99.99 th och ditt maximum är mycket nära varandra(och båda är spikade) än det är en bra signal att detta är ett problem som ditt team ska arbeta med. På detta sätt har Gil rätt att det maximala är en bra signal, men fel att resten av dina data bara är brus. Som du kan se i den här grafen:
Redaktörens anmärkning: som ovan är produkten som producerade denna skärmdump inte längre tillgänglig, men dess funktioner är en del av Instanas APM-och Observerbarhetsplattform.
vår 99.99: e percentilen och maximalt från vårt tidigare exempel matchar exakt. Det här är en bra signal att det du tittar på är en riktig bugg och inte bara en hicka.
Averaging Percentiles: hur Precomputation orsakar dig att Mismeasure Latency:
en ännu värre fallgrop människor faller in än att bara titta på den 95: e percentilen misslyckas med att erkänna att deras percentiler är genomsnittliga. Medelvärdes percentiler är statistiskt absurt; det tar bort all betydelse från vad det är du tittar på. Vi har redan visat hur medelvärden inte är bra, när man tittar på latens, och om du tittar på genomsnittliga percentiler är du helt enkelt tillbaka till ruta ett. Många programvarans genomsnittliga dina percentiler tar till exempel detta Grafana-diagram:
oavsett om du insåg det innan alla percentiler på detta är genomsnittliga! Det står så där i x-axelboken. NÄSTAN ALLA ÖVERVAKNINGSTJÄNSTER GENOMSNITTLIGA DINA PERCENTILER! Detta är en verklighet på grund av precomputation. När din övervakningstjänst tar in dina data beräknar de percentilen av data för den minuten.
sedan när du går för att ta en titt på din 95: e percentilen, de visar dig ett genomsnitt av alla dina percentiler. Denna genväg för ”ditt bra” för att göra din tjänst snabbare, är i verkligheten att ta bort all statistisk betydelse från dina data.
Varför måste du ha Osamplad Data för att mäta latens korrekt:
oavsett om du vet det, genom att övervaka verktyg som deltar i dataprovtagning, producerar de genomsnittliga data. Nästan varje övervakningsverktyg samplar sina data. Ta till exempel DataDog; de har stor dataförlust. Om du skickar dem 3 miljoner poäng på en minut tar de inte dem alla. Istället kommer de slumpmässigt att prova poängen och sedan aggregera dem till 1 poäng per minut.
du måste ha osamplad data för att förstå din latens. Det är inneboende att med samplade data kan du inte komma åt hela distributionen! Ditt maximum är inte ditt sanna maximum, inte heller är din globala percentil en korrekt representation av vad som händer!
samplade Data förvärrar samordnad utelämnande!
när du samplar data utelämnar du data. Säg till exempel att du har 10 000 operationer som händer på en minut och skickar ut 2 datapunkter vardera till ditt övervakningssystem. Säg att du har ett fel i ditt system och en av dessa datapunkter visar detta per 10 000 operationer. Ditt övervakningssystem har bara 1/20 000 chans att välja detta som datapunkt det visar dig som maximalt!
om du kör tillräckligt länge kommer datapunkten att dyka upp så småningom, men som ett resultat kommer det att se ut som ett sporadiskt kantfall, även om det händer med en av dina kunder varje minut! När du inte provar data, och du har en av dessa spikar, kommer den att dyka upp tydligt i din 99,99: e percentilen, och ditt maximala kommer att dyka upp nära det och signalera att du har ett fel i ditt program. När du provar dina data kommer det dock inte att dyka upp så ofta, vilket betyder att du inte ser det som en bugg utan snarare som en hicka. Det betyder att ditt ingenjörsteam inte kommer att inse betydelsen av det!
låt inte ditt övervakningsverktyg lura dig att tro att du vet vad som händer med din latens.
Välj ett verktyg som inte tillhandahåller samplade data. Välj ett verktyg som inte genomsnittliga dina globala percentiler. Starta en gratis två veckors prov idag!
