Gerir a Carga do Servidor para a Cache do Azure para Redis
Tamanhos de valor
O design da aplicação cliente determina se deve armazenar muitos valores pequenos ou um número mais reduzido de valores maiores. Da perspetiva do servidor Redis, os valores mais pequenos proporcionam um melhor desempenho. Recomendamos que mantenha o tamanho dos valores inferior a 100 KB.
Se o design exigir que armazene valores maiores na Cache do Azure para Redis, a carga do servidor será superior. Neste caso, poderá ter de utilizar um escalão de cache superior para garantir que a utilização da CPU não limita o débito.
Mesmo que a cache tenha capacidade de CPU suficiente, os valores de maior dimensão aumentam as latências, pelo que deve seguir a documentação de orientação em Configurar tempos limite adequados.
Os valores de maior dimensão também aumentam as hipóteses de fragmentação da memória, por isso, confirme que segue a documentação de orientação em Configurar a definição maxmemory-reserved.
Evitar picos de ligações do cliente
Criar e fechar ligações é uma operação dispendiosa para o servidor Redis. Se a aplicação cliente criar ou fechar demasiadas ligações num curto período de tempo, poderá sobrecarregar o servidor Redis.
Se estiver a instanciar muitas instâncias de cliente para ligar imediatamente ao Redis, considere escalonar as novas criações de ligações para evitar um pico acentuado no número de clientes ligados.
Pressão da memória
Uma utilização elevada da memória no servidor aumenta a probabilidade de o sistema precisar de paginar dados para o disco, o que resulta em falhas de página e pode abrandar significativamente o sistema.
Evitar comandos de execução prolongada
O servidor Redis é um sistema de thread único. Comandos de execução longa podem causar latência ou tempos limite no lado do cliente porque o servidor não pode responder a outras solicitações enquanto está ocupado trabalhando em um comando de longa execução. Para obter mais informações, veja Resolver problemas do lado do servidor da Cache do Azure para Redis.
Monitorizar a Carga do Servidor
Adicione monitorização à carga do servidor para garantir que recebe notificações quando ocorre uma carga elevada do servidor. A monitorização pode ajudar a compreender as restrições da aplicação. Em seguida, pode trabalhar proactivamente para mitigar os problemas. Recomendamos que tente manter a carga do servidor abaixo dos 80% para evitar efeitos de desempenho negativos. Uma carga sustentada do servidor superior a 80% pode levar a failovers não planejados. Atualmente, o Cache Redis do Azure expõe duas métricas no Insights em Monitoramento no menu Recurso à esquerda do portal: CPU e Carga do Servidor. Compreender o que é medido por cada métrica é importante ao monitorizar a carga do servidor.
A métrica CPU indica o uso da CPU para o nó que hospeda o cache. A métrica da CPU também inclui processos que não são estritamente processos do servidor Redis. A CPU inclui processos em segundo plano para antimalware e outro malware. Como resultado, a métrica da CPU pode, por vezes, aumentar drasticamente e pode não ser um indicador perfeito da utilização da CPU para o servidor Redis.
A métrica Carga do Servidor representa a carga somente no Servidor Redis. Recomendamos monitorar a métrica Server Load 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 mesmo picos breves podem desencadear failovers e tempos limite de comando.
Planear a manutenção do servidor
Confirme que tem capacidade de servidor suficiente para lidar com a carga máxima enquanto os servidores da cache estão em manutenção. Teste o sistema ao reiniciar os nós durante a carga máxima. Para obter mais informações sobre como simular a implantação de um patch, consulte reinicializar.
Teste em relação a um aumento da carga do servidor após a ativação pós-falha
Para SKUs standard e premium, cada cache é alojada em dois nós. Um balanceador de carga distribui as ligações de cliente para os dois nós. Quando ocorre uma manutenção planeada ou não planeada no nó primário, o nó fecha todas as ligações do cliente. Nestas situações, todas as ligações do cliente podem aceder a um único nó, o que faz com que a carga do servidor aumente no nó restante. Recomendamos que teste este cenário ao reiniciar o nó primário e ao garantir que um nó consegue lidar com todas as ligações do cliente sem que a carga do servidor fique demasiado elevada.