Perguntas frequentes sobre o gerenciamento do Redis gerenciado do Azure (versão prévia)

O uso do TLS é recomendado como uma melhor prática em praticamente todos os casos de uso do Redis. A opção de se conectar sem o TLS está incluída para fins de compatibilidade com versões anteriores.

• 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. Para obter um exemplo de como gerenciar uma conexão, confira a classe RedisConnection em Conectar-se ao cache com RedisConnection.
• O Redis funciona melhor com valores menores, portanto, considere talhar dados maiores em várias chaves. Na 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

• 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 no Redis gerenciado do Azure para que você saiba em quais cenários 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

• Consulte o Teste de desempenho no Redis gerenciado do Azure para obter exemplos de parâmetros de comparação e instruções para executar seus próprios testes de desempenho no Redis gerenciado do Azure.

• 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. Cada extensão do Redis tem um 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 são mais altas. 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.
• Consulte o Teste de desempenho no Redis gerenciado do Azure para obter exemplos de parâmetros de comparação e instruções para executar seus próprios testes de desempenho no Redis gerenciado do Azure.

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 limita a taxa à qual injeta novos threads em um thread por 500 milissegundos. Geralmente, se o 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 obteria 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 pode 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ê tem um computador com quatro núcleos e desejar definir 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 definição de 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ê tiver um computador com quatro núcleos e desejar que sua configuração de minIoThreads seja de 200 no runtime, você usará <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

SKUs diferentes podem ter 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 de serviço, consulte preços do Redis gerenciado do Azure. 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

Saiba mais sobre outras perguntas frequentes sobre Redis Gerenciados do Azure.