Résoudre les problèmes de performances dans les comptes de stockage Azure

Article
11/20/2024

Cet article vous aide à examiner les changements inattendus dans le comportement (tels que les temps de réponse plus lents que d’habitude). Ces changements de comportement peuvent souvent être identifiés en supervisant des métriques de stockage dans Azure Monitor. Pour obtenir des informations générales sur l’utilisation des métriques et des journaux dans Azure Monitor, consultez les articles suivants :

Analyse des performances

Pour surveiller les performances des services de stockage, vous pouvez utiliser les métriques suivantes :

Les métriques SuccessE2ELatency et SuccessServerLatency indiquent le temps moyen nécessaire au service de stockage ou au type d’opération d’API pour traiter les demandes. SuccessE2ELatency est une mesure de la latence de bout en bout qui inclut le temps nécessaire pour lire la demande et envoyer la réponse en plus du temps nécessaire pour traiter la demande (par conséquent, elle inclut la latence réseau une fois la requête atteinte au service de stockage). SuccessServerLatency est une mesure du temps de traitement et exclut donc toute latence réseau liée à la communication avec le client.
Les métriques Egress et Ingress indiquent le volume total des données (en octets) entrant et sortant dans votre service de stockage, ou transitant via un type d’opération d’API spécifique.
La métrique Transactions indique le nombre total de demandes que le service de stockage de l’opération d’API reçoit. Les transactions sont le nombre total de demandes reçues par le service de stockage.

Vous pouvez superviser les changements inattendus dans l’une de ces valeurs. Ces changements peuvent indiquer un problème qui nécessite un examen approfondi.

Dans le Portail Azure, vous pouvez ajouter des règles d’alerte qui vous avertissent quand l’une des métriques de performances de ce service tombe en dessous ou dépasse un seuil que vous spécifiez.

Diagnostiquer les problèmes de performances

Les performances d’une application peuvent être subjectives, en particulier du point de vue de l’utilisateur. C'est pourquoi il est important de disposer de métriques de base afin de vous aider à identifier les problèmes de performances éventuels. De nombreux facteurs peuvent affecter les performances d'un service de stockage Azure du point de vue de l'application cliente. Ces facteurs peuvent fonctionner dans le service de stockage, le client ou l’infrastructure réseau. Par conséquent, il est important d’avoir une stratégie pour identifier l’origine du problème de performances.

Après avoir identifié l'emplacement probable de la cause du problème de performances à partir des métriques, vous pouvez utiliser les fichiers journaux afin de disposer d'informations détaillées pour un diagnostic et une résolution en profondeur du problème.

Les métriques indiquent une valeur successE2ELatency élevée et une valeur SuccessServerLatency faible

Dans certains cas, vous pouvez constater que SuccessE2ELatency est supérieur à successServerLatency. Le service de stockage calcule uniquement la métrique SuccessE2ELatency pour les requêtes réussies et, contrairement à la valeur SuccessServerLatency, inclut le temps nécessaire au client pour envoyer les données et recevoir l’accusé de réception du service de stockage. Par conséquent, une différence entre SuccessE2ELatency et SuccessServerLatency peut être due à la lenteur de réponse de l’application cliente ou à des conditions sur le réseau.

Note

Vous pouvez également afficher les valeurs E2ELatency et ServerLatency pour des opérations de stockage individuelles dans les données de journalisation du stockage.

Enquête sur les problèmes de performances client

Les raisons possibles pour le client qui répondent lentement incluent l’utilisation de connexions ou de threads disponibles limités ou d’être faible sur les ressources telles que l’UC, la mémoire ou la bande passante réseau. Vous pouvez peut-être résoudre le problème en modifiant le code client pour qu’il soit plus efficace (par exemple, en utilisant des appels asynchrones au service de stockage) ou en utilisant une machine virtuelle plus volumineuse avec plus de cœurs et plus de mémoire.

Pour les services de table et de file d’attente, l’algorithme Nagle peut également entraîner une latence successE2ELatency élevée par rapport à SuccessServerLatency. Pour plus d’informations, consultez le billet suivant : l’algorithme de Nagle n’est pas convivial pour les petites demandes. Vous pouvez désactiver l’algorithme Nagle dans le code à l’aide de la ServicePointManager classe dans l’espace System.Net de noms. Cette opération doit être effectuée avant de réaliser des appels vers les services de table et de file d’attente dans votre application, car elle n’affecte pas les connexions déjà ouvertes. L’exemple suivant provient de la Application_Start méthode dans un rôle de travail :

var connectionString = Constants.connectionString;
QueueServiceClient queueServiceClient = new QueueServiceClient(connectionString);
ServicePoint queueServicePoint = ServicePointManager.FindServicePoint(queueServiceClient.Uri);
queueServicePoint.UseNagleAlgorithm = false;

Vous devez vérifier les journaux côté client pour voir le nombre de demandes envoyées par votre application cliente et vérifier les goulots d’étranglement généraux liés aux performances liés à .NET dans votre client, tels que le processeur, le garbage collection .NET, l’utilisation du réseau ou la mémoire. La première étape pour la résolution des problèmes des applications clientes .NET consiste à consulter la section Débogage, suivi et profilage.

Enquête sur les problèmes de latence du réseau

Une latence de bout en bout élevée, causée par le réseau, est généralement associée à des conditions provisoires. Vous pouvez examiner les problèmes réseau temporaires et persistants, tels que les paquets supprimés, à l’aide d’outils tels que Wireshark.

Les métriques indiquent une valeur SuccessE2ELatency faible et une valeur SuccessServerLatency faible, mais le client constate une latence élevée

Dans ce scénario, la cause la plus probable est un retard de la demande de stockage à atteindre le service de stockage. Vous devez examiner pourquoi les demandes du client ne le font pas via le service d’objets blob.

Les raisons possibles à un retard de l’envoi des demandes par le client incluent un nombre limité de connexions ou threads disponibles.

Vérifiez également si le client effectue plusieurs nouvelles tentatives et examinez la raison de son utilisation. Pour déterminer si le client effectue plusieurs tentatives, vous pouvez :

Examiner les journaux. Si plusieurs nouvelles tentatives se produisent, plusieurs opérations s’affichent avec les mêmes ID de demande client.
Examiner les journaux d’activité du client. Les nouvelles tentatives apparaissent dans la journalisation documentée.
Déboguez votre code et vérifiez les propriétés de l’objet OperationContext associé à la requête. Si l’opération a retenté, la RequestResults propriété inclut plusieurs requêtes uniques. Vous pouvez également vérifier les heures de début et de fin de chaque demande.

En l’absence de problèmes au niveau du client, vous pouvez enquêter sur la présence de problèmes potentiels au niveau du réseau, tels que la perte de paquets. Vous pouvez utiliser des outils tels que Wireshark pour enquêter sur les problèmes de réseau.

Les métriques indiquent une valeur SuccessServerLatency élevée

En présence d’une valeur SuccessServerLatency élevée pour les demandes de téléchargement d’objet blob, vous devez utiliser les journaux de stockage pour savoir si des demandes répétées ont été envoyées pour le même objet blob (ou ensemble d’objets blob). Pour les demandes de chargement d’objets blob, vous devez examiner la taille de bloc utilisée par le client (par exemple, les blocs inférieurs à 64 K de taille peuvent entraîner des surcharges, sauf si les lectures sont également en moins de 64 K segments) et si plusieurs clients chargent des blocs dans le même objet blob en parallèle. Vous devez également vérifier les métriques par minute pour connaître les pics de demandes qui entraînent un dépassement des cibles d’extensibilité par seconde.

Si vous voyez une valeur élevée successServerLatency pour les demandes de téléchargement d’objets blob lorsqu’il existe des demandes répétées pour le même objet blob ou le même ensemble d’objets blob, envisagez de mettre en cache ces objets blob à l’aide du cache Azure ou du réseau de distribution de contenu Azure (CDN). Pour les demandes de chargement, vous devez améliorer le débit en augmentant la taille des blocs. Pour les requêtes sur des tables, il est également possible d’implémenter une mise en cache côté client sur les clients qui effectuent les mêmes opérations de requête et où les données ne changent pas fréquemment.

Des valeurs SuccessServerLatency élevées peuvent également indiquer la présence de tables mal conçues ou de requêtes donnant lieu à des opérations d’analyse ou qui suivent l’anti-modèle d’ajout/ajout de préfixe.

Note

Vous trouverez une liste de contrôle complète des performances à partir de Stockage Microsoft Azure Liste de contrôle des performances et de l’extensibilité.

Vous constatez des retards inattendus dans la livraison des messages d’une file d’attente

Si vous rencontrez un délai entre le moment où une application ajoute un message à une file d’attente et le moment où elle est disponible pour lire à partir de la file d’attente, procédez comme suit pour diagnostiquer le problème :

Vérifiez que l’application ajoute correctement les messages à la file d’attente. Vérifiez que l’application n’est pas retenter la AddMessage méthode plusieurs fois avant de réussir.
Vérifiez qu’il n’y a pas d’asymétrie d’horloge entre le rôle de travail qui ajoute le message à la file d’attente et le rôle de travail qui lit le message à partir de la file d’attente. Une asymétrie d’horloge le rend comme s’il y a un délai de traitement.
Vérifiez si le rôle de travail qui lit les messages à partir de la file d'attente échoue. Si un client de file d’attente appelle la GetMessage méthode mais ne parvient pas à répondre avec un accusé de réception, le message reste invisible dans la file d’attente jusqu’à l’expiration de la invisibilityTimeout période. Ce n'est qu'à ce moment que le message pourra à nouveau être traité.
Vérifiez si la longueur de la file d'attente augmente avec le temps. Cela peut se produire si vous n’avez pas suffisamment de workers disponibles pour traiter tous les messages que d’autres travailleurs mettent dans la file d’attente. Vérifiez également les métriques pour voir si les demandes de suppression échouent et que le nombre de files d’attente sur les messages, ce qui peut indiquer des tentatives répétées d’échec de suppression du message.
Vérifiez dans les journaux de stockage la présence d’opérations de file d’attente présentant des valeurs E2ELatency et ServerLatency supérieures à celles prévues, pendant une période anormalement longue.

Voir aussi

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.

Partager via