Perguntas frequentes sobre o gerenciamento do Azure Managed Redis (visualização)

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

• 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.
• O Redis funciona melhor com valores menores, portanto, considere dividir dados maiores em várias chaves. Na 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

• 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 Azure Managed Redis 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

• Consulte Testes de desempenho com o Azure Managed Redis , por exemplo, benchmarks e instruções para executar seus próprios testes de desempenho no Azure Managed Redis.

• 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. Cada fragmento Redis é um single-threaded 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 sã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.
• Consulte Testes de desempenho com o Azure Managed Redis , por exemplo, benchmarks e instruções para executar seus próprios testes de desempenho no Azure Managed Redis.

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) atinge o número "mínimo" de threads, o ThreadPool limita a taxa na qual injeta novos threads em um thread a cada 500 milissegundos. Normalmente, se o seu sistema recebe uma explosão de trabalho precisando de um thread IOCP, ele processa 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 veria 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 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 à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 com quatro 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 com quatro 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

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 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 exceda 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 Azure Managed 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 Azure Managed Redis.