Redis latensgraf
Klientforsinkelse
Redis kommer med en klient-serverarkitektur. I noen tilfeller kan flere klienter prøve å koble seg til Redis -serveren samtidig. Siden Redis er entrådet, vil dette introdusere en klientkø der serveren serverer en klientprosess på et gitt tidspunkt. Derfor oppsto samtidig latens. Derfor kan det være nødvendig å etterfølgende klienter å vente.
Kommandolatens
Hver kommando tar litt tid å utføre. Det kan variere fra mikrosekund til sekunder. Derfor er det blitt identifisert som en latenskilde. De fleste av Redis -kommandoene tar konstant eller logaritmisk tidskompleksitet. Samtidig tar noen kommandoer o (n) tidskompleksitet. De er betydelig tregere.
Rundtur latens
Rundtur er tiden det tar å få et svar fra Redis-serveren etter at en kommando er utført på klientsiden. Det kan være forskjellige årsaker til tur-retur-latens, for eksempel treghet i nettverket, gaffeloperasjoner og OS-personsøk.
Redis latensovervåking
Sanntidsapplikasjoner bruker Redis, der ytelsen er avgjørende. Derfor er det givende å ha innsikt i Redis -latens som vil være nyttig å iverksette tiltak på forhånd. Fra versjon 2.8.13, har Redis lagt til latensovervåkningskomponenten til verktøykassen. Denne komponenten er i stand til å registrere latenspigger per hendelse eller spesifikk kodebane.
Latenshendelser eller kodeveier
Latenshendelsene (kodebaner) er ikke noe mer enn de generiske eller spesifikke operasjonene utført av Redis, for eksempel generiske kommandoer, gaffelsystemanrop og unlink -systemer. Når det gjelder de generiske kommandoene, er det to hovedhendelser definert av Redis.
- kommando
- Fast-kommando
Hendelsen "Fast-Command" er definert for Redis-kommandoer som har O (1) eller O (log n) tidskompleksitet, for eksempel HSET, Hincrby, HLEN, etc.
"Kommando" -kodebanen måler latenspigger for de andre kommandoene med O (n) tidskompleksitet.
Aktivering av latensovervåking i Redis Server
Latensverdiene avhenger av applikasjonens natur. En applikasjon kan betrakte 10 millisekunder som høy latens. Samtidig anser en annen applikasjon 1 sekund som en høy verdi. Derfor tilbyr Redis deg et alternativ for å definere latensterskelen på serveren. Som standard er terskelverdien 0. Det er to måter å sette denne verdien i Redis:
- Bruke “Config Set” underkommando i kjøretid
- Endre Redis -konfigurasjonsfilen
Konfigurasjonssettet underkommando
Du kan bruke Config Set Subcommand med parameteren og dens verdi for å angi terskelverdien, som vist på følgende. Her satte vi det som 500 millisekunder.
konfigurasjonssett latens-monitor-terskel 500
Endre Redis.Conf -fil
Vi kan starte Redis -serveren ved å tilby alle konfigurasjonene i en konfigurasjonsfil som heter “Redis.Conf ”. I delen "Latensmonitor" kan du angi parameterverdien "Latens-overvåkning-terskel".
Det anbefales å starte Redis -serveren på nytt etter å ha endret konfigurasjonsfilen.
Latensgrafen underkommando
Kommandoen "latens" tilbyr flere underkommandoer for å hente hendelsesbasert latensinformasjon. En av de populære kommandoene er "latensgraf". Det trekker en graf mot tiden da hendelsen har skjedd. Denne grafen er basert på ASCII -symboler og varierer fra minimum latensverdi til maksimum. Latenspiglene normaliseres mellom min og maks latenser.
La oss bruke kommandoen "feilsøking" for å sjekke hvordan latensgrafinformasjonen er generert.
Syntaks
Latensgraf
Parameteren "Event_name" kan være enhver hendelse definert av Redis Latens-overvåkningsrammen, for eksempel kommando, hurtig-kommando, gaffel osv.
Eksempel 01 - Applikasjoner med latens under terskelen
La oss bruke kommandoen "feilsøking" for å generere noen latenspigger. Det vil gå i dvale til den spesifiserte tidsavbruddet. Siden latensterskelen er 500 ms, vil vi utstede søvnkommandoer med en timeout lavere enn 500 ms.
feilsøking .1
feilsøking .2
feilsøking .3
Deretter vil vi utstede latensgraf -kommandoen som vist i følgende:
Latensgrafkommando
Det ville ideelt sett generere latensgrafen i ASCII-stil for de tidligere kommandoene. Siden kommandoutførelsestiden er lavere enn terskelverdien i alle de tre “Debug Sleep” -kommandoene, vil Redis ikke generere latenspigger. Hvis vi antar at dette er vår sanntidsapplikasjon, er du alle gode. Det er ingen latensproblemer vedlagt.
Produksjon:
Som forventet står det at ingen prøver er tilgjengelige for akkurat denne hendelsen.
Eksempel 02 - applikasjoner med latens større enn terskelen
La oss utstede noen feilsøkingskommandoer med en tidsavbruddsverdi større enn terskelverdien. Vanligvis er det bedre å tilbakestille alle de tidligere latenspigger før neste sett med kommandoer, som vist på følgende:
Latens tilbakestillingskommando
Deretter vil vi utstede feilsøkingskommandoer med en timeoutverdi på mer enn 500 ms.
feilsøking .7
feilsøking .9
Debug Sleep 1
Produksjon:
Som forventet har Ascii-stylet graf blitt generert av Redis. “_” Betegner den laveste latensverdien, og “#” -symbolet betegner den høyeste latenspike som skjedde i løpet av de siste 20 sekundene. Denne grafen kan tolkes vertikalt. Hver kolonne er for en hendelse som har skjedd i løpet av de siste sekundene, minutter eller dager. Den venstre kolonnen kan tolkes som hendelsen som skjedde for 20 sekunder siden, den neste har skjedd for 14 sekunder siden, og den siste kolonnen betegner en hendelse som skjedde for 4 sekunder siden.
Konklusjon
Redis brukes som en datalager for sanntidsapplikasjoner. Derfor er ytelsesaspektene avgjørende. Latensovervåkningsrammen er en komponent som Redis tilbyr for å overvåke latenspigger for forhåndsdefinerte hendelser. "Latensgraf-kommandoen" kan brukes til å generere ASCII-stil latenspigger for en gitt tidsramme. Det brukes til å identifisere latenstrender i applikasjonen din og ta nødvendige tiltak på forhånd. Latenspigger vil bli generert hvis latenstiden er større enn terskelverdien. Latensterskelverdien kan avvike fra en applikasjon til en annen basert på naturen.