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 a linha do tempo de desativação para todos os SKUs. Recomendamos migrar suas instâncias do Cache do Azure para Redis para o Redis Gerenciado pelo Azure assim que possível.

Para obter mais detalhes sobre a aposentadoria:

• Desativação do Azure Cache for Redis: o que saber e como se preparar
• Perguntas frequentes sobre a desativação do Cache do Azure para Redis

Como medir e testar o desempenho do meu cache?

• Use redis-benchmark.exe para carregar o teste de seu servidor Redis. Use redis-benchmark.exe para ter uma ideia da possível taxa de transferência antes de escrever seus próprios testes de desempenho.
• Use redis-cli para monitorar o cache usando o comando INFO. Para obter instruções sobre como baixar as ferramentas do Redis, consulte Como posso executar comandos do Redis?
• Caso use o protocolo TLS/SSL em sua instância de cache, adicione o parâmetro --tls aos comandos das ferramentas do Redis ou use um proxy como stunnel para habilitar o TLS/SSL.
• Redis-benchmark usa a porta 6379 por padrão. Use o parâmetro -p para substituir essa configuração se o cache usar a porta SSL/TLS 6380 ou a porta da camada Enterprise 10000.
• Se necessário, você poderá habilitar a porta não TLS por meio do portal do Azure antes de executar o teste de carga.
• Verifique se a VM (máquina virtual) do cliente usada para teste está na mesma região que sua instância do Cache do Azure para Redis.
• Verifique se a VM cliente tem pelo menos a capacidade de computação e largura de banda que o cache que você está testando. Para obter melhores resultados, use as VMs das séries D e E para seus clientes.
• Caso esteja no Windows, habilite o VRSS (Virtual Receive-Side Scaling) no computador cliente. Para obter mais informações, consulte Novidades no Receive-side Scaling virtual do Windows Server 2012 R2.
• Habilite o diagnóstico de cache para que você possa monitorar a integridade do cache. Você poderá exibir as métricas no portal do Azure e também poderá baixar e examinar suas métricas usando as ferramentas de sua escolha.
• Se a carga estiver causando alta fragmentação de memória, escale verticalmente para um tamanho de cache maior.

Os exemplos a seguir mostram como usar o redis-benchmark.exe. Execute estes comandos em uma VM na mesma região do cache para obter resultados precisos.

Primeiro, teste as solicitações em SET pipeline usando uma carga de 1 mil:

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

Depois de executar o teste SET, execute solicitações em GET pipeline usando uma carga de 1 mil:

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 o GC do servidor pode otimizar o cliente e fornecer melhor desempenho e taxa de transferência ao usar o StackExchange.Redis. Para saber mais sobre a GC do servidor e como habilitá-la, confira os artigos a seguir:

• O <elemento >gcServer
• Noções básicas sobre o GC
• GC e desempenho

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

O servidor Redis não dá suporte nativo ao protocolo TLS, mas o Cache do Azure para Redis dá suporte a TLS. Se você se conectar ao Cache do Azure para Redis com um cliente como StackExchange.Redis que dá suporte o TLS, use o TLS.

Observação

A porta não TLS é desabilitada por padrão para novas instâncias do Redis do Azure. Se o cliente não der suporte ao TLS, habilite a porta não TLS seguindo as instruções nas portas do Access.

Se o cache usar o TLS, você deverá habilitá-lo usando a opção --tls para ferramentas do Redis, como redis-cli. Também é possível usar um utilitário como stunnel para conectar com segurança as ferramentas à porta TLS seguindo as instruções na postagem de blog Anunciando o Provedor de Estado de Sessão do ASP.NET para versão prévia do Redis.

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

Quais são algumas considerações para usar comandos comuns do Redis?

• 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. O Redis é um servidor de thread único que processa comandos um de cada vez. Caso emita o comando KEYS, o Redis não processará os comandos subsequentes até que ele conclua o processamento do comando KEYS.

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

• O tamanho das chaves a serem usadas depende do cenário. Se o cenário exigir chaves maiores, você poderá ajustar o ConnectionTimeout e, em seguida, tentar novamente e ajustar a lógica de repetição. Da perspectiva do servidor Redis, valores de chave menores proporcionam melhor desempenho.

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

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

Cada tipo 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 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 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ão para cada camada, consulte os Preços do Cache do Azure para Redis. Para obter mais informações sobre as conexões e outras configurações padrão, consulte configuração do servidor padrão Redis.

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

• Use a camada Standard ou Premium para sistemas de Produção. A Camada Básica é um sistema de nó único sem replicação de dados e sem SLA (contrato de nível de serviço). Além disso, use pelo menos um cache C1 para Produção. Caches C0 normalmente são usados para cenários de desenvolvimento/teste simples.
• 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 Cache do Azure para Redis.
• Desenvolva seu sistema para que ele possa lidar com conexões causadas por aplicação de patch e failover.
• Use instâncias do Redis do Azure de camada Premium para melhorar a latência de rede e a taxa de transferência, pois elas têm um hardware melhor para CPU e rede.

Práticas recomendadas do StackExchange.Redis

• Defina AbortConnect como false e, em seguida, permita o ConnectionMultiplexer 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. Por exemplo, em Qual é o intervalo de tamanho de valor ideal para Redis?, 100 kb é considerado grande. Para obter mais informações, consulte Considerar mais chaves e valores menores.
• Configure suas configurações de 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 a diferentes operações executadas. 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 à qual ele dá suporte. Selecione cada comando para ver a complexidade para cada operação.

Detalhes importantes sobre o crescimento de ThreadPool

O ThreadPool do CLR (Common Language Runtime) tem dois tipos de threads, Porta de Conclusão de Trabalho e E/S (IOCP).

• WORKER threads são usados para coisas como processar o Task.Run(…), ou métodos ThreadPool.QueueUserWorkItem(…). 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íncrona, como ao ler 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 minimum 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 ocupados existentes atinge o número de threads minimum, o ThreadPool limita a taxa na qual injeta novos threads em um thread por 500 milissegundos.

Normalmente, se o sistema obtém uma intermitência de trabalho que precisa de um thread IOCP, ele processa que funcionam rapidamente. No entanto, se a intermitência for maior do que a configuração minimum definida, haverá algum atraso no processamento de parte do trabalho, pois o ThreadPool aguarda uma das duas possibilidades:

• Um thread existente ficar livre para processar o trabalho.
• Nenhum thread existente ficar livre por 500 ms, o que leva à criação de outro thread.

Basicamente, quando o número de threads Busy é maior que os threads Min, você tem um atraso de 500 ms antes que 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 redução pode se repetir.

Mensagens de erro do build 1.0.450 ou posterior do StackExchange.Redis imprimem estatísticas de 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 thread IOCP, há seis threads ocupados e o sistema está configurado para permitir quatro threads mínimos. Nesse caso, o cliente provavelmente verá dois atrasos de 500 ms, porque 6 > 4.

Observação

O StackExchange.Redis poderá atingir tempos limite se o crescimento de um IOCPou threads WORKER for limitado.

É melhor definir o valor mínimo de configuração para IOCP threads WORKER e para algo maior do que o valor padrão. Não há nenhuma orientação de tamanho único 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ê precisará ajustar essa configuração de acordo com suas necessidades específicas. Um bom ponto de partida é 200 ou 300. Em seguida, teste e ajuste conforme necessário.

Definir a configuração mínima de threads

É possível alterar essa configuração programaticamente usando o método ThreadPool.SetMinThreads (...).

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

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

Caso use o .NET Core, definirá o valor em Program.cs logo antes da chamada para WebApplication.CreateBuilder():

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

Observação

O valor especificado por esse método é uma configuração global que afeta todo o AppDomain. Por exemplo, caso tenha uma VM de quatro núcleos e quiser definir minWorkerThreads e minIoThreads para 50 por CPU durante o runtime, use ThreadPool.SetMinThreads(200, 200).

Também é possível especificar a configuração mínima de threads usando a minIoThreads ou minWorkerThreadsparâmetro de configuração no elemento de configuração <processModel> em 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. Se você definir threads mínimos dessa forma, deverá reiniciar o pool de aplicativos.

Observação

O valor especificado por esse método é uma configuração por núcleo. Por exemplo, caso tenha um computador de quatro núcleos e quiser que sua configuração minIoThreads seja 200 no runtime, use <processModel minIoThreads="50">.

Conteúdo relacionado

• Veja 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 a linha do tempo de desativação para todos os SKUs. Recomendamos migrar suas instâncias do Cache do Azure para Redis para o Redis Gerenciado pelo Azure assim que possível.

Para obter mais detalhes sobre a aposentadoria:

• Desativação do Azure Cache for Redis: o que saber e como se preparar
• Perguntas frequentes sobre a desativação do Cache do Azure para Redis

• Use redis-benchmark.exe para carregar o teste de seu servidor Redis. Use redis-benchmark.exe para ter uma ideia da possível taxa de transferência antes de escrever seus próprios testes de desempenho.
• Use redis-cli para monitorar o cache usando o comando INFO. Para obter instruções sobre como baixar as ferramentas do Redis, consulte Como posso executar comandos do Redis?
• Caso use o protocolo TLS/SSL em sua instância de cache, adicione o parâmetro --tls aos comandos das ferramentas do Redis ou use um proxy como stunnel para habilitar o TLS/SSL.
• Redis-benchmark usa a porta 6379 por padrão. Use o parâmetro -p para substituir essa configuração se o cache usar a porta SSL/TLS 6380 ou a porta da camada Enterprise 10000.
• Se necessário, você poderá habilitar a porta não TLS por meio do portal do Azure antes de executar o teste de carga.
• Verifique se a VM (máquina virtual) do cliente usada para teste está na mesma região que sua instância do Cache do Azure para Redis.
• Verifique se a VM cliente tem pelo menos a capacidade de computação e largura de banda que o cache que você está testando. Para obter melhores resultados, use as VMs das séries D e E para seus clientes.
• Caso esteja no Windows, habilite o VRSS (Virtual Receive-Side Scaling) no computador cliente. Para obter mais informações, consulte Novidades no Receive-side Scaling virtual do Windows Server 2012 R2.
• Habilite o diagnóstico de cache para que você possa monitorar a integridade do cache. Você poderá exibir as métricas no portal do Azure e também poderá baixar e examinar suas métricas usando as ferramentas de sua escolha.
• Se a carga estiver causando alta fragmentação de memória, escale verticalmente para um tamanho de cache maior.

Os exemplos a seguir mostram como usar o redis-benchmark.exe. Execute estes comandos em uma VM na mesma região do cache para obter resultados precisos.

Primeiro, teste as solicitações em SET pipeline usando uma carga de 1 mil:

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

Depois de executar o teste SET, execute solicitações em GET pipeline usando uma carga de 1 mil:

redis-benchmark.exe -h <yourcache>.redis.cache.windows.net -a <yourAccesskey> -t GET -n 1000000 -d 1024 -P 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 saber mais sobre a GC do servidor e como habilitá-la, confira os artigos a seguir:

• O <elemento >gcServer
• Noções básicas sobre o GC
• GC e desempenho

O servidor Redis não dá suporte nativo ao protocolo TLS, mas o Cache do Azure para Redis dá suporte a TLS. Se você se conectar ao Cache do Azure para Redis com um cliente como StackExchange.Redis que dá suporte o TLS, use o TLS.

Observação

A porta não TLS é desabilitada por padrão para novas instâncias do Redis do Azure. Se o cliente não der suporte ao TLS, habilite a porta não TLS seguindo as instruções nas portas do Access.

Se o cache usar o TLS, você deverá habilitá-lo usando a opção --tls para ferramentas do Redis, como redis-cli. Também é possível usar um utilitário como stunnel para conectar com segurança as ferramentas à porta TLS seguindo as instruções na postagem de blog Anunciando o Provedor de Estado de Sessão do ASP.NET para versão prévia do Redis.

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

• 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. O Redis é um servidor de thread único que processa comandos um de cada vez. Caso emita o comando KEYS, o Redis não processará os comandos subsequentes até que ele conclua o processamento do comando KEYS.

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

• O tamanho das chaves a serem usadas depende do cenário. Se o cenário exigir chaves maiores, você poderá ajustar o ConnectionTimeout e, em seguida, tentar novamente e ajustar a lógica de repetição. Da perspectiva do servidor Redis, valores de chave menores proporcionam melhor desempenho.

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

Cada tipo 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 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 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ão para cada camada, consulte os Preços do Cache do Azure para Redis. Para obter mais informações sobre as conexões e outras configurações padrão, consulte configuração do servidor padrão Redis.

• Use a camada Standard ou Premium para sistemas de Produção. A Camada Básica é um sistema de nó único sem replicação de dados e sem SLA (contrato de nível de serviço). Além disso, use pelo menos um cache C1 para Produção. Caches C0 normalmente são usados para cenários de desenvolvimento/teste simples.
• 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 Cache do Azure para Redis.
• Desenvolva seu sistema para que ele possa lidar com conexões causadas por aplicação de patch e failover.
• Use instâncias do Redis do Azure de camada Premium para melhorar a latência de rede e a taxa de transferência, pois elas têm um hardware melhor para CPU e rede.

Práticas recomendadas do StackExchange.Redis

• Defina AbortConnect como false e, em seguida, permita o ConnectionMultiplexer 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. Por exemplo, em Qual é o intervalo de tamanho de valor ideal para Redis?, 100 kb é considerado grande. Para obter mais informações, consulte Considerar mais chaves e valores menores.
• Configure suas configurações de 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 a diferentes operações executadas. 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 à qual ele dá suporte. Selecione cada comando para ver a complexidade para cada operação.

O ThreadPool do CLR (Common Language Runtime) tem dois tipos de threads, Porta de Conclusão de Trabalho e E/S (IOCP).

• WORKER threads são usados para coisas como processar o Task.Run(…), ou métodos ThreadPool.QueueUserWorkItem(…). 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íncrona, como ao ler 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 minimum 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 ocupados existentes atinge o número de threads minimum, o ThreadPool limita a taxa na qual injeta novos threads em um thread por 500 milissegundos.

Normalmente, se o sistema obtém uma intermitência de trabalho que precisa de um thread IOCP, ele processa que funcionam rapidamente. No entanto, se a intermitência for maior do que a configuração minimum definida, haverá algum atraso no processamento de parte do trabalho, pois o ThreadPool aguarda uma das duas possibilidades:

• Um thread existente ficar livre para processar o trabalho.
• Nenhum thread existente ficar livre por 500 ms, o que leva à criação de outro thread.

Basicamente, quando o número de threads Busy é maior que os threads Min, você tem um atraso de 500 ms antes que 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 redução pode se repetir.

Mensagens de erro do build 1.0.450 ou posterior do StackExchange.Redis imprimem estatísticas de 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 thread IOCP, há seis threads ocupados e o sistema está configurado para permitir quatro threads mínimos. Nesse caso, o cliente provavelmente verá dois atrasos de 500 ms, porque 6 > 4.

Observação

O StackExchange.Redis poderá atingir tempos limite se o crescimento de um IOCPou threads WORKER for limitado.

É melhor definir o valor mínimo de configuração para IOCP threads WORKER e para algo maior do que o valor padrão. Não há nenhuma orientação de tamanho único 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ê precisará ajustar essa configuração de acordo com suas necessidades específicas. Um bom ponto de partida é 200 ou 300. Em seguida, teste e ajuste conforme necessário.

Definir a configuração mínima de threads

É possível alterar essa configuração programaticamente usando o método ThreadPool.SetMinThreads (...).

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

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

Caso use o .NET Core, definirá o valor em Program.cs logo antes da chamada para WebApplication.CreateBuilder():

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

Observação

O valor especificado por esse método é uma configuração global que afeta todo o AppDomain. Por exemplo, caso tenha uma VM de quatro núcleos e quiser definir minWorkerThreads e minIoThreads para 50 por CPU durante o runtime, use ThreadPool.SetMinThreads(200, 200).

Também é possível especificar a configuração mínima de threads usando a minIoThreads ou minWorkerThreadsparâmetro de configuração no elemento de configuração <processModel> em 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. Se você definir threads mínimos dessa forma, deverá reiniciar o pool de aplicativos.

Observação

O valor especificado por esse método é uma configuração por núcleo. Por exemplo, caso tenha um computador de quatro núcleos e quiser que sua configuração minIoThreads seja 200 no runtime, use <processModel minIoThreads="50">.

Conteúdo relacionado

• Veja outras Perguntas frequentes sobre o Cache do Azure para Redis .