Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Dans cet article, nous expliquons comment utiliser et surveiller la charge d’un cache Redis managé Azure.
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 vous oblige à stocker des valeurs plus importantes dans le Azure Redis managé, 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é processeur suffisante, les valeurs supérieures augmentent les latences. Suivez donc les instructions de Configuration des délais d’expiration appropriés.
É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.
Pression 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 d'exécution
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 Dépannage des problèmes côté serveur pour Azure Cache for Redis.
Surveiller la charge du serveur et le processeur
Ajoutez la surveillance de la charge du serveur et du processeur pour vous assurer que vous recevez des notifications lorsque l'un ou l'autre est élevé. 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 Managed Redis expose deux métriques dans Insights sous Monitoring dans le menu Ressource à gauche du portail : CPU et Server Load. Comprendre ce qui est mesuré par chaque métrique est important lors de leur surveillance.
La métrique CPU (également appelée pourcentage du temps processeur) indique l’utilisation de l’UC pour le nœud qui héberge 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 du processeur peut présenter des fluctuations et ne pas refléter parfaitement l’utilisation du processeur pour le serveur Redis.
La métrique de chargement du serveur Redis reflète l’évaluation de la charge globale du serveur Redis et est similaire à la métrique du processeur, mais au niveau d’un cluster.
Recommandations pour les références SKU plus petites
Pour les références SKU Azure Managed Redis basées sur des VM 2 vCPU (B0–B5, X3 et M10), les métriques en pourcentage comme Server Load et CPU sont naturellement plus sensibles. Un thread d’arrière-plan à courte durée de vie peut consommer un pourcentage significatif du processeur total, ce qui entraîne l’apparition de métriques élevées même lorsque la charge de travail réelle est légère. Par conséquent, ces métriques peuvent surestimater la charge réelle sur de petites références SKU et ne peuvent pas indiquer la saturation de la charge de travail.
Lors de l’examen des métriques sur des périodes plus longues, telles que plusieurs heures ou plusieurs jours, nous vous recommandons :
- Utiliser CPU au lieu de Server Load, car il peut être observé au niveau de l’instance ce qui offre une granularité accrue.
- Fractionnement par ID d'instance des machines virtuelles qui supportent l’instance Redis managée d’Azure
- Utilisation de l’agrégation moyenne au lieu du maximum pour ces intervalles de temps plus longs
Vous pouvez toujours utiliser l’agrégation maximale sur des fenêtres de temps courtes pour intercepter de brefs pics ou événements (tels que ceux susceptibles de provoquer des délais d’attente ou des basculements), tout en utilisant la moyenne sur des fenêtres plus longues pour l’analyse des tendances sur de petites références SKU, en particulier lors de l’utilisation du processeur.
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.