Perguntas frequentes sobre gerenciamento de cache

Este artigo fornece respostas a perguntas comuns sobre como gerenciar o Cache do Azure para Redis.

Importante

O Cache do Azure para Redis anunciou seu cronograma de desativação para todas as SKUs. Recomendamos mover as suas instâncias existentes do Azure Cache para Redis para Azure Managed Redis o mais rápido possível.

Para mais detalhes sobre a aposentadoria:

• Cache do Azure para Aposentadoria Redis: o que saber e como preparar
• Perguntas frequentes sobre a descontinuação do Cache do Azure para Redis

Como posso comparar e testar o desempenho do meu cache?

• Use redis-benchmark.exe para carregar o teste do seu servidor Redis. Use redis-benchmark.exe para ter uma ideia da taxa de transferência possível antes de escrever seus próprios testes de desempenho.
• Use redis-cli para monitorar o cache usando o INFO comando. Para obter instruções sobre como baixar as ferramentas Redis, consulte Como posso executar comandos Redis?
• Se você usar Transport Layer Security/Secure Socket Layer (TLS/SSL) em sua instância de cache, adicione o --tls parâmetro aos comandos das ferramentas Redis ou use um proxy como stunnel para habilitar TLS/SSL.
• Redis-benchmark usa porta 6379 por padrão. Use o -p parâmetro para substituir essa configuração se o cache usar a porta 6380 SSL/TLS ou a porta 10000da camada Enterprise.
• Se necessário, você pode habilitar a porta não-TLS por meio do portal do Azure antes de executar o teste de carga.
• Verifique se a máquina virtual (VM) cliente que você usa para teste está na mesma região que sua instância do Cache do Azure para Redis.
• Certifique-se de que sua VM cliente tenha pelo menos tanta capacidade de computação e largura de banda quanto o cache que você está testando. Para obter melhores resultados, use VMs das séries D e E para seus clientes.
• Se você estiver no Windows, habilite o VRSS (Virtual Receive-side Scaling) na máquina cliente. Para obter mais informações, consulte Virtual Receive-side Scaling in Windows Server 2012 R2.
• 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 baixar e revisar suas métricas usando as ferramentas de sua escolha.
• Se a carga estiver causando alta fragmentação de memória, aumente a escala para um tamanho de cache maior.

Os exemplos a seguir mostram como usar redis-benchmark.exeo . Execute esses comandos a partir de uma VM na mesma região do cache para obter resultados precisos.

Primeiro, teste solicitações canalizadas SET 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

Depois de executar o SET teste, execute solicitações canalizadas GET 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

Como posso habilitar o GC do servidor para obter mais taxa de transferência no cliente ao usar o StackExchange.Redis?

Habilitar a coleta de lixo do servidor (GC) pode otimizar o cliente e fornecer melhor desempenho e taxa de transferência quando você usa o StackExchange.Redis. Para obter mais informações sobre o GC do servidor e como habilitá-lo, consulte os seguintes artigos:

• O <elemento gcServer>
• Fundamentos da coleta de lixo
• Recolha de lixo e desempenho

Devo habilitar a porta não-TLS/SSL para me conectar ao Redis?

O servidor Redis não suporta nativamente TLS (Transport Layer Security), mas o Cache Redis do Azure dá suporte a TLS. Se você se conectar ao Cache Redis do Azure com um cliente como StackExchange.Redis que dá suporte a TLS, use TLS.

Nota

A porta não-TLS é desabilitada por padrão para novas instâncias do Azure Redis. Se o seu cliente não suportar TLS, habilite a porta não-TLS seguindo as instruções em Portas de acesso.

Se o cache usa TLS, você deve habilitar o TLS usando a --tls opção para ferramentas Redis como redis-cli. Você também 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 ASP.NET Session State Provider for Redis Preview Release .

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

Quais são algumas considerações para o uso de comandos comuns do 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. O Redis é um servidor de thread único que processa comandos um de cada vez. Se você executar o comando, o KEYS Redis não processará os comandos subsequentes até concluir o processamento do KEYS comando.

  O site redis.io tem detalhes de complexidade de tempo para cada operação suportada. Selecione cada comando para ver a complexidade de cada operação.

• O tamanho das chaves a serem usadas depende do cenário. Se o cenário exigir chaves maiores, você poderá ajustar os valores de repetição e ajustar a ConnectionTimeoutlógica de repetição. Do ponto de vista do servidor Redis, valores de chave menores proporcionam melhor desempenho.

• Essas considerações não significam que você não possa armazenar valores maiores no Redis, mas as latências são maiores. Se você tiver um conjunto de dados maior que outro, poderá usar várias ConnectionMultiplexer instâncias, cada uma configurada com um conjunto diferente de valores de tempo limite e de novas tentativas. Para obter mais informações, consulte O que fazem as opções de configuração do StackExchange.Redis?

Quais são algumas considerações de desempenho para conexões?

Cada camada de preço do Cache do Azure para Redis 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 envolve sobrecarga associada. Um exemplo dessa sobrecarga é 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 limites de conexão 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.

Quais são algumas das melhores práticas de produção?

• Use o nível Standard ou Premium para sistemas de produção. A camada básica é um sistema de nó único sem replicação de dados e sem contrato de nível de serviço (SLA). Além disso, use pelo menos um cache C1 para produção. Os caches C0 são normalmente usados para cenários simples de desenvolvimento/teste.
• Lembre-se de que o Redis é um armazenamento de dados na memória e a perda de dados pode ocorrer em alguns cenários. Para obter mais informações, consulte Solucionar problemas de perda de dados no Cache do Azure para Redis.
• Desenvolva seu sistema para que ele possa lidar com falhas de conexão causadas por patches e failover.
• Use instâncias Redis do Azure de camada Premium para melhor latência e taxa de transferência de rede, porque elas têm melhor hardware para CPU e rede.

Práticas recomendadas do StackExchange.Redis

• Defina AbortConnect como false e, em seguida, deixe a ConnectionMultiplexer reconexão 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. Por exemplo, em Qual é a faixa de tamanho de valor ideal para redis?, 100 kb é considerado grande. Para obter mais informações, consulte Considerar mais chaves e valores menores.
• 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ê executa. 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 de cada operação suportada. Selecione cada comando para ver a complexidade de cada operação.

Detalhes importantes sobre o crescimento do ThreadPool

O Common Language Runtime (CLR) ThreadPool tem dois tipos de threads, Worker e IOCP (I/O Completion Port).

• WORKER threads são usados para coisas como processar o Task.Run(…), ou ThreadPool.QueueUserWorkItem(…) métodos. Vários componentes no CLR também usam esses threads quando o trabalho precisa acontecer em um thread em segundo plano.
• IOCP threads são usados para E/S assíncronas, 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 minimum configuração 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 ocupados existentes atinge o minimum número 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 que precisa de um IOCP thread, ele processa esse trabalho rapidamente. No entanto, se o burst for maior do que a configuração configurada minimum , há 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, então um novo thread é criado.

Basicamente, quando o número de threads é maior do que threads, você enfrenta um atraso de Busy 500 ms antes que Min o aplicativo processe o tráfego de rede. Além disso, um thread existente que permanece ocioso por mais de 15 segundos é limpo, e esse ciclo de crescimento e encolhimento pode se repetir.

As mensagens de erro do StackExchange.Redis build 1.0.450 ou posterior imprimem estatísticas do ThreadPool, conforme mostrado no exemplo a seguir.

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)

O exemplo mostra que, para o IOCP thread, há seis threads ocupados e o sistema está configurado para permitir quatro threads mínimos. Neste caso, é provável que o cliente veja dois atrasos de 500 ms, porque 6 > 4.

Nota

O StackExchange.Redis pode atingir tempos limite se o crescimento de um ou IOCPWORKER threads for limitado.

É melhor definir o valor mínimo de configuração para IOCP e WORKER threads para algo maior do que o valor padrão. Não há uma orientação única sobre esse valor, porque o valor certo para um aplicativo é provavelmente muito alto ou baixo para outro aplicativo. Essa configuração também pode afetar o desempenho de outras partes de aplicativos complicados. Você precisa ajustar essa configuração às suas necessidades específicas. Um bom ponto de partida é 200 ou 300. Em seguida, teste e ajuste conforme necessário.

Definir a configuração de threads mínimos

Você pode alterar essa configuração programaticamente usando o método ThreadPool.SetMinThreads (... ).

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

    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ê usar o .NET Core, defina o valor em Program.cs imediatamente antes da chamada como WebApplication.CreateBuilder():

    const int minThreads = 200
                  
    ThreadPool.SetMinThreads(minThreads, minThreads);
    
    var builder = WebApplication.CreateBuilder(args);
    // rest of application setup

Nota

O valor especificado por esse método é uma configuração global que afeta todo o AppDomain. Por exemplo, se você tiver uma VM de quatro núcleos e quiser definir minWorkerThreads e minIoThreads para 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 minIoThreads definição ou minWorkerThreadsconfiguração 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. Se você definir threads mínimos dessa maneira, deverá reiniciar o pool de aplicativos.

Nota

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

Conteúdo relacionado

• Consulte outras perguntas frequentes sobre o Cache do Azure para Redis.

Este artigo fornece respostas a perguntas comuns sobre como gerenciar o Cache do Azure para Redis.

Importante

O Cache do Azure para Redis anunciou seu cronograma de desativação para todas as SKUs. Recomendamos mover as suas instâncias existentes do Azure Cache para Redis para Azure Managed Redis o mais rápido possível.

Para mais detalhes sobre a aposentadoria:

• Cache do Azure para Aposentadoria Redis: o que saber e como preparar
• Perguntas frequentes sobre a descontinuação do Cache do Azure para Redis

• Use redis-benchmark.exe para carregar o teste do seu servidor Redis. Use redis-benchmark.exe para ter uma ideia da taxa de transferência possível antes de escrever seus próprios testes de desempenho.
• Use redis-cli para monitorar o cache usando o INFO comando. Para obter instruções sobre como baixar as ferramentas Redis, consulte Como posso executar comandos Redis?
• Se você usar Transport Layer Security/Secure Socket Layer (TLS/SSL) em sua instância de cache, adicione o --tls parâmetro aos comandos das ferramentas Redis ou use um proxy como stunnel para habilitar TLS/SSL.
• Redis-benchmark usa porta 6379 por padrão. Use o -p parâmetro para substituir essa configuração se o cache usar a porta 6380 SSL/TLS ou a porta 10000da camada Enterprise.
• Se necessário, você pode habilitar a porta não-TLS por meio do portal do Azure antes de executar o teste de carga.
• Verifique se a máquina virtual (VM) cliente que você usa para teste está na mesma região que sua instância do Cache do Azure para Redis.
• Certifique-se de que sua VM cliente tenha pelo menos tanta capacidade de computação e largura de banda quanto o cache que você está testando. Para obter melhores resultados, use VMs das séries D e E para seus clientes.
• Se você estiver no Windows, habilite o VRSS (Virtual Receive-side Scaling) na máquina cliente. Para obter mais informações, consulte Virtual Receive-side Scaling in Windows Server 2012 R2.
• 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 baixar e revisar suas métricas usando as ferramentas de sua escolha.
• Se a carga estiver causando alta fragmentação de memória, aumente a escala para um tamanho de cache maior.

Os exemplos a seguir mostram como usar redis-benchmark.exeo . Execute esses comandos a partir de uma VM na mesma região do cache para obter resultados precisos.

Primeiro, teste solicitações canalizadas SET 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

Depois de executar o SET teste, execute solicitações canalizadas GET 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

Habilitar a coleta de lixo do servidor (GC) pode otimizar o cliente e fornecer melhor desempenho e taxa de transferência quando você usa o StackExchange.Redis. Para obter mais informações sobre o GC do servidor e como habilitá-lo, consulte os seguintes artigos:

• O <elemento gcServer>
• Fundamentos da coleta de lixo
• Recolha de lixo e desempenho

O servidor Redis não suporta nativamente TLS (Transport Layer Security), mas o Cache Redis do Azure dá suporte a TLS. Se você se conectar ao Cache Redis do Azure com um cliente como StackExchange.Redis que dá suporte a TLS, use TLS.

Nota

A porta não-TLS é desabilitada por padrão para novas instâncias do Azure Redis. Se o seu cliente não suportar TLS, habilite a porta não-TLS seguindo as instruções em Portas de acesso.

Se o cache usa TLS, você deve habilitar o TLS usando a --tls opção para ferramentas Redis como redis-cli. Você também 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 ASP.NET Session State Provider for Redis Preview Release .

Para obter instruções sobre como baixar as ferramentas Redis, consulte Como posso executar comandos 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. O Redis é um servidor de thread único que processa comandos um de cada vez. Se você executar o comando, o KEYS Redis não processará os comandos subsequentes até concluir o processamento do KEYS comando.

  O site redis.io tem detalhes de complexidade de tempo para cada operação suportada. Selecione cada comando para ver a complexidade de cada operação.

• O tamanho das chaves a serem usadas depende do cenário. Se o cenário exigir chaves maiores, você poderá ajustar os valores de repetição e ajustar a ConnectionTimeoutlógica de repetição. Do ponto de vista do servidor Redis, valores de chave menores proporcionam melhor desempenho.

• Essas considerações não significam que você não possa armazenar valores maiores no Redis, mas as latências são maiores. Se você tiver um conjunto de dados maior que outro, poderá usar várias ConnectionMultiplexer instâncias, cada uma configurada com um conjunto diferente de valores de tempo limite e de novas tentativas. Para obter mais informações, consulte O que fazem as opções de configuração do StackExchange.Redis?

Cada camada de preço do Cache do Azure para Redis 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 envolve sobrecarga associada. Um exemplo dessa sobrecarga é 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 limites de conexão 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.

• Use o nível Standard ou Premium para sistemas de produção. A camada básica é um sistema de nó único sem replicação de dados e sem contrato de nível de serviço (SLA). Além disso, use pelo menos um cache C1 para produção. Os caches C0 são normalmente usados para cenários simples de desenvolvimento/teste.
• Lembre-se de que o Redis é um armazenamento de dados na memória e a perda de dados pode ocorrer em alguns cenários. Para obter mais informações, consulte Solucionar problemas de perda de dados no Cache do Azure para Redis.
• Desenvolva seu sistema para que ele possa lidar com falhas de conexão causadas por patches e failover.
• Use instâncias Redis do Azure de camada Premium para melhor latência e taxa de transferência de rede, porque elas têm melhor hardware para CPU e rede.

Práticas recomendadas do StackExchange.Redis

• Defina AbortConnect como false e, em seguida, deixe a ConnectionMultiplexer reconexão 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. Por exemplo, em Qual é a faixa de tamanho de valor ideal para redis?, 100 kb é considerado grande. Para obter mais informações, consulte Considerar mais chaves e valores menores.
• 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ê executa. 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 de cada operação suportada. Selecione cada comando para ver a complexidade de cada operação.

O Common Language Runtime (CLR) ThreadPool tem dois tipos de threads, Worker e IOCP (I/O Completion Port).

• WORKER threads são usados para coisas como processar o Task.Run(…), ou ThreadPool.QueueUserWorkItem(…) métodos. Vários componentes no CLR também usam esses threads quando o trabalho precisa acontecer em um thread em segundo plano.
• IOCP threads são usados para E/S assíncronas, 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 minimum configuração 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 ocupados existentes atinge o minimum número 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 que precisa de um IOCP thread, ele processa esse trabalho rapidamente. No entanto, se o burst for maior do que a configuração configurada minimum , há 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, então um novo thread é criado.

Basicamente, quando o número de threads é maior do que threads, você enfrenta um atraso de Busy 500 ms antes que Min o aplicativo processe o tráfego de rede. Além disso, um thread existente que permanece ocioso por mais de 15 segundos é limpo, e esse ciclo de crescimento e encolhimento pode se repetir.

As mensagens de erro do StackExchange.Redis build 1.0.450 ou posterior imprimem estatísticas do ThreadPool, conforme mostrado no exemplo a seguir.

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)

O exemplo mostra que, para o IOCP thread, há seis threads ocupados e o sistema está configurado para permitir quatro threads mínimos. Neste caso, é provável que o cliente veja dois atrasos de 500 ms, porque 6 > 4.

Nota

O StackExchange.Redis pode atingir tempos limite se o crescimento de um ou IOCPWORKER threads for limitado.

É melhor definir o valor mínimo de configuração para IOCP e WORKER threads para algo maior do que o valor padrão. Não há uma orientação única sobre esse valor, porque o valor certo para um aplicativo é provavelmente muito alto ou baixo para outro aplicativo. Essa configuração também pode afetar o desempenho de outras partes de aplicativos complicados. Você precisa ajustar essa configuração às suas necessidades específicas. Um bom ponto de partida é 200 ou 300. Em seguida, teste e ajuste conforme necessário.

Definir a configuração de threads mínimos

Você pode alterar essa configuração programaticamente usando o método ThreadPool.SetMinThreads (... ).

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

    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ê usar o .NET Core, defina o valor em Program.cs imediatamente antes da chamada como WebApplication.CreateBuilder():

    const int minThreads = 200
                  
    ThreadPool.SetMinThreads(minThreads, minThreads);
    
    var builder = WebApplication.CreateBuilder(args);
    // rest of application setup

Nota

O valor especificado por esse método é uma configuração global que afeta todo o AppDomain. Por exemplo, se você tiver uma VM de quatro núcleos e quiser definir minWorkerThreads e minIoThreads para 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 minIoThreads definição ou minWorkerThreadsconfiguração 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. Se você definir threads mínimos dessa maneira, deverá reiniciar o pool de aplicativos.

Nota

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

Conteúdo relacionado

• Consulte outras perguntas frequentes sobre o Cache do Azure para Redis.