Gérer la charge du serveur pour Azure Cache pour Redis
Tailles de valeurs
La conception de votre application cliente détermine si vous devez stocker de nombreuses petites valeurs ou un plus petit nombre de valeurs plus élevées. Du point de vue du serveur Redis, les valeurs les plus petites donnent de meilleures performances. Nous vous recommandons de conserver une taille de valeur inférieure à 100 Ko.
Si votre conception exige que vous stockiez des valeurs plus élevées dans Azure Cache pour Redis, la charge du serveur sera plus élevée. Dans ce cas, vous devrez peut-être utiliser un niveau de cache plus élevé pour garantir que l’utilisation du processeur ne limite pas le débit.
Même si le cache dispose d’une capacité de processeur suffisante, les valeurs plus élevées augmentent les latences. Par conséquent, suivez les instructions dans Configurer des délais d’expiration appropriés.
Des valeurs plus élevées augmentent également les chances de fragmentation de la mémoire. Veillez donc à suivre les instructions dans Configurer votre paramètre maxmemory-reserved.
Éviter les pics de connexion client
La création et la fermeture de connexions constituent une opération coûteuse pour le serveur Redis. Si votre application cliente crée ou ferme un trop grand nombre de connexions dans un laps de temps réduit, le serveur Redis peut être chargé.
Si vous instanciez de nombreuses instances clientes simultanément pour vous connecter à Redis, envisagez d’échelonner les nouvelles créations de connexions afin d’éviter un pic abrupt du nombre de clients connectés.
Sollicitation de la mémoire
Une utilisation élevée de la mémoire sur le serveur rend le système plus susceptible de devoir paginer des données sur le disque, ce qui entraîne des défauts de page qui peuvent ralentir considérablement le système.
Éviter les commandes de longue durée
Le serveur Redis est un système à thread unique. Les commandes de longue durée peuvent entraîner une latence ou des délais d’expiration côté client car le serveur ne peut pas répondre à d’autres requêtes lorsqu’il est occupé à travailler sur une commande de longue durée. Pour plus d’informations, consultez Résoudre les problèmes côté serveur liés à Azure Cache pour Redis.
Surveiller la charge du serveur
Ajoutez une surveillance de la charge du serveur pour vous assurer que vous recevez des notifications en cas de charge élevée du serveur. La surveillance peut vous aider à comprendre vos contraintes d’application. Vous pouvez ensuite travailler de manière proactive pour atténuer les problèmes. Nous vous recommandons d’essayer de conserver une charge du serveur inférieure à 80 % pour éviter des effets négatifs sur les performances. Une charge du serveur soutenue et supérieure à 80 % peut entraîner des basculements non planifiés. Actuellement, Azure Cache pour Redis expose deux métriques dans Informations sous Surveillance dans le menu de la ressource à gauche du portail : UCet Charge du serveur. Il est important de comprendre ce que mesure chaque métrique lors de la surveillance de la charge du serveur.
La métrique UC indique l’utilisation de l’UC pour le nœud hébergeant le cache. La métrique UC inclut également des processus qui ne sont pas strictement ceux du serveur Redis. L’UC inclut des processus en arrière-plan pour des logiciels anti-programme malveillant et autres. Par conséquent, la métrique UC peut présenter des pics et ne pas être un indicateur parfait de l’utilisation de l’UC pour le serveur Redis.
La métrique Charge du serveur représente la charge du seul serveur Redis. Nous vous recommandons de surveiller la métrique Charge du serveur plutôt que la métrique UC.
Au chargement du serveur moniteur, nous vous recommandons également d’examiner les pics maximaux de la charge du serveur plutôt que la moyenne, car même de brefs pics peuvent déclencher des basculements et des délais d’expiration de commande.
Planifier la maintenance du serveur
Vérifiez que vous disposez d’une capacité de serveur suffisante pour gérer vos pics de charge lorsque vos serveurs de cache sont en cours de maintenance. Testez votre système en redémarrant les nœuds pendant les pics de charge. Pour plus d’informations sur la façon de simuler le déploiement d’un patch, consultez la section relative au redémarrage.
Tester l’augmentation de la charge du serveur après le basculement
Pour les SKU Standard et Premium, chaque cache est hébergé sur deux nœuds. Un équilibreur de charge distribue les connexions clientes entre les deux nœuds. Lorsque la maintenance planifiée ou non planifiée se produit sur le nœud principal, le nœud ferme toutes les connexions clientes. Dans ce cas, toutes les connexions clientes peuvent atterrir sur un seul nœud, ce qui entraîne une augmentation de la charge du serveur sur le nœud restant. Nous vous recommandons de tester ce scénario en redémarrant le nœud principal et en veillant à ce qu’un nœud puisse gérer toutes vos connexions clientes sans que la charge du serveur soit trop élevée.