Gráfico de latência Redis

Redis é um armazenamento de dados em memória amplamente utilizado que é bem otimizado para um desempenho mais alto. Sua velocidade o torna útil para aplicações em tempo real, armazenamento em cache e sessão. Ao mesmo tempo, Redis oferece vários comandos que são rápidos e otimizados para o desempenho. Ainda assim, alguns comandos Redis tomam a complexidade do tempo mais lento. A natureza de thread única de Redis também levanta preocupações de latência. A latência de Redis pode ser categorizada em três áreas principais: latência do cliente, latência de comando e latência de ida e volta.

Latência do cliente

Redis vem com uma arquitetura cliente-servidor. Em alguns casos, vários clientes podem tentar se conectar ao servidor Redis simultaneamente. Como Redis é um thread único, isso apresentará uma fila de clientes em que o servidor serve um processo de cliente em um determinado momento. Portanto, surgiu a latência de simultaneidade. Portanto, os clientes seguintes podem precisar esperar.

Latência de comando

Cada comando leva algum tempo para executar. Pode variar de microssegundo a segundos. Portanto, foi identificado como uma fonte de latência. A maioria dos comandos Redis toma complexidade do tempo constante ou logarítmico. Ao mesmo tempo, alguns comandos levam a (n) complexidade do tempo. Eles são consideravelmente mais lentos.

Latência de ida e volta

Ida e volta é o tempo que leva para obter uma resposta do servidor Redis depois que um comando foi executado no lado do cliente. Pode haver causas diferentes para latência de ida e volta, como lentidão de rede, operações de garfo e paginação.

Monitoramento de latência Redis

As aplicações em tempo real usam redis, onde o desempenho é crucial. Portanto, é gratificante ter informações sobre a latência de Redis que serão úteis para tomar medidas com antecedência. Da versão 2.8.13, Redis adicionou o componente de monitoramento de latência à sua caixa de ferramentas. Este componente é capaz de gravar picos de latência por evento ou caminho de código específico.

Eventos de latência ou caminhos de código

Os eventos de latência (caminhos de código) nada mais são do que as operações genéricas ou específicas realizadas pela Redis, como comandos genéricos, chamadas do sistema de garfo e sistemas desvinculados. Quando se trata dos comandos genéricos, há dois eventos principais definidos por Redis.

1. comando
2. comando rápido

O evento "Fast-Command" é definido para comandos Redis que possuem complexidade do tempo O (1) ou O (log n), como hset, hincrby, hlen, etc.

O caminho do código de "comando" mede os picos de latência para os outros comandos com a (n) complexidade do tempo.

Ativando o monitoramento de latência no servidor Redis

Os valores de latência dependem da natureza do aplicativo. Um aplicativo pode considerar 10 milissegundos como alta latência. Ao mesmo tempo, outro aplicativo considera 1 segundo como um valor alto. Portanto, Redis oferece a opção para definir o limite de latência no servidor. Por padrão, o valor limite é 0. Existem duas maneiras de definir esse valor em Redis:

1. Usando o subcomando "Config Set" em tempo de execução
2. Modificando o arquivo de configuração Redis

O subcomando do conjunto de configurações
Você pode usar o subcomando de configuração de configuração com o parâmetro e seu valor para definir o valor limite, conforme mostrado no seguinte. Aqui, definimos como 500 milissegundos.

Conjunto de configuração Latência-Monitor-Trinda 500

Modificando os redis.arquivo conf
Podemos iniciar o servidor Redis, fornecendo todas as configurações em um arquivo de configuração chamado “Redis.conf ”. Na seção "Monitor de Latência", você pode definir o valor do parâmetro "Latência-Monitor-Limite" de acordo.

Recomenda -se reiniciar o servidor Redis após modificar o arquivo de configuração.

O subcomando do gráfico de latência

O comando "Latência" oferece vários subcomandos para recuperar informações de latência baseadas em eventos. Um dos comandos populares é o "gráfico de latência". Ele desenha um gráfico contra o tempo em que o evento aconteceu. Este gráfico é baseado em símbolos ASCII e varia do valor mínimo de latência ao máximo. Os picos de latência são normalizados entre as latências min e max.

Vamos usar o comando "Debug Sleep" para verificar como as informações do gráfico de latência são geradas.

Sintaxe

Gráfico de latência

O parâmetro "Event_Name" pode ser qualquer evento definido pela estrutura de monitoramento de latência Redis, como comando, comando rápido, garfo, etc.

Exemplo 01 - Aplicativos com latência abaixo do limite

Vamos usar o comando "Debug Sleep" para gerar alguns picos de latência. Ele vai dormir até o tempo limite especificado. Como o limite de latência é de 500 ms, emitiremos comandos do sono com um tempo limite inferior a 500 ms.

Debug Sleep .1
Debug Sleep .2
Debug Sleep .3

Em seguida, emitiremos o comando Graph de latência, conforme mostrado no seguinte:

Comando de gráfico de latência

Idealmente, isso geraria o gráfico de latência do estilo ASCII para os comandos anteriores. Como o tempo de execução do comando é menor que o valor limite em todos os três comandos de "Sleep de depuração", Redis não gera picos de latência. Se assumirmos que este é o nosso aplicativo em tempo real, você é bom. Não há problemas de latência anexados.

Saída:

Como esperado, diz que nenhuma amostra está disponível para este evento em particular.

Exemplo 02 - Aplicações com latência maior que o limite

Vamos emitir alguns comandos de depuração com um valor de tempo limite maior que o valor limite. Geralmente, é melhor redefinir todos os picos de latência anterior antes do próximo conjunto de comandos, conforme mostrado no seguinte:

Comando de redefinição de latência

Em seguida, emitiremos os comandos do Sleep Debug com um valor de tempo limite de mais de 500 ms.

Debug Sleep .7
Debug Sleep .9
Debug Sleep 1

Saída:

Como esperado, o gráfico de estilo ASCII foi gerado por Redis. O "_" indica o menor valor de latência, e o símbolo "#" indica o maior pico de latência que ocorreu nos últimos 20 segundos. Este gráfico pode ser interpretado verticalmente. Cada coluna é para um evento que ocorreu nos últimos segundos, minutos ou dias. A coluna mais à esquerda pode ser interpretada como o evento que aconteceu há 20 segundos, o próximo aconteceu há 14 segundos, e a última coluna indica um evento que ocorreu há 4 segundos.

Conclusão

Redis é usado como um armazenamento de dados para aplicativos em tempo real. Portanto, os aspectos de desempenho são cruciais. A estrutura de monitoramento de latência é um componente oferecido pela Redis para monitorar os picos de latência para eventos predefinidos. O "comando de grafto de latência" pode ser usado para gerar os picos de latência no estilo ASCII para um determinado prazo. É usado para identificar as tendências de latência em seu aplicativo e tomar as ações necessárias com antecedência. Os picos de latência serão gerados se o tempo de latência for maior que o valor limite. O valor do limite de latência pode diferir de um aplicativo para outro com base na natureza.