Gráfico de latencia de Redis

Redis es un almacén de datos en memoria ampliamente utilizado que está bien optimizado para un mayor rendimiento. Su velocidad lo hace útil para aplicaciones en tiempo real, almacenamiento en caché y almacenamiento de sesión. Al mismo tiempo, Redis ofrece varios comandos que son rápidos y optimizados por el rendimiento. Aún así, algunos comandos de Redis toman O (n) complejidad del tiempo más lenta. La naturaleza única de Redis también plantea preocupaciones de latencia. La latencia de Redis se puede clasificar en tres áreas principales: latencia del cliente, latencia de comando y latencia de ida y vuelta.

Latencia del cliente

Redis viene con una arquitectura de cliente cliente. En algunos casos, varios clientes pueden intentar conectarse al servidor Redis simultáneamente. Dado que Redis es un solo hilo, esto presentará una cola de cliente donde el servidor sirve a un proceso de cliente en un momento determinado. Por lo tanto, surgió la latencia de concurrencia. Por lo tanto, los clientes sucesivos pueden necesitar esperar.

Latencia de comando

Cada comando lleva algún tiempo ejecutar. Puede variar de microsegundos a segundos. Por lo tanto, se ha identificado como una fuente de latencia. La mayoría de los comandos de Redis toman complejidad de tiempo constante o logarítmica. Al mismo tiempo, algunos comandos toman o (n) complejidad del tiempo. Son considerablemente más lentos.

Latencia de ida y vuelta

El viaje de ida y vuelta es el tiempo que lleva obtener una respuesta del servidor Redis después de que se haya ejecutado un comando en el lado del cliente. Puede haber diferentes causas para la latencia de ida y vuelta, como la lentitud de la red, las operaciones de la bifurcación y la paginación del sistema operativo.

Monitoreo de latencia de Redis

Las aplicaciones en tiempo real usan Redis, donde el rendimiento es crucial. Por lo tanto, es gratificante tener información sobre la latencia de Redis que serán útiles para tomar medidas por adelantado. De la versión 2.8.13, Redis ha agregado el componente de monitoreo de latencia a su caja de herramientas. Este componente es capaz de registrar picos de latencia por evento o ruta de código específica.

Eventos de latencia o rutas de código

Los eventos de latencia (rutas de código) no son más que las operaciones genéricas o específicas realizadas por REDIS, como comandos genéricos, llamadas al sistema de horquilla y sistemas Unlink. Cuando se trata de los comandos genéricos, hay dos eventos principales definidos por Redis.

1. dominio
2. mando

El evento de "comando rápido" se define para los comandos Redis que tienen O (1) u (log n) complejidad del tiempo, como HSET, HINCRBY, HLEN, etc.

La ruta del código de "comando" mide los picos de latencia para los otros comandos con o (n) complejidad del tiempo.

Habilitando el monitoreo de latencia en Redis Server

Los valores de latencia dependen de la naturaleza de la aplicación. Una aplicación podría considerar 10 milisegundos como alta latencia. Al mismo tiempo, otra aplicación considera 1 segundo como un valor alto. Por lo tanto, Redis le ofrece una opción para definir el umbral de latencia en el servidor. Por defecto, el valor umbral es 0. Hay dos formas de establecer este valor en Redis:

1. Usando el subcomando "Config set" en tiempo de ejecución
2. Modificación del archivo de configuración de Redis

El subcomand de configuración establecido
Puede usar el subcomand de configuración con el parámetro y su valor para establecer el valor umbral, como se muestra en lo siguiente. Aquí lo establecemos como 500 milisegundos.

configurar establecer el umbral de latencia-monitor 500

Modificando el redis.archivo conf
Podemos iniciar el servidor Redis proporcionando todas las configuraciones en un archivo de configuración llamado "Redis.conf ". En la sección "Monitor de latencia", puede establecer el valor del parámetro "Latency-monitor-umbral" en consecuencia.

Se recomienda reiniciar el servidor Redis después de modificar el archivo de configuración.

El subcomando del gráfico de latencia

El comando "Latencia" ofrece varios subcomandos para recuperar la información de latencia basada en eventos. Uno de los comandos populares es el "Gráfico de latencia". Dibuja un gráfico contra el momento en que el evento ha sucedido. Este gráfico se basa en símbolos ASCII y varía del valor de latencia mínimo al máximo. Los picos de latencia se normalizan entre las latencias Min y Max.

Usemos el comando "Depurar el sueño" para verificar cómo se genera la información del gráfico de latencia.

Sintaxis

Gráfico de latencia

El parámetro "Event_Name" puede ser cualquier evento definido por el marco de monitoreo de latencia de Redis, como comando, comando rápido, bifurcación, etc.

Ejemplo 01 - Aplicaciones con latencia por debajo del umbral

Usemos el comando "Sleep de depuración" para generar algunos picos de latencia. Se irá a dormir hasta el tiempo de espera especificado. Dado que el umbral de latencia es de 500 ms, emitiremos comandos de sueño con un tiempo de espera inferior a 500 ms.

Depurar el sueño .1
Depurar el sueño .2
Depurar el sueño .3

A continuación, emitiremos el comando de gráfico de latencia como se muestra en el siguiente:

Comando de gráfico de latencia

Que idealmente generaría el gráfico de latencia de estilo ASCII para los comandos anteriores. Dado que el tiempo de ejecución de comandos es más bajo que el valor umbral en los tres comandos de "sueño de depuración", Redis no generará picos de latencia. Si asumimos que esta es nuestra solicitud en tiempo real, todos están bien. No hay problemas de latencia adjuntos.

Producción:

Como se esperaba, dice que no hay muestras disponibles para este evento en particular.

Ejemplo 02 - Aplicaciones con latencia mayores que el umbral

Emitamos algunos comandos de depuración con un valor de tiempo de espera mayor que el valor umbral. Por lo general, es mejor restablecer todos los picos de latencia anteriores antes del siguiente conjunto de comandos, como se muestra en lo siguiente:

Comando de reinicio de latencia

A continuación, emitiremos los comandos de sueño de depuración con un valor de tiempo de espera de más de 500 ms.

Depurar el sueño .7
Depurar el sueño .9
depurar dormir 1

Producción:

Como se esperaba, el gráfico de estilo ASCII ha sido generado por Redis. El "_" denota el valor de latencia más bajo, y el símbolo "#" denota el pico de latencia más alto que ocurrió en los últimos 20 segundos. Este gráfico se puede interpretar verticalmente. Cada columna es para un evento que ha ocurrido en los últimos segundos, minutos o días. La columna más izquierda se puede interpretar como el evento que ocurrió hace 20 segundos, la siguiente ha sucedido hace 14 segundos, y la última columna denota un evento que ocurrió hace 4 segundos.

Conclusión

Redis se utiliza como un almacén de datos para aplicaciones en tiempo real. Por lo tanto, los aspectos de rendimiento son cruciales. El marco de monitoreo de latencia es un componente ofrecido por Redis para monitorear los picos de latencia para eventos predefinidos. El "comando de gráfico de latencia" se puede usar para generar los picos de latencia de estilo ASCII para un marco de tiempo determinado. Se utiliza para identificar las tendencias de latencia en su aplicación y tomar las acciones necesarias de antemano. Se generarán los picos de latencia si el tiempo de latencia es mayor que el valor umbral. El valor umbral de latencia puede diferir de una aplicación a otra basada en la naturaleza.