Grafico di latenza Redis

Redis è un archivio di dati in memoria ampiamente utilizzato che è ben ottimizzato per prestazioni più elevate. La sua velocità lo rende utile per applicazioni in tempo reale, memorizzazione nella cache e archiviazione delle sessioni. Allo stesso tempo, Redis offre diversi comandi che sono veloci e ottimizzati per le prestazioni. Tuttavia, alcuni comandi Redis prendono O (n) la complessità del tempo più lento. La natura a thread singola di Redis solleva anche le preoccupazioni di latenza. La latenza di Redis può essere classificata in tre aree principali: latenza del cliente, latenza di comando e latenza di andata e ritorno.

Latenza del cliente

Redis viene fornito con un'architettura client-server. In alcuni casi, più client possono provare a connettersi al server Redis contemporaneamente. Poiché Redis è singolo, questo introdurrà una coda client in cui il server serve un processo client in un determinato momento. Quindi, è nata la latenza di concorrenza. Pertanto, i clienti successivi potrebbero aver bisogno di aspettare.

Latenza di comando

Ogni comando richiede del tempo per eseguire. Può variare da microsecondi a secondi. Quindi, è stato identificato come una fonte di latenza. La maggior parte dei comandi Redis assume una complessità temporale costante o logaritmica. Allo stesso tempo, alcuni comandi prendono la complessità del tempo O (n). Sono considerevolmente più lenti.

Latenza di andata e ritorno

Il viaggio di andata e ritorno è il tempo necessario per ottenere una risposta dal server Redis dopo che un comando è stato eseguito sul lato client. Potrebbero esserci diverse cause per la latenza di andata e ritorno, come la lentezza di rete, le operazioni della forcella e il pagamento del sistema operativo.

Monitoraggio della latenza Redis

Le applicazioni in tempo reale utilizzano Redis, dove le prestazioni sono cruciali. Quindi, è gratificante avere intuizioni sulla latenza di Redis che saranno utili per adottare misure in anticipo. Dalla versione 2.8.13, Redis ha aggiunto il componente di monitoraggio della latenza alla sua casella degli strumenti. Questo componente è in grado di registrare picchi di latenza per evento o percorso di codice specifico.

Eventi di latenza o percorsi di codice

Gli eventi di latenza (percorsi di codice) non sono altro che le operazioni generiche o specifiche eseguite da Redis, come comandi generici, chiamate di sistema di forcella e sistemi Unkink. Quando si tratta dei comandi generici, ci sono due eventi principali definiti da Redis.

1. comando
2. comando veloce

L'evento "Fast-comand" è definito per i comandi Redis che hanno O (1) o O (log n) complessità del tempo, come HSET, Hincrby, Hlen, ecc.

Il percorso del codice "Comando" misura i picchi di latenza per gli altri comandi con O (n) complessità del tempo.

Abilitazione del monitoraggio della latenza nel server Redis

I valori di latenza dipendono dalla natura dell'applicazione. Un'applicazione potrebbe considerare 10 millisecondi come alta latenza. Allo stesso tempo, un'altra applicazione considera 1 secondo come un valore elevato. Quindi, Redis ti offre un'opzione per definire la soglia di latenza nel server. Per impostazione predefinita, il valore di soglia è 0. Esistono due modi per impostare questo valore in Redis:

1. Utilizzo del sottocomando "config set" in runtime
2. Modifica del file di configurazione Redis

Il sottocomando di configurazione
È possibile utilizzare il sottocomando set config con il parametro e il suo valore per impostare il valore di soglia, come mostrato nel seguente. Qui, lo abbiamo impostato come 500 millisecondi.

config set latency-monitor-soglia 500

Modifica dei Redis.Conf File
Possiamo avviare il server Redis fornendo tutte le configurazioni in un file di configurazione chiamato "Redis.conflitto. Nella sezione "Monitor di latenza", è possibile impostare di conseguenza il valore del parametro "Latency-Monitor-soglia".

Si consiglia di riavviare il server Redis dopo aver modificato il file di configurazione.

Il sottocomando grafico latenza

Il comando "Latency" offre diversi sottocampi per recuperare le informazioni sulla latenza basate dagli eventi. Uno dei comandi popolari è "Grafico di latenza". Disegna un grafico contro il tempo in cui è successo l'evento. Questo grafico si basa sui simboli ASCII e varia dal valore minimo di latenza al massimo. I picchi di latenza sono normalizzati tra le latenze min e massime.

Utilizziamo il comando "debug sleep" per verificare come vengono generate le informazioni sul grafico della latenza.

Sintassi

Grafico di latenza

Il parametro "event_name" può essere qualsiasi evento definito dal framework di monitoraggio della latenza Redis, come comando, comando veloce, forcella, ecc.

Esempio 01 - Applicazioni con latenza al di sotto della soglia

Usiamo il comando "Debug Sleep" per generare alcuni picchi di latenza. Andrà a dormire fino al timeout specificato. Poiché la soglia di latenza è di 500 ms, emetteremo comandi di sonno con un timeout inferiore a 500 ms.

Sleep del debug .1
Sleep del debug .2
Sleep del debug .3

Successivamente, emetteremo il comando grafico latenza come mostrato nel seguente:

comando grafico latenza

Ciò genererebbe idealmente il grafico di latenza in stile ASCI per i comandi precedenti. Poiché il tempo di esecuzione del comando è inferiore al valore di soglia in tutti e tre i comandi del "sonno di debug", Redis non genererà picchi di latenza. Se supponiamo che questa sia la nostra applicazione in tempo reale, siete tutti bravi. Non ci sono problemi di latenza allegati.

Produzione:

Come previsto, dice che non sono disponibili campioni per questo particolare evento.

Esempio 02 - Applicazioni con latenza maggiore della soglia

Emettiamo alcuni comandi di debug con un valore di timeout maggiore del valore di soglia. Di solito, è meglio ripristinare tutti i picchi di latenza precedenti prima del set successivo di comandi, come mostrato nei seguenti:

comando di ripristino latenza

Successivamente, emetteremo i comandi del sonno di debug con un valore di timeout di oltre 500 ms.

Sleep del debug .7
Sleep del debug .9
DEBUG SONNO 1

Produzione:

Come previsto, il grafico in stile ASCI è stato generato da Redis. Il "_" indica il valore di latenza più basso e il simbolo "#" indica il picco di latenza più elevato che si è verificato negli ultimi 20 secondi. Questo grafico può essere interpretato in verticale. Ogni colonna è per un evento che si è verificato negli ultimi secondi, minuti o giorni. La colonna più a sinistra può essere interpretata come l'evento che è accaduto 20 secondi fa, il prossimo è successo 14 secondi fa e l'ultima colonna indica un evento che si è verificato 4 secondi fa.

Conclusione

Redis viene utilizzato come archivio di dati per applicazioni in tempo reale. Pertanto, gli aspetti delle prestazioni sono cruciali. Il framework di monitoraggio della latenza è un componente offerto da Redis per monitorare i picchi di latenza per eventi predefiniti. Il "comando grafico latenza" può essere utilizzato per generare i picchi di latenza in stile ASCI per un determinato lasso di tempo. Viene utilizzato per identificare le tendenze di latenza nell'applicazione e intraprendere le azioni necessarie in anticipo. I picchi di latenza verranno generati se il tempo di latenza è maggiore del valore di soglia. Il valore della soglia di latenza potrebbe differire da un'applicazione all'altra in base alla natura.