Afficher les données d’Application Insights Profiler

  • Article

Supposons que vous exécutez un test de performances web. Vous avez besoin des traces pour comprendre comment votre application web s’exécute avec une certaine charge. Dans cet article, vous allez :

  • Générez du trafic vers votre application web en démarrant un test de performances web ou en démarrant une session Profiler à la demande.
  • Affichez les traces de Profiler après votre test de charge ou session Profiler.
  • Découvrez comment lire les données de performances de Profiler et la pile des appels.

Générer du trafic vers votre service Azure

Pour que Profiler charge des traces, votre service doit gérer activement les demandes.

Si vous venez d’activer Profiler, exécutez un test de charge court avec Azure Load Testing.

Si votre service Azure a déjà du trafic entrant ou si vous souhaitez simplement générer manuellement du trafic, ignorez le test de charge et démarrez une session Profiler à la demande :

  1. A partir de la page de vue d’ensemble d’Application Insights, sélectionnez Performances dans le menu de gauche.

  2. Dans le volet Performances, sélectionnez Profiler dans le menu supérieur pour les paramètres de Profiler.

    Screenshot of the Profiler button from the Performance pane.

  3. Une fois la page des paramètres de Profiler chargée, sélectionnez Profiler maintenant.

    Screenshot of Profiler page features and settings.

Affichage des traces

  1. Une fois les sessions Profiler terminées, revenez au volet Performances.

  2. Sous Explorer..., sélectionnez Traces Profiler pour afficher les traces.

    Screenshot of trace explorer page.

L’Explorateur de trace affiche les informations suivantes :

Filtrer Description
Arborescence des profils ou Graphe de flamme Affichez les traces sous forme d’arborescence ou de graphe.
Chemin à chaud Sélectionnez cette option pour ouvrir le plus grand nœud terminal. Dans la plupart des cas, ce nœud est proche d’un goulot d’étranglement des performances.
Dépendances du framework Sélectionnez cette option pour afficher chacune des dépendances du framework tracées associées aux traces.
Masquer les événements Tapez des chaînes à masquer dans la vue de la trace. Sélectionnez Événements suggérés pour obtenir des suggestions.
Événement Nom de l’événement ou de la fonction. L’arborescence affiche un mélange de code et d’événements qui se sont produits, par exemple, des événements SQL et HTTP. L’événement supérieur représente la durée globale de la requête.
Module Module dans lequel l’événement ou la fonction suivi s’est produit.
Heure du thread intervalle de temps entre le début de l’opération et la fin.
Durée moment auquel la fonction ou l’événement était en cours d’exécution par rapport à d’autres fonctions.

Comment lire les données de performances

Profiler utilise un ensemble de méthodes d’échantillonnage et une instrumentation pour analyser les performances de votre application. Lors de l’exécution d’une collection détaillée, le Profiler :

  • Échantillonne le pointeur d’instruction de chaque processeur de machine toutes les millisecondes.
    • Chaque exemple capture la pile des appels complète du thread, en donnant des informations détaillées à des niveaux d’abstraction faibles et élevés.
  • Collecte des événements pour suivre la corrélation d’activité et la causalité, notamment :
    • Événements de basculement de contexte
    • Événements de la bibliothèque parallèle de tâches (TPL)
    • Événements de pool de threads

La pile des appels présentée dans l’affichage chronologique est le résultat de l’échantillonnage et de l’instrumentation. Comme chaque échantillon capture l’ensemble de la pile des appels du thread, il inclut le code de Microsoft .NET Framework et des autres frameworks que vous référencez.

Allocation d’objets (clr!JIT_New ou clr!JIT_Newarr1)

clr!JIT_New et clr!JIT_Newarr1 sont des fonctions d’assistance dans .NET Framework qui allouent de la mémoire à partir d’un segment de mémoire managé.

  • clr!JIT_New est appelé lorsqu’un objet est alloué.
  • clr!JIT_Newarr1 est appelé lorsqu’un tableau d’objets est alloué.

Ces deux fonctions fonctionnent généralement rapidement. Si clr!JIT_New ou clr!JIT_Newarr1 prend du temps dans votre chronologie, le code pourrait allouer de nombreux objets et consommer une quantité importante de mémoire.

Code de chargement (clr!ThePreStub)

clr!ThePreStub est une fonction d’assistance dans .NET Framework qui prépare le code pour l’exécution initiale, qui inclut généralement la compilation juste-à-temps (JIT). Pour chaque méthode C#, clr!ThePreStub doit être appelé au maximum une fois pendant un processus.

Si clr!ThePreStub prend plus de temps pour traiter une demande, c’est la première demande à exécuter cette méthode. Le runtime .NET Framework prend beaucoup de temps pour charger la première méthode. Considérez les aspects suivants :

  • Vous pouvez utiliser un processus de mise en route qui exécute cette partie du code avant que vos utilisateurs y accèdent.
  • Vous pouvez exécuter Native Image Generator (ngen.exe) sur vos assemblys.

Contention de verrouillage (clr!JITutil_MonContention ou clr!JITutil_MonEnterWorker)

clr!JITutil_MonContention ou clr!JITutil_MonEnterWorker indiquent que le thread actuel est en attente d’ouverture d’un verrou. Ce texte s’affiche souvent lorsque vous :

  • Exécutez une instruction LOCK C#,
  • Appelez la méthode Monitor.Enter ou
  • Appelez une méthode avec l’attribut MethodImplOptions.Synchronized.

La contention de verrouillage se produit généralement quand le thread A acquiert un verrou et que le thread B tente d’acquérir le même verrou avant qu’il ne soit libéré par le thread A.

Code de chargement ([COLD])

Si le runtime .NET Framework exécute du code non optimisé pour la première fois, le nom de la méthode contient [COLD] :

mscorlib.ni![COLD]System.Reflection.CustomAttribute.IsDefined

Pour chaque méthode, cela doit s’afficher au maximum une fois pendant le processus.

Si le chargement du code prend beaucoup de temps pour une demande, c’est la première exécution par la demande de la partie non optimisée de la méthode. Vous pouvez envisager d’utiliser un processus de mise en route qui exécute cette partie du code avant que vos utilisateurs y accèdent.

Envoyer une requête HTTP

Les méthodes comme HttpClient.Send indiquent que le code attend la fin d’une requête HTTP.

Opération de base de données

Une méthode comme SqlCommand.Execute indique que le code attend la fin d’une opération de base de données.

En attente (AWAITTIME)

AWAIT_TIME indique que le code attend la fin de l’exécution d’une autre tâche. Ce délai se produit avec l’instruction AWAIT C#. Lorsque le code effectue une AWAIT C# :

  • Le thread se déroule et retourne le contrôle au pool de threads.
  • Il n’y a pas de thread bloqué qui attend la fin de l’instruction AWAIT.

Toutefois, le thread qui a exécuté l’instruction AWAIT est logiquement « bloqué » en attendant que l’opération se termine. L’instruction AWAIT_TIME indique le temps de blocage en attendant la fin de l’exécution de la tâche.

Si l’opérateur AWAIT_TIME semble être dans le code d’infrastructure au lieu de votre code, le Profileur peut afficher :

  • Le code d’infrastructure utilisé pour exécuter l’opérateur AWAIT
  • Code utilisé pour l’enregistrement des données de télémétrie concernant l’opérateur AWAIT

Vous pouvez décocher la case Dépendances du framework en haut de la page pour afficher uniquement votre code et faciliter l’affichage de l’origine de l’opérateur AWAIT.

Temps de blocage

BLOCKED_TIME indique que le code attend qu’une autre ressource soit disponible. Par exemple, il attend peut-être :

  • Un objet de synchronisation
  • Un thread disponible
  • Une demande à terminer

Asynchrone non managé

Pour permettre le suivi des appels asynchrones entre les threads, .NET Framework émet des événements ETW et transmet les ID d’activité entre les threads. Étant donné que le code non managé (natif) et certains anciens styles de code asynchrone n’ont pas ces événements et ID d’activité, Profiler ne peut pas suivre le thread et les fonctions s’exécutant sur le thread. Cela est indiqué par Asynchrone non managé dans la pile des appels. Téléchargez le fichier ETW afin d’utiliser PerfView pour plus d’informations.

Temps processeur

Le processeur est occupé à exécuter les instructions.

Temps du disque

L’application effectue les opérations de disque.

Temps réseau

L’application effectue les opérations réseau.

Colonne « When » (Quand)

La colonne When permet de voir la variété d’exemples inclusifs collectés pour un nœud au fil du temps. La plage totale de la requête est divisée en 32 compartiments de temps, où les exemples inclusifs du nœud sont accumulés. Chaque période est représentée sous forme de barre. La hauteur de la barre représente une valeur à l’échelle. Pour les nœuds suivants, la barre représente la consommation de l’une des ressources durant le compartiment :

  • Nœuds marqués CPU_TIME ou BLOCKED_TIME.
  • Nœuds avec une relation évidente à la consommation d’une ressource (par exemple, un processeur, un disque ou un thread).

Pour ces métriques, vous pouvez dépasser le seuil de 100 % en consommant plusieurs ressources. Par exemple, si vous utilisez en moyenne deux processeurs sur un intervalle donné, vous obtenez 200 %.

Étapes suivantes

Découvrez comment...

Configurer les paramètres de Profiler