Gestire il carico del server per Redis gestito di Azure (anteprima)
Dimensioni valore
La progettazione dell'applicazione client determina se archiviare molti valori piccoli o un numero minore di valori più grandi. Dal punto di vista del server Redis, valori più piccoli offrono prestazioni migliori. È consigliabile mantenere le dimensioni del valore inferiori a 100 kB.
Se la progettazione richiede di archiviare valori più grandi in Azure Managed Redis (anteprima), il carico del server sarà superiore. In questo caso, potrebbe essere necessario usare un livello di cache superiore per garantire che l'utilizzo della CPU non limiti la velocità effettiva.
Anche se la cache ha capacità CPU sufficiente, valori più grandi aumentano le latenze, quindi seguire le indicazioni in Configurare timeout appropriati.
Evitare picchi di connessione client
La creazione e la chiusura delle connessioni è un'operazione costosa per il server Redis. Se l'applicazione client crea o chiude un numero eccessivo di connessioni in un periodo di tempo ridotto, il server Redis potrebbe sovraccaricarsi.
Se si istanziano molte istanze client con connessione simultanea a Redis, è consigliabile dilatare le nuove creazioni di connessione per evitare un picco ripido nel numero di client connessi.
Utilizzo elevato della memoria
Un utilizzo elevato della memoria nel server rende più probabile il paging dei dati su disco da parte del sistema, cosa che causa errori di pagina che possono rallentare significativamente il sistema.
Evitare comandi a esecuzione prolungata
Il server Redis è un sistema a thread singolo. I comandi a esecuzione prolungata possono causare latenza o timeout sul lato client perché il server non può rispondere ad altre richieste mentre è occupato a gestire un comando a esecuzione prolungata. Per altre informazioni, vedere Risolvere i problemi di cache di Azure per Redis lato server.
Monitorare il carico del server
Aggiungere il monitoraggio sul carico del server per assicurarsi di ricevere notifiche quando si verifica un carico elevato del server. Il monitoraggio consente di comprendere i vincoli dell'applicazione. È quindi possibile lavorare in modo proattivo per attenuare i problemi. È consigliabile mantenere il carico del server inferiore all'80% per evitare effetti negativi sulle prestazioni. Il carico del server prolungato oltre l'80% può causare failover non pianificati. Attualmente, Azure Managed Redis espone due metriche in Insights in Monitoraggio nel menu Risorsa a sinistra del portale: CPU e carico del server. Comprendere cosa viene misurato in base a ogni metrica è importante quando si monitora il carico del server.
La metrica CPU indica l'utilizzo della CPU per il nodo che ospita la cache. La metrica CPU include anche processi che non sono strettamente legati al server Redis. La CPU include processi in background per antimalware e altri. Di conseguenza, la metrica CPU può talvolta aumentare e potrebbe non essere un indicatore perfetto dell'utilizzo della CPU per il server Redis.
La metrica Carico server rappresenta il carico nel solo server Redis. È consigliabile monitorare la metrica Carico server anziché la metrica CPU.
Quando si monitora il carico del server, è consigliabile esaminare anche i picchi massimi di carico del server anziché la media, perché anche brevi picchi possono attivare failover e timeout dei comandi.
Pianificare la manutenzione del server
Assicurarsi di avere una capacità server sufficiente per gestire il carico massimo mentre i server della cache sono in fase di manutenzione. Testare il sistema riavviando i nodi durante il picco di carico. Per altre informazioni su come simulare la distribuzione di una patch, vedere Riavviare.
Testare l'aumento del carico del server dopo il failover
Per gli SKU standard e premium, ogni cache è ospitata in due nodi. Un servizio di bilanciamento del carico distribuisce le connessioni client ai due nodi. Quando si verifica una manutenzione pianificata o non pianificata nel nodo primario, il nodo chiude tutte le connessioni client. In tali situazioni, tutte le connessioni client potrebbero raggiungere un singolo nodo, causando l'aumento del carico del server sul nodo rimanente. È consigliabile testare questo scenario riavviando il nodo primario e assicurandosi che un nodo possa gestire tutte le connessioni client senza che il carico del server sia troppo elevato.