Anzeigen von Application Insights Profiler-Daten
Angenommen, Sie führen einen Webleistungstest aus. Sie benötigen Ablaufverfolgungen, um zu verstehen, wie Ihre Web-App beim Laden ausgeführt wird. In diesem Artikel führen Sie Folgendes durch:
- Generieren Sie Datenverkehr zu Ihrer Web-App, indem Sie einen Webleistungstest starten oder eine Profiler-On-Demand-Sitzung starten.
- Zeigen Sie die Profiler-Ablaufverfolgungen nach dem Ladetest oder der Profiler-Sitzung an.
- Erfahren Sie, wie Sie die Profiler-Leistungsdaten und den Aufrufstapel lesen.
Generieren von Datenverkehr zu Ihrem Azure-Dienst
Damit Profiler Ablaufverfolgungen hochladen kann, muss Ihr Dienst Anforderungen aktiv verarbeiten.
Wenn Sie den Profiler neu aktiviert haben, führen Sie einen kurzen Ladetest mit Azure Load Testing aus.
Wenn Ihr Azure-Dienst bereits eingehenden Datenverkehr hat oder Wenn Sie nur manuell Datenverkehr generieren möchten, überspringen Sie den Auslastungstest, und starten Sie eine Profiler-On-Demand-Sitzung:
Wählen Sie auf der Übersichtsseite „Application Insights“ für Ihren Azure-Dienst im linken Menü die Option Leistung aus.
Wählen Sie im Bereich Leistung die Option Profiler im oberen Menü für Profiler-Einstellungen aus.
Nachdem die Seite "Profiler-Einstellungen" geladen wurde, wählen Sie Profil jetzt aus.
Ablaufverfolgungen anzeigen
Kehren Sie nach Abschluss der Ausführung der Profiler-Sitzungen zum Bereich Leistung zurück.
Wählen Sie unter Drill into...Profiler-Ablaufverfolgungen aus, um die Ablaufverfolgungen anzuzeigen.
Im Ablaufverfolgungs-Explorer werden die folgenden Informationen angezeigt:
| Filtern | BESCHREIBUNG |
|---|---|
| Profilstruktur v. Flammendiagramm | Zeigen Sie die Ablaufverfolgungen entweder als Struktur oder in Diagrammform an. |
| Langsamster Pfad | Wählen Sie aus, um den größten Blattknoten zu öffnen. In den meisten Fällen befindet sich dieser Knoten in der Nähe eines Leistungsengpasses. |
| Frameworkabhängigkeiten | Wählen Sie aus, um jede der überwachten Frameworkanhängigkeiten anzuzeigen, die den Ablaufverfolgungen zugeordnet sind. |
| Ereignisse ausblenden | Geben Sie Zeichenfolgen ein, um sie aus der Ablaufverfolgungsansicht auszublenden. Wählen Sie Vorgeschlagene Ereignisse für Vorschläge aus. |
| Ereignis | Ereignis- oder Funktionsname. Die Struktur enthält eine Mischung aus Code und aufgetretenen Ereignissen (wie etwa SQL- und HTTP-Ereignisse). Das oberste Ereignis stellt die Gesamtdauer der Anforderung dar. |
| Modul | Das Modul, in dem das Ablaufverfolgungsereignis oder die Funktion aufgetreten ist. |
| Threadzeit | Das Zeitintervall zwischen Beginn und Ende des Vorgangs. |
| Zeitachse | Der Zeitpunkt, an dem die Funktion oder das Ereignis relativ zu anderen Funktionen aktiv war. |
Lesen von Leistungsdaten
Profiler verwendet eine Kombination aus Samplingmethoden und Instrumentierung, um die Leistung Ihrer Anwendung zu analysieren. Beim Ausführen einer detaillierten Sammlung führt der Profiler Folgendes aus:
- Beispiele für den Anweisungszeiger jeder Computer CPU jeder Millisekunden.
- Jedes Beispiel erfasst den vollständigen Aufrufstapel des Threads und gibt detaillierte Informationen auf hohen und niedrigen Abstraktionsebenen.
- Erfasst Ereignisse zum Nachverfolgen der Aktivitätskorrelation und Kausalität, einschließlich:
- Kontextwechselereignisse
- Task Parallel Library (TPL)-Ereignisse
- Threadpoolereignisse
Die in der Zeitachsenansicht angezeigte Aufrufliste ist das Ergebnis des oben erwähnten Samplings und der Instrumentierung. Da jede Stichprobe den vollständigen Aufrufstapel des Threads erfasst, enthält es Code aus Microsoft .NET Framework und alle anderen Frameworks, auf die Sie verweisen.
Objektzuordnung („clr!JIT_New“ oder „clr!JIT_Newarr1“)
clr!JIT_New und clr!JIT_Newarr1 sind Hilfsfunktionen in .NET Framework, die Arbeitsspeicher von einem verwalteten Heap zuweisen.
- clr!JIT_New wird aufgerufen, wenn ein Objekt zugeordnet wird.
- clr!JIT_Newarr1 wird aufgerufen, wenn ein Objektarray zugeordnet wird.
Diese beiden Funktionen funktionieren in der Regel schnell. Sollten clr!JIT_New oder clr!JIT_Newarr1 auf Ihrer Zeitachse viel Zeit beanspruchen, deutet dies darauf hin, dass der Code viele Objekte zuordnet und eine erhebliche Menge an Arbeitsspeicher beansprucht.
Laden von Code (clr!ThePreStub)
Clr! ThePreStub ist eine Hilfsfunktion in .NET Framework, die den Code für die anfängliche Ausführung vorbereitet, die normalerweise die Just-in-Time-Kompilierung (JIT) enthält. Während eines Prozesses sollte clr!ThePreStub für jede C#-Methode höchstens einmal aufgerufen werden.
Wenn clr!ThePreStub für eine Anforderung viel Zeit beansprucht, ist dies ein Hinweis darauf, dass die Anforderung die erste ist, die diese Methode ausführt. Die .NET Framework-Laufzeit nimmt eine erhebliche Zeit in Anspruch, um die erste Methode zu laden. Berücksichtigen Sie dabei Folgendes:
- Verwenden Sie ggf. einen Vorbereitungsprozess, der diesen Teil des Codes ausführt, bevor Ihre Benutzer darauf zugreifen.
- Ausführen des nativen Image-Generators (ngen.exe) in Ihren Assemblys.
Sperrkonflikt („clr!JITutil_MonContention“ oder „clr!JITutil_MonEnterWorker“)
clr!JITutil_MonContention oder clr!JITutil_MonEnterWorker gibt an, dass der aktuelle Thread auf die Aufhebung einer Sperre wartet. Dieser Text wird häufig angezeigt, wenn Sie:
- Eine C# -LOCK-Anweisung ausführen,
- die Monitor.Enter-Methode aufrufen oder
- eine Methode mit dem Attribut MethodImplOptions.Synchronized aufrufen.
Ein Sperrkonflikt ist meist darauf zurückzuführen, dass Thread A eine Sperre abruft und Thread B versucht, die gleiche Sperre abzurufen, bevor sie von Thread A wieder aufgehoben wurde.
Laden von Code ([COLD])
Wenn die .NET Framework Laufzeit zum ersten Mal nicht optimierten Code ausführt, enthält der Methodenname [COLD]:
mscorlib.ni![COLD]System.Reflection.CustomAttribute.IsDefined
Während des Prozesses sollte dies höchstens für jede Methode einmal angezeigt werden.
Falls das Laden von Code bei einer Anforderung sehr lange dauert, ist die Anforderung die erste, die den nicht optimierten Teil der Methode ausführt. Verwenden Sie ggf. einen Vorbereitungsprozess, der diesen Teil des Codes ausführt, bevor Ihre Benutzer darauf zugreifen.
Senden von HTTP-Anforderungen
Methoden wie HttpClient.Send deuten darauf hin, dass der Code auf den Abschluss einer HTTP-Anforderung wartet.
Datenbankvorgang
Methoden wie SqlCommand.Execute deuten darauf hin, dass der Code auf den Abschluss eines Datenbankvorgangs wartet.
Warten (AWAIT_TIME)
AWAIT_TIME deutet darauf hin, dass der Code auf den Abschluss einer anderen Aufgabe wartet. Diese Verzögerung tritt bei C#-Anweisungen vom Typ AWAIT auf. Wenn der Code ein C# AWAIT ausführt:
- Der Thread entwickelt sich und gibt die Steuerung an den Threadpool zurück.
- Es gibt keinen blockierten Thread, der auf den Abschluss des AWAIT wartet.
Logisch betrachtet ist allerdings der Thread, der AWAIT ausgeführt hat, blockiert, während er auf die Beendigung des Vorgangs wartet. Die AWAIT_TIME-Anweisung gibt die blockierte Zeit an, für die auf die Beendigung der Aufgabe gewartet wird.
Wenn sich AWAIT_TIME im Frameworkcode anstelle Ihres Codes zu befinden scheint, zeigt der Profiler möglicherweise Folgendes an:
- Der Frameworkcode, der zum Ausführen von AWAIT verwendet wird
- Der Code, der zum Aufzeichnen von Telemetriedaten über AWAIT verwendet wird
Sie können das Kontrollkästchen Frameworkabhängigkeiten oben auf der Seite deaktivieren, um nur Ihren Code anzuzeigen und leichter zu erkennen, woher AWAIT stammt.
Blockierte Zeit
BLOCKED_TIME gibt an, dass der Code darauf wartet, dass eine andere Ressource verfügbar ist. Es könnte beispielsweise warten auf:
- ein Synchronisierungsobjekt
- einen verfügbaren Thread
- die Beendigung einer Anforderung
Async (nicht verwaltet)
Damit asynchrone Aufrufe über Threads nachverfolgt werden können, gibt .NET Framework ETW-Ereignisse aus und übergibt Aktivitäts-IDs zwischen Threads. Da nicht verwalteter (systemeigener) Code und einige ältere Formatvorlagen von asynchronem Code diese Ereignisse und Aktivitäts-IDs fehlen, kann der Profiler den Thread und die im Thread ausgeführten Funktionen nicht nachverfolgen. Dieses Element wird im Aufrufstapel als nicht verwaltete Async bezeichnet. Laden Sie die ETW-Datei herunter, um PerfView für weitere Erkenntnisse zu verwenden.
CPU-Zeit
Die CPU ist mit der Ausführung der Anweisungen beschäftigt.
Datenträgerzeit
Die Anwendung führt Datenträgervorgänge aus.
Netzwerkzeit
Die Anwendung führt Netzwerkvorgänge aus.
Wann-Spalte
Die Spalte Wann ist eine Visualisierung der Vielfalt inklusiver Stichproben für einen Knoten im Zeitverlauf. Der gesamte Bereich einer Anforderung wird in 32 Time-Buckets aufgeteilt, wobei sich die inklusivem Stichproben des Knotens akkumulieren. Jeder Zeitrahmen wird als Balken dargestellt. Die Höhe der Balken stellt einen skalierten Wert dar. Für die folgenden Knoten stellt die Leiste den Verbrauch einer der Ressourcen während des Buckets dar:
- Knoten, die mit CPU_TIME oder BLOCKED_TIME markiert sind.
- Knoten mit einer offensichtlichen Beziehung zum Verbrauch einer Ressource (z. B. eine CPU, ein Datenträger oder ein Thread).
Durch die Nutzung mehrerer Ressourcen können Sie bei diesen Metriken einen Wert über der 100 %-Marke erhalten. Wenn Sie also beispielsweise innerhalb eines Intervalls im Schnitt zwei CPUs verwenden, erhalten Sie 200 %.
Nächste Schritte
Weitere Informationen: