måling af latens korrekt kræver, at du har kvalitetsdata. Der er en grund til, at KPMG ‘ s “2016 Global CEO Outlook” fandt ud af, at 84% af administrerende direktører er bekymrede over kvaliteten af de data, de baserer beslutninger på, og det er fordi alt for ofte data kan vildlede.
forskellen mellem virksomheder, der bekymrer sig om deres data og ikke er enorm. MIT-forskere fandt ud af, at virksomheder, der har vedtaget et datadrevet design, har en produktion, der er 5-6% højere end hvad man kunne forvente i betragtning af deres andre investeringer og brug af informationsteknologi. Denne grund alene gør forståelse af latenstid kritisk for forretningssucces.
på bare 7 minutter lærer du alt, hvad du har brug for at vide om måling af latens
Sådan måles latens
hvorfor korrekt måling af det betyder noget
almindelige faldgruber, når du ser på dine latensdata
kritikken af øjeblikkelig feedback
hvorfor der kræves usamplede data
så hvad er latens?
Dictionary.com definerer latenstid som “forsinkelsesperioden, når en komponent i et maskinsystem venter på, at en handling udføres af en anden komponent”. I enklere termer betyder dette mængden af tid mellem at kalde en funktion og dens faktiske udførelse. Latency er iboende i alle systemer; selvom vi havde et perfekt system(som ikke eksisterer), ville det være latent, hvor lang tid det tager for elektronerne i computeren at skifte transistorerne fra til TIL FRA eller omvendt.
Latency i små operationer er ikke en big deal, men når man håndterer millioner af operationer, er der millioner af latenser, der tilføjes hurtigt. Latency er ikke defineret af en arbejdsenheder/tid, men i stedet hvordan det opfører sig. Overvågningsværktøjer rapporterer tilbage, hvor lang tid det tager fra starten af en funktion til slutningen af funktionen.
Latency kan have stor indflydelse på din virksomhed, for eksempel “når det kommer til mobilhastighed, betyder hvert sekund noget — for hvert ekstra sekund tager det en mobilside at indlæse, konverteringer kan falde med op til 20%”(kilde). Så det er kritisk vigtigt at forstå din latenstid så godt du kan.
almindelige faldgruber, når man ser på dine Latensdata:
latens følger næsten aldrig en Normal, Gaussisk eller Poisson distribution. Selvom din latenstid følger en af disse distributioner på grund af den måde, vi observerer latenstid på, gør det gennemsnit, medianer og endda standardafvigelser ubrugelige! Hvis du for eksempel måler sidebelastninger, kan 99.9999999999% af disse belastninger være værre end din median. Dette er en del af grunden til, at tilfældig prøveudtagning din latenstid forårsager unøjagtige data, men mere om dette senere.
på dette tidspunkt spørger du sandsynligvis dig selv, om vi ikke bruger nogen standardafvigelse, hvordan kan vi meningsfuldt beskrive forsinkelser? Svaret er, at vi skal se på percentiler og maksimum. De fleste mennesker tænker for sig selv, okay, så jeg ser på P95, og jeg forstår den “almindelige sag”. Problemet med dette er, at P95 vil skjule alle de dårlige ting. Som Gil Tene, CTO, siger “det er et” marketing system”, bliver nogen narret.”
tag for eksempel denne graf:
Redaktørens Note: BeeInstant-produktet, der producerede dette skærmbillede, er ikke længere tilgængeligt, men dets muligheder er en del af Instanas APM-og Observerbarhedsplatform.
når du ser denne graf, kan du tydeligt se, hvorfor det er medianen, og gennemsnittet har ingen reel betydning, de viser ikke problemområdet. Når du ser den 95. percentil skyde op til venstre, tror du, at du ser hjertet af problemet.
dette er selvfølgelig ikke sandt, når du går for at undersøge, hvorfor dit program havde en hik, undlader du at se de værste 5% af hvad der skete. For at få denne form for spike kræver, at de øverste 5% af dataene er betydeligt værre.
se nu på den samme graf, der også viser 99.99 percentilen:
Redaktørens Note: BeeInstant-produktet, der producerede dette skærmbillede, er ikke længere tilgængeligt, men dets muligheder er en del af Instanas APM-og Observerbarhedsplatform.
den røde linje er den 95.percentil, mens den grønne er den 99,99. percentillinie. Som du tydeligt kan se, viser den 95. percentil kun 2 ud af 22 af dine problemer! Derfor skal du se på det fulde spektrum af dine data.
på trods af at mange mennesker måske tror, at de sidste 5% af dataene ikke har så stor betydning. Jo da, det kunne bare være en virtuel maskine genstart eller en hikke i dit system, eller noget i den retning, men mens det er sandt ved at ignorere det, du siger, at det bare ikke sker, når det kunne være en af de vigtigste ting for dig at målrette!
Gil Tenel kan lide at gøre den dristige påstand om, at “den første indikator, du aldrig skal slippe af med, er den maksimale værdi. Det er ikke støj, det er signalet. Resten er støj.”Mens maksimumet faktisk er en stor single i et system i stor skala, er det ofte ikke praktisk at forfølge kun det maksimale tilfælde. Intet system er perfekt, og hikke forekommer, i et stort praktisk system, der udelukkende forfølger det maksimale tilfælde, er det ofte en god måde at brænde dit udviklingsteam ud.
når man ser på 99.99 percentilen ser du, hvad der sker med det store flertal af dine kunder, og eventuelle pigge, du ser der, ved du, er faktiske problemer, mens eventuelle pigge i dit maksimum måske bare er en hik i dit system. Når dine devops-hold fokuserer deres indsats på disse små hikke, gør de det med store mulighedsomkostninger, da de ikke i stedet kan arbejde på flere større problemer.
det bemærkes, at hvis din 99.99 th og dit maksimum er meget tæt på hinanden(og begge er spiked), end det er et godt signal om, at dette er et problem, dit team skal arbejde på. På denne måde har Gil ret i, at maksimumet er et godt signal, men forkert, at resten af dine data bare er støj. Som du kan se i denne graf:
Redaktørens Note: som ovenfor er produktet, der producerede dette skærmbillede, ikke længere tilgængeligt, men dets muligheder er en del af Instanas APM-og Observerbarhedsplatform.
vores 99.99. percentil og maksimum fra vores tidligere eksempel matcher nøjagtigt. Dette er et godt signal om, at det, du ser på, er en rigtig fejl og ikke bare en hik.
Averaging Percentiles: hvordan Precomputation får dig til at Mismeasure Latency:
en endnu værre faldgrube folk falder ind end bare at se på 95.percentilen undlader at erkende, at deres percentiler er gennemsnitlige. Gennemsnitlig percentiler er statistisk absurd; det fjerner al betydning fra, hvad det er, du ser på. Vi har allerede vist, hvordan gennemsnit ikke er gode, når man ser på latenstid, og hvis du ser på gennemsnitlige percentiler, er du simpelthen lige tilbage til firkantet. Mange programmers gennemsnitlige dine percentiler tager for eksempel dette Grafana-diagram:
uanset om du indså det, før alle percentiler på dette er gennemsnitlige! Det står der i hovedbogen. NÆSTEN ALLE OVERVÅGNINGSTJENESTER GENNEMSNIT DINE PERCENTILER! Dette er en realitet på grund af precomputation. Når din overvågningstjeneste optager dine data, beregner de percentilen af dataene i det øjeblik.
så når du går for at se på din 95.percentil, viser de dig et gennemsnit af alle dine percentiler. Denne genvej til” dit gode ” for at gøre din service hurtigere fjerner i virkeligheden al statistisk signifikans fra dine data.
hvorfor du skal have Unsampled Data for at måle latenstid korrekt:
uanset om du ved det, ved at overvåge værktøjer, der deltager i data sampling, producerer de gennemsnitlige data. Næsten alle overvågningsværktøjer prøver deres data. Tag for eksempel DataDog; de har stort tab af data. Hvis du sender dem 3 Millioner point i et minut, de vil ikke tage dem alle. I stedet vil de tilfældigt prøve punkterne og derefter samle dem i 1 point pr.
du skal have unsampled data for at forstå din latenstid. Det er iboende, at med samplede data kan du ikke få adgang til den fulde distribution! Dit maksimum er ikke dit sande maksimum, og din globale percentil er heller ikke en nøjagtig gengivelse af, hvad der foregår!
samplede Data forværrer koordineret udeladelse!
når du prøver data, udelader du data. Sig for eksempel, at du har 10.000 operationer, der sker på et minut, og sender 2 datapunkter hver til dit overvågningssystem. Sig, at du har en fejl i dit system, og et af disse datapunkter viser dette pr.10.000 operationer. Dit overvågningssystem har kun en 1/20. 000 chance for at vælge dette som det datapunkt, det viser dig som maksimum!
hvis du løber længe nok, vises datapunktet til sidst, men som et resultat vil det se ud som en sporadisk edge-sag, selvom det sker med en af dine kunder hvert minut! Når du ikke prøve data, og du har en af disse pigge, det vil dukke op tydeligt i din 99.99 percentilen, og din maksimale vil dukke op tæt på det, signalerer dig, at du har en fejl i dit program. Når du prøver dine data, vises de dog ikke så ofte, hvilket betyder, at du ikke ser det som en fejl, men snarere som en hik. Dette betyder, at dit ingeniørteam ikke vil indse betydningen af det!
lad ikke dit overvågningsværktøj narre dig til at tro, at du ved, hvad der foregår med din latenstid.
Vælg et værktøj, der ikke leverer samplede data. Vælg et værktøj, der ikke gennemsnit dine globale percentiler. Start en gratis to-ugers prøveperiode i dag!
