a késleltetés megfelelő méréséhez minőségi adatokra van szükség. Ennek oka, hogy a KPMG “2016 Global CEO Outlook” megállapította, hogy a vezérigazgatók 84% – a aggódik a döntések alapjául szolgáló adatok minősége miatt, és ez azért van, mert túl gyakran az adatok félrevezethetik.
óriási a különbség azon vállalatok között, amelyek törődnek az adataikkal, és nem. Az MIT kutatói azt találták, hogy az adatközpontú tervezést alkalmazó vállalatok teljesítménye 5-6%-kal magasabb, mint amit más beruházásaik és az információs technológia használata miatt várnának. Ez az ok önmagában kritikussá teszi a késés megértését az üzleti siker szempontjából.
mindössze 7 perc alatt megtudhat mindent, amit tudnia kell a késleltetés méréséről
hogyan kell mérni a késleltetést
miért fontos a megfelelő mérés
gyakori buktatók a késleltetési adatok megtekintésekor
az azonnali visszajelzés kritikussága
miért van szükség mintavétel nélküli adatokra
tehát mi a késleltetés?
Dictionary.com a késleltetést úgy határozza meg, mint “a késleltetés időtartamát, amikor a hardverrendszer egyik összetevője egy másik komponens által végrehajtott műveletre vár”. Egyszerűbben fogalmazva, ez azt jelenti, hogy mennyi idő telik el egy függvény meghívása és tényleges végrehajtása között. A késleltetés minden rendszerben benne rejlik; még akkor is, ha tökéletes rendszerünk lenne(ami nem létezik), látens lenne, hogy mennyi időbe telik, amíg a számítógép elektronjai átkapcsolják a tranzisztorokat be-ről kikapcsolásra vagy fordítva.
a kis műveletek késése nem nagy ügy, de millió művelet kezelésekor millió késés van, amelyek gyorsan összeadódnak. Latency nem határozza meg a munka egységek / idő, hanem hogyan viselkedik. A Felügyeleti eszközök beszámolnak arról, hogy mennyi ideig tart a funkció kezdetétől a funkció végéig.
a késés jelentős hatással lehet vállalkozására, például “amikor a mobil sebességéről van szó, minden másodperc számít — minden további másodpercre egy mobil oldal betöltése szükséges, a konverziók akár 20% – kal is csökkenhetnek”(forrás). Ezért kritikus fontosságú, hogy a lehető legjobban megértsük a késleltetést.
gyakori buktatók a késleltetési adatok megtekintésekor:
a késleltetés szinte soha nem követi a normál, Gauss-vagy Poisson-eloszlást. Még akkor is, ha a késleltetés ezen eloszlások egyikét követi a késleltetés megfigyelésének módja miatt, az átlagokat, mediánokat, sőt a szórásokat is használhatatlanná teszi! Ha például oldalbetöltéseket mér, akkor ezeknek a betöltéseknek a 99,999999999% – a rosszabb lehet, mint a medián. (Kattintson a statisztika tweeteléséhez) ez az oka annak, hogy a késés véletlenszerű mintavétele pontatlan adatokat okoz, de erről később.
ezen a ponton valószínűleg azt kérdezi magától, hogy ha nem használunk szórást, hogyan tudjuk értelmesen leírni a késéseket? A válasz az, hogy meg kell vizsgálnunk a Percentiliseket és a maximumokat. A legtöbb ember azt gondolja, hogy maguk, oké, így ránézek P95 és megértem a”közös eset”. A probléma ezzel az, hogy a P95 elrejti az összes rossz dolgot. Ahogy Gil Tene, az Azul Systems műszaki vezetője azt mondja:” ez egy “marketing rendszer”, valakit becsapnak.”
Vegyük például ezt a grafikont:
a szerkesztő megjegyzése: A beeinstant termék, amely ezt a képernyőképet készítette, már nem érhető el, de képességei az Instana APM és Observability platformjának részét képezik.
amikor ezt a grafikont látja, világosan láthatja, hogy miért a medián és az átlagnak nincs valódi jelentősége, nem mutatják a problémás területet. Amikor látja, hogy a 95. percentilis balra lő, úgy gondolja, hogy látja a probléma szívét.
ez, persze, nem igaz, bár, ha megy, hogy vizsgálja meg, hogy miért a program volt a csuklás nem látja a legrosszabb 5% – a, hogy mi történt. Ahhoz, hogy ez a fajta tüske megköveteli, hogy a felső 5% az adatok lényegesen rosszabb.
most nézze meg ugyanazt a grafikont, amely a 99,99. százalékot is mutatja:
a szerkesztő megjegyzése: A beeinstant termék, amely ezt a képernyőképet készítette, már nem érhető el, de képességei az Instana APM és Observability platformjának részét képezik.
ez a piros vonal a 95.percentilis, míg a zöld a 99,99. percentilis vonal. Mint jól látható, a 95. percentilis csak azt mutatja 2 kívül 22 a kérdések! Ezért meg kell vizsgálnia az adatok teljes spektrumát.
annak ellenére, hogy sokan azt gondolhatják, hogy az adatok utolsó 5% – ának nincs ekkora jelentősége. Persze, lehet, hogy csak egy virtuális gép újraindítása vagy csuklás a rendszerben, vagy valami ilyesmi, de bár ez igaz, ha figyelmen kívül hagyja, azt mondja, hogy egyszerűen nem történik meg, amikor ez lehet az egyik legfontosabb dolog, amit megcélozhat!
Gil Tenel szereti azt a merész állítást tenni, hogy “az első számú mutató, amelytől soha nem szabad megszabadulni, a maximális érték. Ez nem zaj, ez a jel. A többi csak zaj.”Bár a maximum valóban nagyszerű kislemez egy nagyszabású rendszerben, gyakran nem célszerű csak a maximális esetet folytatni. Egyetlen rendszer sem tökéletes, csuklás nem fordul elő, egy nagyszabású gyakorlati rendszerben, amely kizárólag a maximális esetet követi, gyakran jó módja annak, hogy kiégesse a fejlesztői csapatot.
ha megnézzük a 99,99-es percentilis látod, hogy mi történik a nagy többsége az ügyfelek és a tüskék látsz ott tudod, hogy a tényleges problémák, mivel minden tüskék a maximális lehet, hogy csak egy csuklás a rendszerben. Amikor a devops csapatai ezekre a kis csuklásokra összpontosítják erőfeszítéseiket, akkor ezt nagy alternatív költségekkel teszik, mivel nem tudnak inkább nagyobb kérdésekben dolgozni.
megjegyzendő, hogy ha a 99.99-es és a maximum nagyon közel van egymáshoz (és mindkettő tüskés), akkor ez egy nagyszerű jel, hogy ez egy olyan kérdés, amelyen a csapatnak dolgoznia kell. Ily módon, Gil igaza van, hogy a maximális egy nagy jel, de rossz, hogy a többi adat csak zaj. Mint látható ezen a grafikonon:
a szerkesztő megjegyzése: A fentiekhez hasonlóan a képernyőképet készítő termék már nem érhető el, de képességei az Instana APM és Observability platformjának részét képezik.
a 99.Az előző példánkban szereplő 99. percentilis és maximum pontosan egyezik. Ez egy nagyszerű jel, hogy amit láttok, az egy igazi hiba, és nem csak egy csuklás.
Averaging percentilis: hogyan Precomputation okozza, hogy Mismeasure Latency:
egy még rosszabb buktató emberek esnek, mint nézi a 95.percentilis nem ismeri fel, hogy a percentilisek átlagolt. A percentilisek átlagolása statisztikailag abszurd; eltávolít minden jelentőséget abból, amit nézel. Már megmutattuk, hogy az átlagok nem jók, ha a késleltetést nézzük, és ha az átlagolt percentiliseket nézzük, akkor egyszerűen visszatérünk az első négyzethez. Sok szoftver átlaga az Ön percentilisei például ezt a Grafana diagramot veszik figyelembe:
függetlenül attól, hogy rájött-e, mielőtt az összes percentilis átlag lenne! Ez áll az x tengely főkönyvében. SZINTE AZ ÖSSZES FELÜGYELETI SZOLGÁLTATÁS ÁTLAGOLJA A PERCENTILISEKET! Ez az Előszámítás miatt valóság. Amikor a felügyeleti szolgáltatás veszi az adatokat, ők Számítástechnikai a percentilis az adatok az adott pillanatban.
akkor, ha megy, hogy vessen egy pillantást a 95.percentilis, ők mutatja meg egy átlagos ki az összes percentilis. Ez a parancsikon a” jó”, hogy a szolgáltatás gyorsabb, van, a valóságban, eltávolítja az összes statisztikai jelentősége az adatokat.
miért van szükség mintavétel nélküli adatokra a késleltetés megfelelő méréséhez:
függetlenül attól, hogy tudja-e, az adatmintavételben részt vevő felügyeleti eszközökkel átlagolt adatokat állítanak elő. Szinte minden megfigyelő eszköz mintát vesz az adataiból. Vegyük például a DataDog-ot; jelentős adatvesztésük van. Ha egy perc alatt 3 millió pontot küld nekik, nem fogják mindet elvinni. Ehelyett véletlenszerűen mintavételezik a pontokat, majd összesítik őket 1 pont / perc.
a késleltetés megértéséhez mintavétel nélküli adatokkal kell rendelkeznie. Jellemző, hogy a mintavételezett adatokkal nem férhet hozzá a teljes disztribúcióhoz! A maximumod nem az igazi maximumod, és a globális percentilised sem pontos ábrázolása annak, ami történik!
a mintavételezett adatok súlyosbítják a koordinált mulasztást!
amikor adatokat mintáz, akkor kihagyja az adatokat. Tegyük fel például, hogy egy perc alatt 10 000 művelet történik, mindegyik 2 adatpontot küld a megfigyelő rendszernek. Tegyük fel, hogy van egy hiba a rendszerben, és az egyik ilyen adatpont ezt mutatja 10 000 műveletenként. A felügyeleti rendszernek csak 1/20 000 esélye van arra, hogy ezt válassza az adatpontként, amelyet a maximumként mutat meg!
ha elég hosszú ideig fut, akkor az adatpont végül megjelenik, de ennek eredményeként szórványos edge esetnek fog kinézni, annak ellenére, hogy percenként történik az egyik ügyfelével! Ha nem mintavételezünk adatokat, és van egy ilyen tüskénk, akkor az egyértelműen megjelenik a 99,99-edik percentilisünkben, a maximumunk pedig közelít hozzá, jelezve, hogy hiba van a programunkban. Amikor mintát az adatokat, azonban, akkor nem jelenik meg olyan gyakran, ami azt jelenti, hogy nem fogja látni, mint egy hiba, hanem egy csuklás. Ez azt jelenti, hogy a mérnöki csapata nem fogja felismerni ennek jelentőségét!
ne hagyja, hogy a felügyeleti eszköz becsapni azt gondolni, hogy tudja, mi folyik a késés.
válasszon olyan eszközt, amely nem szolgáltat mintavételezett adatokat. Válasszon olyan eszközt, amely nem átlagolja a globális percentiliseket. Indítson ma egy ingyenes kéthetes próbaverziót!
