Perguntas frequentes sobre o gerenciamento do Redis Gerenciado do Azure

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.
• 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.
• Defina as configurações do ThreadPool para evitar tempos limite.
• 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 repetição, 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 CLR tem dois tipos de threads : threads iocp ( porta de conclusão de E/S e trabalho).

• 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 os threads min, você provavelmente está pagando um atraso de 500 ms antes que o aplicativo processe o tráfego de rede. 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. Consulte os detalhes do IOCP e do WORKER mais adiante no artigo.

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, você vê que para o thread IOCP há seis threads ocupados e o sistema está configurado para permitir quatro threads mínimos. Nesse caso, o cliente obteria dois atrasos de 500 ms, porque 6 > 4.

Recomendação

Recomendamos que os clientes definam o valor mínimo de configuração para threads IOCP e WORKER como algo maior que o valor padrão. Não podemos fornecer orientação de tamanho único sobre 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. Cada cliente precisa ajustar essa configuração às suas necessidades específicas. Um bom ponto de partida é 200 ou 300, para testar e ajustar conforme necessário.

Como definir essa configuração:

Recomendamos alterar essa configuração programaticamente usando o método ThreadPool.SetMinThreads (...) em aplicativos .NET Framework e .NET Core.

Por exemplo, no NET Framework, você o Global.asax.cs define no Application_Start método:

```csharp
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);
}
```

Se você estiver usando o .NET Core, configure-o Program.csantes da chamada para WebApplication.CreateBuilder():

```csharp
const int minThreads = 200
              
ThreadPool.SetMinThreads(minThreads, minThreads);

var builder = WebApplication.CreateBuilder(args);
// rest of application setup
```

Também é possível especificar a configuração mínima de threads usando a configuração ou minIoThreads a minWorkerThreadsconfiguração no <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 de todo o sistema. Se você definir dessa forma, será necessário reiniciar o pool de aplicativos.

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
• Fundamentos da 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é algum número de conexões, cada conexão com o Redis tem sobrecarga associada a ele. 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.

Conteúdo relacionado

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