Perguntas frequentes sobre o gerenciamento do Cache do Azure para Redis

O servidor do Redis não dá suporte nativo ao TLS, mas o Cache do Azure para Redis, sim. Se você estiver se conectando ao Cache do Azure para Redis, e seu cliente der suporte ao TLS, como o StackExchange.Redis, você deverá usar o TLS.

Ferramentas do Redis como o redis-cli não funcionam com a porta TLS, mas você pode usar um utilitário como stunnel para conectar as ferramentas com segurança à porta TLS seguindo as instruções na postagem no blog Anúncio do provedor de estado de sessão ASP.NET para a versão prévia do Redis.

Para obter instruções sobre como baixar as ferramentas do Redis, consulte a seção Como posso executar comandos do Redis?

• Práticas recomendadas do StackExchange.Redis
• Configuração e conceitos
• Testes de desempenho

Práticas recomendadas do StackExchange.Redis

• Defina AbortConnect como false e deixe o ConnectionMultiplexer se reconectar automaticamente.
• Use uma única instância ConnectionMultiplexer de longa duração em vez de criar uma nova conexão para cada solicitação.
• O Redis funciona melhor com valores menores, portanto, considere talhar dados maiores em várias chaves. Nesta discussão do Redis, 100 KB é considerado grande. Para obter mais informações, consulte Melhores práticas para a pesquisa.
• Configure suas configurações de ThreadPool para evitar tempos limites.
• Use pelo menos o connectTimeout padrão de 5 segundos. Esse intervalo dá ao StackExchange.Redis tempo suficiente para restabelecer a conexão caso ocorra um blip de rede.
• Lembre-se dos custos de desempenho associados a operações diferentes que você está executando. Por exemplo, o KEYS comando é uma operação O(n) e deve ser evitado. O site redis.io apresenta detalhes sobre a complexidade de tempo para cada operação a qual ele dá suporte. Selecione cada comando para ver a complexidade para cada operação.

Configuração e conceitos

• Use as camadas Standard ou Premium para Sistemas de Produção. A camada Básica é um sistema de nó único sem replicação de dados e sem SLA. Além disso, use pelo menos um cache C1. Caches C0 normalmente são usados para cenários de desenvolvimento/teste simples.
• Lembre-se de que o Redis é um armazenamento de dados na memória . Para obter mais informações, consulte Solucionar problemas de perda de dados em Cache do Azure para Redis para que você esteja ciente de cenários em que a perda de dados pode ocorrer.
• Desenvolva seu sistema, de modo que ele possa lidar com blips de conexão causados pela aplicação de patch e pelo failover.

Testes de desempenho

• Comece usando redis-benchmark.exe para ter uma ideia de taxa de transferência possível antes de escrever seus próprios testes de desempenho. Como redis-benchmark não dá suporte ao TLS, você precisa habilitar a porta não TLS no portal do Azure antes de executar o teste. Por exemplo, consulte Como medir e testar o desempenho do meu cache?
• A VM do cliente usada para testes deve estar na mesma região que a instância do Cache do Azure para Redis.
• É recomendável usar a Série de VM Dv2 série para o cliente, pois ela tem hardware melhor e deve oferecer melhores resultados.
• Verifique se a VM do cliente escolhida tem ao menos a quantidade de computação e funcionalidade de largura de banda de cache que você está testando.
• Habilite o VRSS no computador cliente, se você estiver usando o Windows. Consulte aqui para obter detalhes.
• As instâncias do Redis de camada Premium têm melhor latência de rede e taxa de transferência porque estão em execução tanto para a CPU quanto para a Rede.

• Evite usar determinados comandos do Redis que demoram muito para serem concluídos, a menos que você entenda bem o resultado desses comandos. Por exemplo, não execute o comando KEYS em produção. Dependendo do número de chaves, o retorno pode levar muito tempo. O Redis é um servidor de thread único e processa um comando por vez. Se você tiver outros comandos após KEYS, eles não serão processados até que o Redis processe o comando KEYS. O site redis.io apresenta detalhes sobre a complexidade de tempo para cada operação a qual ele dá suporte. Selecione cada comando para ver a complexidade para cada operação.
• Tamanhos de chave - devo usar valores pequenos ou grandes de chave? Depende do cenário. Se seu cenário exigir chaves maiores, você poderá ajustar o ConnectionTimeout e, depois, repetir os valores e ajustar sua lógica de repetição de tentativas. Da perspectiva do servidor Redis, valores menores apresentam um desempenho melhor.
• Essas considerações não significam que você não pode armazenar valores maiores em Redis, mas que deve estar ciente das considerações a seguir. As latências serão maiores. Se você tiver um conjunto de dados maior e outro menor, poderá usar várias instâncias do ConnectionMultiplexer. Configure cada um com um conjunto diferente de valores de tempo limite e nova tentativa, conforme descrito na seção anterior O que as opções de configuração StackExchange.Redis fazem.

• Habilite o diagnóstico de cache para que você possa monitorar a integridade do cache. Você pode exibir as métricas no portal do Azure e também pode baixá-las e analisá-las usando as ferramentas de sua escolha.
• Você pode usar o redis-benchmark.exe para testar a carga em seu servidor do Redis.
• Verifique se o cliente de teste de carga e o Cache do Azure para Redis estão na mesma região.
• Use o redis cli.exe e monitore o cache usando o comando INFO.
• Se sua carga está causando um nível elevado de fragmentação de memória, você deve escalar verticalmente para um tamanho de cache maior.
• Para obter instruções sobre como baixar as ferramentas do Redis, consulte a seção Como posso executar comandos do Redis?

Estes são alguns exemplos de como usar redis-benchmark.exe. Execute esses comandos de uma VM na mesma região que o cache para resultados precisos.cache-development-faq.yml

• Teste solicitações SET de Pipeline usando um conteúdo de 1k

  redis-benchmark.exe -h **yourcache**.redis.cache.windows.net -a **yourAccesskey** -t SET -n 1000000 -d 1024 -P 50

• Solicitações GET de Pipelined usando uma conteúdo de 1k.

redis-benchmark.exe -h **yourcache**.redis.cache.windows.net -a **yourAccesskey** -t GET -n 1000000 -d 1024 -P 50

O ThreadPool do CLR tem dois tipos de threads: "Trabalho" e "Porta de conclusão E/S" (IOCP).

• Os threads de trabalho são usados em situações como o processamento dos métodos Task.Run(…) ou ThreadPool.QueueUserWorkItem(…). Esses threads também são usados por vários componentes no CLR quando o trabalho precisa ser executado em um thread em segundo plano.
• Os threads IOCP são usados quando há E/S assíncrona, como durante a leitura da rede.

O pool de threads fornece novos threads de trabalho ou de conclusão de E/S sob demanda (sem qualquer limitação) até atingir a configuração de "Mínimo" para cada tipo de thread. Por padrão, o número mínimo de threads é definido como o número de processadores em um sistema.

Depois que o número de threads existentes (ocupados) atinge o número "mínimo" de threads, o ThreadPool limitará a taxa à qual injeta novos threads em um thread por 500 milissegundos. Geralmente, se seu sistema obtiver um pico de trabalho que precisa de um thread IOCP, ele processará esse trabalho rapidamente. No entanto, se a intermitência for maior que a configuração "Mínimo", haverá algum atraso no processamento do trabalho, já que o ThreadPool aguardará uma destas duas possibilidades:

• Um thread existente ficar livre para processar o trabalho.
• Nenhum thread existente ficar livre por 500 ms e um thread for criado.

Basicamente, quando o número de threads ocupados é maior que o mínimo de threads, você provavelmente está pagando um atraso de 500 ms antes que o tráfego de rede seja processado pelo aplicativo. Além disso, quando um thread existente permanece ocioso por mais de 15 segundos, ele é limpo e esse ciclo de crescimento e redução pode ser repetido.

Se examinarmos um exemplo de mensagem de erro do StackExchange.Redis (build 1.0.450 ou posterior), veremos agora que ela imprime estatísticas de ThreadPool. Confira os detalhes de IOCP e TRABALHO abaixo.

System.TimeoutException: Timeout performing GET MyKey, inst: 2, mgr: Inactive,
queue: 6, qu: 0, qs: 6, qc: 0, wr: 0, wq: 0, in: 0, ar: 0,
IOCP: (Busy=6,Free=994,Min=4,Max=1000),
WORKER: (Busy=3,Free=997,Min=4,Max=1000)

Conforme mostrado no exemplo anterior, você pode ver que, para o thread IOCP, há seis threads ocupados, e o sistema está configurado para permitir o mínimo de quatro threads. Nesse caso, o cliente provavelmente veria dois atrasos de 500 ms porque 6 > 4.

Recomendação

Dadas essas informações, recomendamos fortemente que os clientes definam o valor de configuração mínima para threads de TRABALHO e IOCP com um valor maior que o valor padrão. Não podemos dar uma orientação que sirva para todos sobre esse valor porque o valor correto para um aplicativo provavelmente será muito alto ou baixo para outro aplicativo. Essa configuração também pode afetar o desempenho de outras partes de aplicativos complicados; portanto, cada cliente precisa ajustar essa configuração para as próprias necessidades específicas. Um bom ponto de partida é 200 ou 300, para testar e ajustar conforme necessário.

Como definir essa configuração:

• É recomendável alterar essa configuração programaticamente usando o método ThreadPool.SetMinThreads (...) no global.asax.cs. Por exemplo:

  private readonly int minThreads = 200;
  void Application_Start(object sender, EventArgs e)
  {
      // Code that runs on application startup
      AreaRegistration.RegisterAllAreas();
      RouteConfig.RegisterRoutes(RouteTable.Routes);
      BundleConfig.RegisterBundles(BundleTable.Bundles);
      ThreadPool.SetMinThreads(minThreads, minThreads);
  }
  

  Observação

  O valor especificado por esse método é uma configuração global que afeta todo o AppDomain. Por exemplo, se você tiver um computador com quatro núcleos e desejar definir as configurações minWorkerThreads e minIoThreads como 50 por CPU durante o tempo de execução, use ThreadPool.SetMinThreads (200, 200).

• Também é possível especificar a configuração de threads mínimos usando a configuração minIoThreads ou minWorkerThreads no elemento de configuração <processModel> no Machine.config. Machine.config normalmente está localizado em %SystemRoot%\Microsoft.NET\Framework\[versionNumber]\CONFIG\. Definir o número de threads mínimos assim não é recomendado, pois é uma configuração de todo o sistema.

  Observação

  O valor especificado nesse elemento de configuração é uma configuração por núcleo. Por exemplo, se você tivesse um computador com quatro núcleos e desejar que sua configuração minIoThreads seja de 200 no runtime, usaria <processModel minIoThreads="50"/>.

Habilitar a GC do servidor pode otimizar o cliente e proporcionar melhor desempenho e produtividade ao usar o Stackexchange.Redis. Para saber mais sobre a GC do servidor e como habilitá-la, confira os artigos a seguir:

• Para habilitar a GC (coleta de lixo) do servidor
• Noções básicas sobre a coleta de lixo
• Coleta de lixo e desempenho

Cada tipo de preço tem limites diferentes para conexões de cliente, memória e largura de banda. Embora cada tamanho de cache permita até um determinado número de conexões, cada conexão com o Redis tem sobrecarga associadas. Um exemplo de tal sobrecarga seria o uso da CPU e de memória devido à criptografia TLS/SSL. O limite máximo de conexão para um tamanho de cache determinado pressupõe um cache com pouca carga. Se a carga da conexão de sobrecarga, mais a carga de operações do cliente, exceder a capacidade do sistema, o cache poderá enfrentar problemas de capacidade mesmo se não exceder o limite de conexão para o tamanho atual do cache.

Para obter mais informações sobre os limites de conexões diferentes para cada camada, consulte preços do Cache do Azure para Redis. Para obter mais informações sobre as conexões e outras configurações padrão, consulte configuração do servidor padrão Redis.

Próximas etapas

Confira outras Perguntas frequentes do Cache do Azure para Redis.