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

Article
04/10/2024

Cet article vous aide à examiner les changements inattendus de comportement (tels que les temps de réponse plus lents que d’habitude). Ces changements de comportement peuvent souvent être identifiés en surveillant les 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 :

Surveillance 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 que le service de stockage ou le type d’opération d’API prend pour traiter les demandes. SuccessE2ELatency est une mesure de la latence de bout en bout qui inclut le temps nécessaire pour lire la requête 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 que la requête atteint le 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 Sortie et Entrée affichent la quantité totale de données, en octets, entrantes et sortantes de votre service de stockage ou via un type d’opération API spécifique.
La métrique Transactions indique le nombre total de demandes reçues par le service de stockage de l’opération d’API. Transactions correspond au nombre total de demandes reçues par le service de stockage.

Vous pouvez surveiller les modifications inattendues de l’une de ces valeurs. Ces modifications peuvent indiquer un problème qui nécessite un examen plus approfondi.

Dans la 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. Par conséquent, il est important d’avoir des métriques de base disponibles pour vous aider à identifier où il peut y avoir un problème de performances. 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.

Une fois que vous avez identifié l’emplacement probable de la cause du problème de performances à partir des métriques, vous pouvez utiliser les fichiers journaux pour trouver des informations détaillées pour diagnostiquer et résoudre le problème plus en détail.

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

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 à SuccessServerLatency, inclut le temps nécessaire au client pour envoyer les données et recevoir un accusé de réception du service de stockage. Par conséquent, une différence entre SuccessE2ELatency et SuccessServerLatency peut être due à la lenteur de la réponse de l’application cliente ou à des conditions sur le réseau.

Remarque

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

Examen des problèmes de performances du client

Les raisons possibles pour lesquelles le client répond lentement incluent le fait d’avoir des connexions ou des threads disponibles limités ou d’avoir une faible consommation de ressources telles que le processeur, la mémoire ou la bande passante réseau. Vous pouvez 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 grande 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 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 de System.Net noms . Vous devez le faire avant d’effectuer des appels aux services de table ou de file d’attente dans votre application, car cela 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 case activée les journaux côté client pour voir le nombre de demandes que votre application cliente envoie et case activée pour 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. Comme point de départ pour la résolution des problèmes des applications clientes .NET, consultez Débogage, suivi et profilage.

Examen des problèmes de latence réseau

En règle générale, la latence élevée de bout en bout causée par le réseau est due à des conditions temporaires. 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 faible valeur SuccessServerLatency, mais le client rencontre une latence élevée

Dans ce scénario, la cause la plus probable est un retard dans la demande de stockage qui atteint le service de stockage. Vous devez examiner pourquoi les demandes du client ne sont pas envoyées au service blob.

L’une des raisons possibles pour lesquelles le client retarde l’envoi des demandes est qu’il existe un nombre limité de connexions ou de threads disponibles.

En outre, case activée si le client effectue plusieurs nouvelles tentatives et examinez la raison si c’est le cas. Pour déterminer si le client effectue plusieurs nouvelles tentatives, vous pouvez :

Examinez les journaux. Si plusieurs nouvelles tentatives sont effectuées, vous verrez plusieurs opérations avec les mêmes ID de demande client.
Examinez les journaux du client. La journalisation détaillée indique qu’une nouvelle tentative s’est produite.
Déboguez votre code et case activée les propriétés de l’objet OperationContext associé à la requête. Si l’opération a fait une nouvelle tentative, la RequestResults propriété inclut plusieurs demandes uniques. Vous pouvez également case activée les heures de début et de fin de chaque requête.

S’il n’y a aucun problème dans le client, vous devez examiner les problèmes réseau potentiels tels que la perte de paquets. Vous pouvez utiliser des outils tels que Wireshark pour examiner les problèmes réseau.

Les métriques indiquent une latence successServerLatency élevée

Dans le cas d’une valeur SuccessServerLatency élevée pour les demandes de téléchargement d’objets blob, vous devez utiliser les journaux de stockage pour voir s’il y a des demandes répété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 d’une taille inférieure à 64 Ko peuvent entraîner des surcharges, sauf si les lectures sont également en moins de 64 000 blocs) et si plusieurs clients chargent des blocs dans le même objet blob en parallèle. Vous devez également case activée les métriques par minute pour les pics du nombre de demandes qui entraînent un dépassement des objectifs d’extensibilité par seconde.

Si vous voyez une latence SuccessServerLatency élevée pour les demandes de téléchargement d’objets blob lorsqu’il y a 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 d’Azure Cache ou du réseau de distribution de contenu (CDN) Azure. Pour les demandes de chargement, vous pouvez améliorer le débit en utilisant une plus grande taille de bloc. Pour les requêtes vers des tables, il est également possible d’implémenter la 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.

Les valeurs SuccessServerLatency élevées peuvent également être un symptôme de tables ou de requêtes mal conçues qui entraînent des opérations d’analyse ou qui suivent l’anti-modèle append/prepend.

Remarque

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

Vous rencontrez des retards inattendus dans la remise des messages dans 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ù il devient disponible pour la lecture à partir de la file d’attente, effectuez les étapes suivantes pour diagnostiquer le problème :

Vérifiez que l’application ajoute correctement les messages à la file d’attente. Vérifiez que l’application ne retentera pas 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 donne l’impression qu’il y a un délai de traitement.
Vérifiez si le rôle de travail qui lit les messages 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 stade, le message est à nouveau disponible pour traitement.
Vérifiez si la longueur de la file d’attente augmente au fil du temps. Cela peut se produire si vous n’avez pas suffisamment de workers disponibles pour traiter tous les messages que les autres workers placent dans la file d’attente. En outre, case activée les métriques pour voir si les demandes de suppression échouent et le nombre de messages de suppression de la file d’attente, ce qui peut indiquer des échecs répétés de tentatives de suppression du message.
Examinez les journaux de stockage pour rechercher les opérations de file d’attente qui ont des valeurs E2ELatency et ServerLatency plus élevées que prévu sur une période plus longue que d’habitude.

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