het correct meten van de latentie vereist kwaliteitsgegevens. Er is een reden dat KPMG ‘ s “2016 Global CEO Outlook” vond dat 84% van de CEO ‘ s zich zorgen maakt over de kwaliteit van de gegevens waarop ze beslissingen baseren en dat is omdat maar al te vaak gegevens kunnen misleiden.
het verschil tussen bedrijven die om hun gegevens geven en die dat niet doen, is enorm. MIT onderzoekers vonden dat bedrijven die een data-driven ontwerp hebben aangenomen hebben een output die 5-6% hoger is dan wat verwacht zou worden gezien hun andere investeringen en gebruik van informatietechnologie. Alleen al deze reden maakt het begrijpen van Latency van cruciaal belang voor zakelijk succes.
In slechts 7 minuten leert u alles wat u moet weten over het meten van latentie
hoe latentie te meten
waarom het er toe doet
gemeenschappelijke valkuilen bij het bekijken van uw latentiegegevens
de kriticiteit van directe feedback
waarom niet-samplede gegevens vereist zijn
dus wat is latentie?
Dictionary.com definieert latency als “de periode van vertraging wanneer een component van een hardwaresysteem wacht op een actie die door een andere component wordt uitgevoerd”. In eenvoudigere termen betekent dit de hoeveelheid tijd tussen het aanroepen van een functie en de daadwerkelijke uitvoering ervan. Latentie is inherent aan alle systemen; zelfs als we een perfect systeem hadden(dat niet bestaat), zou het latent zijn hoeveel tijd het kost voor de elektronen in de computer om de transistors van aan naar uit te schakelen of vice versa.
latentie in kleine operaties is niet zo erg, maar bij het verwerken van miljoenen operaties, zijn er miljoenen latenties die snel optellen. Latentie wordt niet gedefinieerd door een werkeenheid / tijd, maar in plaats daarvan hoe het zich gedraagt. Monitoring tools rapporteren hoe lang het duurt van het begin van een functie tot het einde van de functie.
Latency kan een grote impact hebben op uw bedrijf, bijvoorbeeld “als het gaat om mobiele snelheid, elke seconde telt — voor elke extra seconde duurt het een mobiele pagina te laden, conversies kunnen dalen met maximaal 20%”(bron). Het is dus van cruciaal belang om je latency zo goed mogelijk te begrijpen.
veelvoorkomende valkuilen bij het bekijken van uw Latentiegegevens:
latentie volgt bijna nooit een normale, Gaussiaanse of Poisson distributie. Zelfs als je latency een van deze distributies volgt vanwege de manier waarop we latency waarnemen, maakt het gemiddelden, medianen en zelfs standaarddeviaties nutteloos! Als u bijvoorbeeld paginabelastingen meet, kan 99,9999999999% van deze belastingen slechter zijn dan uw mediaan. (Klik om deze statistiek te twitteren) dit is een deel van de reden dat willekeurige sampling van uw latency onjuiste gegevens veroorzaakt, maar meer hierover later.
op dit moment vraagt u zich waarschijnlijk af, als we geen standaarddeviatie gebruiken, hoe kunnen we latenties zinvol beschrijven? Het antwoord is dat we naar percentielen en Maxima moeten kijken. De meeste mensen denken bij zichzelf, Oké, dus ik kijk naar P95 en ik begrijp de “gewone zaak”. Het probleem hiermee is dat P95 alle slechte dingen gaat verbergen. Zoals Gil Tene, CTO van Azul Systems, zegt “het is een “marketing systeem”, iemand wordt bedrogen.”
Neem bijvoorbeeld deze grafiek:
Opmerking van de redacteur: het Beinstant product dat deze screenshot geproduceerd is niet langer beschikbaar, maar de mogelijkheden zijn onderdeel van Instana ‘ s APM en Observability Platform.
wanneer u deze grafiek ziet, kunt u duidelijk zien waarom het de mediaan is en het gemiddelde heeft geen echte betekenis, Ze laten het probleemgebied niet zien. Als je het 95e percentiel naar links ziet schieten, denk je dat je de kern van het probleem ziet.
dit is natuurlijk niet waar, wanneer u gaat onderzoeken waarom uw programma een hik had, ziet u niet de ergste 5% van wat er gebeurd is. Om dit soort piek te krijgen vereist dat de top 5% van de gegevens is aanzienlijk erger.
kijk nu naar dezelfde grafiek die ook het 99,99 e percentiel toont:
Opmerking van de redacteur: het Beinstant product dat deze screenshot geproduceerd is niet langer beschikbaar, maar de mogelijkheden zijn onderdeel van Instana ‘ s APM en Observability Platform.
die rode lijn is het 95e percentiel terwijl de groene de 99,99e percentiellijn is. Zoals je duidelijk kunt zien toont het 95e percentiel slechts 2 van de 22 van je problemen! Daarom moet u kijken naar het volledige spectrum van uw gegevens.
ondanks het feit dat veel mensen denken dat de laatste 5% van de gegevens niet zo veel betekenis heeft. Zeker, het kan gewoon een virtuele machine herstarten of een hik in uw systeem, of iets dergelijks, maar terwijl dat waar is door het te negeren, je zegt dat het gewoon niet gebeuren wanneer het een van de belangrijkste dingen voor u om te richten zou kunnen zijn!
Gil Tenel claimt graag dat ” de Nummer één indicator die je nooit kwijt moet raken, de maximale waarde is. Dat is geen lawaai, dat is het signaal. De rest is lawaai.”Hoewel het maximum inderdaad een geweldige single is in een systeem op grote schaal, is het vaak niet praktisch om alleen de maximale case na te streven. Geen systeem is perfect en hik doen optreden, in een grootschalige praktische systeem het nastreven van de maximale case uitsluitend is vaak een goede manier om burn-out van uw development team.
als je kijkt naar het 99,99 e percentiel zie je wat er gebeurt met de grote meerderheid van je klanten en eventuele pieken die je daar ziet, weet je dat er werkelijke problemen zijn, terwijl elke pieken in je maximum gewoon een hik in je systeem kan zijn. Wanneer uw devops teams richten hun inspanning op deze kleine hik ze doen dit op grote opportunity cost, als ze niet in plaats daarvan werken aan meer grote problemen.
het is van belang dat als uw 99,99 E en uw maximum zeer dicht bij elkaar staan(en beide zijn verrijkt) dan is het een geweldig signaal dat dit een probleem is waar uw team aan moet werken. Op deze manier, Gil heeft gelijk dat het maximum is een geweldig signaal, maar verkeerd dat de rest van uw gegevens is gewoon ruis. Zoals u kunt zien in deze grafiek:
Opmerking van de redacteur: zoals hierboven, het product dat deze screenshot geproduceerd is niet langer beschikbaar, maar de mogelijkheden zijn onderdeel van Instana ‘ s APM en Observability Platform.
onze 99.99 percentiel en maximum van ons vorige voorbeeld komen precies overeen. Dit is een geweldig signaal dat wat het is waar je naar kijkt een echte bug is en niet alleen een hik.
gemiddelde percentielen: hoe Voorcomputing ervoor zorgt dat u de latentie verkeerd meet:
een nog ergere valkuil waar mensen in vallen dan alleen maar kijken naar het 95e percentiel, is niet in staat te herkennen dat hun percentielen gemiddeld zijn. Het gemiddelde percentiel is statistisch absurd; het verwijdert alle Betekenis van waar je naar kijkt. We hebben al laten zien hoe gemiddelden niet goed zijn, als je naar latency kijkt, en als je naar gemiddelde percentielen kijkt, ben je gewoon weer terug bij af. Veel software ‘ s gemiddelde uw percentielen neem bijvoorbeeld deze Grafana grafiek:
of je het al dan niet besefte voordat alle percentielen op dit zijn gemiddeld! Dat staat in het grootboek van de x-as. BIJNA ALLE MONITORING DIENSTEN GEMIDDELD UW PERCENTIELEN! Dit is een realiteit als gevolg van precomputatie. Wanneer uw monitoringdienst uw gegevens opneemt, berekenen ze het percentiel van de gegevens voor die minuut.
als je dan naar je 95e percentiel gaat kijken, laten ze je een gemiddelde zien van al je percentielen. Deze snelkoppeling voor “uw goed” om uw service sneller te maken, is, in werkelijkheid, het verwijderen van alle statistische betekenis van uw gegevens.
waarom u niet-samplede gegevens moet hebben om de latentie correct te meten:
of u dit al dan niet weet, door controle-instrumenten die deelnemen aan de data sampling, produceren ze gemiddelde gegevens. Bijna elke monitoring tool samples hun gegevens. Neem bijvoorbeeld DataDog; ze hebben een groot verlies van gegevens. Als je ze 3 miljoen punten in een minuut stuurt, nemen ze ze niet allemaal. In plaats daarvan zullen ze willekeurig de punten bemonsteren en ze vervolgens samenvoegen tot 1 punt per minuut.
u moet niet-samplede gegevens hebben om uw latentie te begrijpen. Het is inherent dat met gesamplede gegevens u geen toegang tot de volledige distributie! Jullie maximum is niet jullie ware maximum, noch is jullie globale percentiel een nauwkeurige weergave van wat er gaande is!
wanneer u gegevens voorbeeldt, laat u gegevens weg. Stel dat u bijvoorbeeld 10.000 operaties hebt die in een minuut plaatsvinden en elk 2 datapunten naar uw monitoringsysteem verzenden. Stel dat je een bug in je systeem hebt en een van deze datapunten toont dit per 10.000 operaties. Uw monitoringsysteem heeft slechts een 1/20, 000 kans om dit te kiezen als het gegevenspunt het toont u als het maximum!
als u lang genoeg loopt, zal het gegevenspunt uiteindelijk verschijnen, maar als gevolg daarvan zal het eruit zien als een sporadische randgeval, ook al gebeurt het elke minuut bij een van uw klanten! Als je geen gegevens samplet, en je hebt een van deze pieken, het zal duidelijk te zien in uw 99,99 e percentiel, en uw maximum zal worden weergegeven dicht bij het, signaleren u dat u een bug in uw programma. Wanneer u een monster van uw gegevens, echter, het zal niet zo vaak te zien, wat betekent dat je het niet ziet als een bug, maar eerder als een hik. Dit betekent dat uw engineering team zal falen om de Betekenis van het te realiseren!
laat je monitoring tool je niet misleiden door te denken dat je weet wat er aan de hand is met je Latency.
Kies een gereedschap dat geen gesamplede gegevens levert. Kies een tool die uw globale percentielen niet gemiddeld. Begin vandaag nog een gratis proefperiode van twee weken!
