FAQs de gestão da Cache do Azure para Redis

O servidor Redis não suporta nativamente TLS, mas o Cache Redis do Azure suporta. Se você estiver se conectando ao Cache Redis do Azure e seu cliente oferecer suporte a TLS, como StackExchange.Redis, use TLS.

Ferramentas Redis, como redis-cli não funcionam com a porta TLS, mas você pode usar um utilitário como stunnel conectar com segurança as ferramentas à porta TLS seguindo as instruções na postagem do blog Anunciando o Provedor de Estado da Sessão do ASP.NET para a Versão de Visualização do Redis.

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

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

Práticas recomendadas do StackExchange.Redis

• Defina AbortConnect como false e, em seguida, deixe o ConnectionMultiplexer se reconectar automaticamente.
• Use uma única instância de longa duração ConnectionMultiplexer em vez de criar uma nova conexão para cada solicitação. Para obter um exemplo de como gerenciar uma conexão, consulte a RedisConnection classe em Conectar ao cache com Redisconnection.
• O Redis funciona melhor com valores menores, portanto, considere dividir dados maiores em várias chaves. Nesta discussão do Redis, 100 kb é considerado grande. Para obter mais informações, consulte Desenvolvimento de práticas recomendadas.
• Configure as configurações do ThreadPool para evitar tempos limites.
• Use pelo menos o padrão connectTimeout de 5 segundos. Esse intervalo dá ao StackExchange.Redis tempo suficiente para restabelecer a conexão se houver um blip de rede.
• Esteja ciente dos custos de desempenho associados às diferentes operações que você está executando. Por exemplo, o KEYS comando é uma operação O(n) e deve ser evitado. O site redis.io tem detalhes sobre a complexidade de tempo para cada operação suportada. Selecione cada comando para ver a complexidade de cada operação.

Configuração e conceitos

• Use o nível Standard ou Premium para sistemas de produção. O Escalão Básico é um sistema de nó único sem replicação de dados e sem SLA. Além disso, utilize pelo menos uma cache C1. Os caches C0 são normalmente usados para cenários simples de desenvolvimento/teste.
• Lembre-se de que o Redis é um armazenamento de dados In-Memory . Para obter mais informações, consulte Solucionar problemas de perda de dados no Cache Redis do Azure para que você esteja ciente dos 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 por patches e failover.

Testes de desempenho

• Comece usando redis-benchmark.exe para ter uma ideia da taxa de transferência possível antes de escrever seus próprios testes de desempenho. Como redis-benchmark não oferece suporte a TLS, você deve habilitar a porta Não TLS por meio do portal do Azure antes de executar o teste. Para obter exemplos, consulte Como posso comparar e testar o desempenho do meu cache?
• A VM cliente usada para teste deve estar na mesma região que sua instância do Cache do Azure para Redis.
• Recomendamos o uso da série Dv2 VM para o seu cliente, pois eles têm melhor hardware e devem dar os melhores resultados.
• Verifique se a VM cliente escolhida tem pelo menos tanta capacidade de computação e largura de banda quanto o cache que você está testando.
• Habilite o VRSS na máquina cliente se estiver no Windows. Veja aqui os detalhes.
• As instâncias Redis de camada Premium têm melhor latência e taxa de transferência de rede porque são executadas em hardware melhor para CPU e Rede.

• Evite usar certos comandos Redis que levam muito tempo para serem concluídos, a menos que você entenda completamente o resultado desses comandos. Por exemplo, não execute o comando KEYS na produção. Dependendo do número de chaves, pode levar muito tempo para retornar. O Redis é um servidor de thread único e processa comandos um de cada vez. Se você tiver outros comandos emitidos após KEYS, eles não serão processados até que o Redis processe o comando KEYS. O site redis.io tem detalhes sobre a complexidade de tempo para cada operação suportada. Selecione cada comando para ver a complexidade de cada operação.
• Tamanhos de chave - devo usar chaves/valores pequenos ou chaves/valores grandes? Depende do cenário. Se o cenário exigir chaves maiores, você poderá ajustar o ConnectionTimeout, repetir valores e ajustar a lógica de repetição. Da perspetiva do servidor Redis, os valores mais pequenos proporcionam um melhor desempenho.
• Essas considerações não significam que você não possa armazenar valores maiores no Redis; Você deve estar ciente das seguintes considerações. 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 novas tentativas, conforme descrito na seção anterior O que fazem as opções de configuração do StackExchange.Redis.

• Ativar o diagnóstico da cache para poder monitorizar o estado de funcionamento da cache. Pode ver as métricas no portal do Azure e transferi-las e revê-las com as ferramentas da sua escolha.
• Você pode usar redis-benchmark.exe para carregar o teste do seu servidor Redis.
• Verifique se o cliente de teste de carga e o Cache Redis do Azure estão na mesma região.
• Use redis-cli.exe e monitore o cache usando o comando INFO.
• Se a carga estiver causando alta fragmentação de memória, você deverá dimensionar para um tamanho de cache maior.
• Para obter instruções sobre como baixar as ferramentas Redis, consulte a seção Como posso executar comandos Redis?

Aqui estão alguns exemplos de uso de redis-benchmark.exe. Execute esses comandos a partir de uma VM na mesma região do cache para obter results.cache-development-faq.yml precisos

• Testar solicitações SET canalizadas usando uma carga útil de 1k

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

• Teste solicitações GET canalizadas usando uma carga útil de 1k.

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

O CLR ThreadPool tem dois tipos de threads - threads "Worker" e "I/O Completion Port" (IOCP).

• Os threads de trabalho são usados para coisas como processar o Task.Run(…), ou ThreadPool.QueueUserWorkItem(…) métodos. Esses threads também são usados por vários componentes no CLR quando o trabalho precisa acontecer em um thread em segundo plano.
• Os threads IOCP são usados quando a E/S assíncrona acontece, como ao ler a partir da rede.

O pool de threads fornece novos threads de trabalho ou threads de conclusão de E/S sob demanda (sem qualquer limitação) até atingir a configuração "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.

Quando o número de threads existentes (ocupados) atingir o número "mínimo" de threads, o ThreadPool limitará a taxa na qual injeta novos threads em um thread a cada 500 milissegundos. Normalmente, se o seu sistema receber uma explosão de trabalho precisando de um thread IOCP, ele processará esse trabalho rapidamente. No entanto, se o burst for maior do que a configuração "Mínimo" configurada, haverá algum atraso no processamento de parte do trabalho, pois o ThreadPool aguarda uma das duas possibilidades:

• Um thread existente torna-se livre para processar o trabalho.
• Nenhum thread existente fica livre por 500 ms e um novo thread é criado.

Basicamente, quando o número de threads ocupados é maior do que os threads Min, 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 encolhimento pode se repetir.

Se olharmos para um exemplo de mensagem de erro do StackExchange.Redis (build 1.0.450 ou posterior), veremos que ele agora imprime estatísticas do ThreadPool. Veja os detalhes do IOCP e do TRABALHADOR 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)

Como mostrado no exemplo, você vê que para thread IOCP há seis threads ocupados e o sistema está configurado para permitir quatro threads mínimos. Neste caso, o cliente provavelmente teria visto dois atrasos de 500 ms, porque 6 > 4.

Recomendação

Dadas essas informações, é altamente recomendável que os clientes definam o valor mínimo de configuração para threads IOCP e WORKER para algo maior do que o valor padrão. Não podemos fornecer uma orientação única sobre qual deve ser esse valor, porque o valor certo 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 às suas necessidades específicas. Um bom ponto de partida é 200 ou 300, depois teste e ajuste conforme necessário.

Como definir essa configuração:

• Recomendamos alterar essa configuração programaticamente usando o método ThreadPool.SetMinThreads (...) em 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);
  }
  

  Nota

  O valor especificado por esse método é uma configuração global, afetando todo o AppDomain. Por exemplo, se você tiver uma máquina de 4 núcleos e quiser 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 mínima de threads usando a configuração minIoThreads ou minWorkerThreads sob o <processModel> elemento de configuração em Machine.config. Machine.config normalmente está localizado em %SystemRoot%\Microsoft.NET\Framework\[versionNumber]\CONFIG\. Definir o número mínimo de threads dessa maneira não é recomendado porque é uma configuração em todo o sistema.

  Nota

  O valor especificado neste elemento de configuração é uma configuração por núcleo . Por exemplo, se você tiver uma máquina de 4 núcleos e quiser que sua configuração minIoThreads seja 200 em tempo de execução, você usaria <processModel minIoThreads="50"/>.

Habilitar o GC do servidor pode otimizar o cliente e fornecer melhor desempenho e taxa de transferência ao usar o StackExchange.Redis. Para obter mais informações sobre o GC do servidor e como habilitá-lo, consulte os seguintes artigos:

• Para habilitar o GC do servidor
• Fundamentos da Recolha de Lixo
• Recolha de Lixo e Desempenho

Cada camada 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 certo número de conexões, cada conexão com o Redis tem sobrecarga associada a ele. Um exemplo dessa sobrecarga seria o uso de CPU e memória por causa da criptografia TLS/SSL. O limite máximo de conexão para um determinado tamanho de cache pressupõe um cache levemente carregado. Se a carga da sobrecarga de conexão mais a carga das operações do cliente excederem a capacidade do sistema, o cache poderá enfrentar problemas de capacidade, mesmo que você não tenha excedido o limite de conexão para o tamanho atual do cache.

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

Próximos passos

Saiba mais sobre outras perguntas frequentes do Cache do Azure para Redis.