Perguntas frequentes sobre gerenciamento de cache

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

Como medir e testar o desempenho do meu cache?

• Use redis-benchmark.exe para testar a carga do 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 INFO comando. Para obter instruções sobre como baixar as ferramentas do Redis, consulte Como posso executar comandos do 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 do Redis ou use um proxy como stunnel para habilitar o TLS/SSL.
• Redis-benchmark usa a 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 VM (máquina virtual) do cliente que você usa 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 tanta capacidade de computação e largura de banda quanto o cache que você está testando. Para obter melhores resultados, use VMs da série D e da série E para seus clientes.
• Se você estiver no Windows, habilite o VRSS (Virtual Receive-side Scaling) no computador cliente. Para obter mais informações, consulte Dimensionamento virtual do lado de recebimento no 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 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 redis-benchmark.exeo . Execute esses comandos de uma VM na mesma região do cache para obter resultados precisos.

Primeiro, teste as solicitações em SET pipeline 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 em GET pipeline usando uma carga 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 GC (coleta de lixo do servidor) pode otimizar o cliente e fornecer melhor desempenho e taxa de transferência quando você usa StackExchange.Redis. Para saber mais sobre a GC do servidor e como habilitá-la, confira os artigos a seguir:

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

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

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

Observação

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

Se o cache usar TLS, você deverá habilitar o TLS usando a --tls opção para ferramentas do Redis, como redis-cli. Você também pode usar um utilitário para stunnel conectar com segurança as ferramentas à porta TLS seguindo as instruções na postagem no blog Anunciando ASP.NET Provedor de Estado de Sessão para Versão de Visualização 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. Se você emitir o comando, o KEYS Redis não processará os comandos subsequentes até que termine de processar o KEYS comando.

  O site redis.io tem detalhes de complexidade de tempo para cada operação que ele suporta. 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 os valores de ConnectionTimeoutrepetição, repetir e ajustar a lógica de repetição. Do ponto de vista do servidor Redis, valores de chave menores oferecem 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. 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 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 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 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 sobrecarga de conexão mais a carga das operações do cliente exceder a capacidade do sistema, o cache poderá ter problemas de capacidade mesmo que você não exceda o limite de conexão para o tamanho do cache atual.

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 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 no Cache do Azure para Redis.
• Desenvolva seu sistema para que ele possa lidar com blips de conexão causados por patches e failover.
• Use instâncias do Azure Redis de camada Premium para obter melhor latência e taxa de transferência de rede, pois elas têm melhor hardware para CPU e rede.

Práticas recomendadas do StackExchange.Redis

• Defina AbortConnect como false e deixe a ConnectionMultiplexer reconexão 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 à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 que suporta. Selecione cada comando para ver a complexidade para cada operação.

Detalhes importantes sobre o crescimento de ThreadPool

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

• WORKER Os threads são usados para coisas como processar os Task.Run(…)métodos , OR 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 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.

Depois que 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 por 500 milissegundos.

Normalmente, se o sistema receber uma intermitência de trabalho que precisa de um IOCP thread, ele processará esse trabalho rapidamente. No entanto, se a intermitência for maior do que a configuração definida minimum , 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 fica livre por 500 ms, portanto, um novo thread é criado.

Basicamente, quando o número de Busy threads é maior que os threads, você experimenta um atraso de 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. Nesse caso, é provável que o cliente veja dois atrasos de 500 ms, porque 6 > 4.

Observação

StackExchange.Redis pode atingir tempos limite se o crescimento de um IOCP ou WORKER mais threads for limitado.

É melhor definir o valor mínimo de configuração para IOCP e WORKER threads como algo maior que o valor padrão. Não há uma orientação única para todos esse valor, pois 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 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, 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)o .

Também é possível especificar a configuração mínima de threads usando a minIoThreadsminWorkerThreads ou 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 threads mínimos dessa maneira, deverá reiniciar o pool de aplicativos.

Observação

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 no tempo de execução, use <processModel minIoThreads="50">.

Conteúdo relacionado

• Confira 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.

• Use redis-benchmark.exe para testar a carga do 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 INFO comando. Para obter instruções sobre como baixar as ferramentas do Redis, consulte Como posso executar comandos do 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 do Redis ou use um proxy como stunnel para habilitar o TLS/SSL.
• Redis-benchmark usa a 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 VM (máquina virtual) do cliente que você usa 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 tanta capacidade de computação e largura de banda quanto o cache que você está testando. Para obter melhores resultados, use VMs da série D e da série E para seus clientes.
• Se você estiver no Windows, habilite o VRSS (Virtual Receive-side Scaling) no computador cliente. Para obter mais informações, consulte Dimensionamento virtual do lado de recebimento no 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 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 redis-benchmark.exeo . Execute esses comandos de uma VM na mesma região do cache para obter resultados precisos.

Primeiro, teste as solicitações em SET pipeline 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 em GET pipeline usando uma carga de 1k:

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

Habilitar a GC (coleta de lixo do servidor) pode otimizar o cliente e fornecer melhor desempenho e taxa de transferência quando você usa StackExchange.Redis. Para saber mais sobre a GC do servidor e como habilitá-la, confira os artigos a seguir:

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

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

Observação

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

Se o cache usar TLS, você deverá habilitar o TLS usando a --tls opção para ferramentas do Redis, como redis-cli. Você também pode usar um utilitário para stunnel conectar com segurança as ferramentas à porta TLS seguindo as instruções na postagem no blog Anunciando ASP.NET Provedor de Estado de Sessão para Versão de Visualização 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. Se você emitir o comando, o KEYS Redis não processará os comandos subsequentes até que termine de processar o KEYS comando.

  O site redis.io tem detalhes de complexidade de tempo para cada operação que ele suporta. 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 os valores de ConnectionTimeoutrepetição, repetir e ajustar a lógica de repetição. Do ponto de vista do servidor Redis, valores de chave menores oferecem 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. 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 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 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 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 sobrecarga de conexão mais a carga das operações do cliente exceder a capacidade do sistema, o cache poderá ter problemas de capacidade mesmo que você não exceda o limite de conexão para o tamanho do cache atual.

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 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 no Cache do Azure para Redis.
• Desenvolva seu sistema para que ele possa lidar com blips de conexão causados por patches e failover.
• Use instâncias do Azure Redis de camada Premium para obter melhor latência e taxa de transferência de rede, pois elas têm melhor hardware para CPU e rede.

Práticas recomendadas do StackExchange.Redis

• Defina AbortConnect como false e deixe a ConnectionMultiplexer reconexão 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 à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 que suporta. Selecione cada comando para ver a complexidade para cada operação.

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

• WORKER Os threads são usados para coisas como processar os Task.Run(…)métodos , OR 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 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.

Depois que 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 por 500 milissegundos.

Normalmente, se o sistema receber uma intermitência de trabalho que precisa de um IOCP thread, ele processará esse trabalho rapidamente. No entanto, se a intermitência for maior do que a configuração definida minimum , 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 fica livre por 500 ms, portanto, um novo thread é criado.

Basicamente, quando o número de Busy threads é maior que os threads, você experimenta um atraso de 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. Nesse caso, é provável que o cliente veja dois atrasos de 500 ms, porque 6 > 4.

Observação

StackExchange.Redis pode atingir tempos limite se o crescimento de um IOCP ou WORKER mais threads for limitado.

É melhor definir o valor mínimo de configuração para IOCP e WORKER threads como algo maior que o valor padrão. Não há uma orientação única para todos esse valor, pois 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 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, 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)o .

Também é possível especificar a configuração mínima de threads usando a minIoThreadsminWorkerThreads ou 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 threads mínimos dessa maneira, deverá reiniciar o pool de aplicativos.

Observação

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 no tempo de execução, use <processModel minIoThreads="50">.

Conteúdo relacionado

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