Gerenciar a carga do servidor para o Cache do Azure para Redis
Tamanhos de valor
O design do seu aplicativo cliente determina se você deve armazenar muitos valores pequenos ou um número menor de valores maiores. Da perspectiva do servidor Redis, valores menores apresentam um desempenho melhor. É recomendável manter o tamanho do valor menor do que 100 kB.
Se o design exigir que você armazene valores maiores no Cache do Azure para Redis, a carga do servidor será maior. Nesse caso, talvez seja necessário usar uma camada de cache superior para garantir que o uso da CPU não limite a taxa de transferência.
Mesmo que o cache tenha capacidade suficiente de CPU, valores maiores aumentam as latências, portanto, siga as orientações em Configurar tempos limite apropriados.
Valores maiores também aumentam as chances de fragmentação de memória, portanto, certifique-se de seguir as diretrizes em configurar sua configuração de MaxMemory-reserved.
Evitar picos de conexão do cliente
A criação e o fechamento de conexões é uma operação cara para o servidor Redis. Se o aplicativo cliente criar ou fechar muitas conexões em um pequeno período de tempo, ele poderá sobrecarregar o servidor Redis.
Se você estiver instanciando várias instâncias de cliente para se conectar ao Redis de uma só vez, considere escalonar as novas criações de conexão para evitar um pico acentuado no número de clientes conectados.
Demanda de memória
O alto uso da memória no servidor torna mais provável que o sistema precise paginar dados no disco, resultando em falhas de página que podem desacelerar significativamente o sistema.
Evite comandos de execução prolongada
O Redis Server é um sistema de thread único. Comandos de execução prolongada podem causar latência ou tempos limite no lado do cliente, pois o servidor não pode responder a outras solicitações enquanto está ocupado trabalhando em um comando de execução prolongada. Para mais informações, veja Solucionar problemas no lado do servidor do Cache do Azure para Redis.
Monitorar carga do servidor
Adicione monitoramento na carga do servidor para garantir que você obtenha notificações quando a alta carga do servidor ocorrer. O monitoramento pode ajudá-lo a reconhecer as restrições do aplicativo. Em seguida, você pode trabalhar de forma proativa para atenuar os problemas. É recomendável tentar manter a carga do servidor abaixo de 80% para evitar efeitos de desempenho negativos. A carga sustentada do servidor acima de 80% pode levar a failovers não planejados. Atualmente, o Cache do Azure para Redis expõe duas métricas em Insights, em Monitoramento, no menu Recurso à esquerda do portal: CPU e Carga do Servidor. Entender o que é medido por cada métrica é importante ao monitorar a carga do servidor.
A métrica de CPU indica o uso da CPU para o nó que hospeda o cache. A métrica de CPU também inclui processos que não são estritamente processos de servidor Redis. A CPU inclui processos em segundo plano para antimalware e outros. Como resultado, a métrica de CPU pode, às vezes, ser um pico e pode não ser um indicador perfeito de uso da CPU para o servidor Redis.
A métrica de Carga do Servidor representa apenas a carga no servidor Redis. É recomendável monitorar a métrica de Carga do Servidor em vez da CPU.
Ao monitorar a carga do servidor, também recomendamos que você examine os picos máximos de Carga do Servidor em vez da média, pois até mesmo picos breves podem disparar failovers e tempos limite de comando.
Planejar a manutenção do servidor
Verifique se você tem capacidade de servidor suficiente para lidar com sua carga de pico enquanto os servidores de cache estão passando por manutenção. Teste seu sistema reinicializando os nós durante o pico de carga. Para obter mais informações sobre como simular a implantação de um patch, consulte reinicializar.
Testar o aumento da carga do servidor após o failover
Para SKUs padrão e premium, cada cache é hospedado em dois nós. Um balanceador de carga distribui as conexões de cliente para os dois nós. Quando a manutenção planejada ou não planejada ocorre no nó primário, o nó encerra todas as conexões do cliente. Nessas situações, todas as conexões de cliente podem chegar em um único nó, fazendo com que a carga do servidor aumente no nó restante. É recomendável testar esse cenário reiniciando o nó primário e garantindo que um nó possa lidar com todas as conexões de cliente sem que a carga do servidor seja muito alta.