Visa Application Insights Profiler för .NET-data
Anta att du kör ett webbprestandatest. Du behöver spårningar för att förstå hur webbappen körs under belastning. I den här artikeln ska du:
- Generera trafik till webbappen genom att starta ett webbprestandatest eller starta en Profiler-session på begäran.
- Visa Profiler-spårningar efter belastningstestet eller Profiler-sessionen.
- Lär dig hur du läser prestandadata för Profiler och anropsstacken.
Generera trafik till din Azure-tjänst
För att .NET Profiler ska kunna ladda upp spårningar måste tjänsten aktivt hantera begäranden.
Om du nyligen har aktiverat Profiler för .NET kör du ett kort belastningstest med Azure Load Testing.
Om din Azure-tjänst redan har inkommande trafik eller om du bara vill generera trafik manuellt hoppar du över belastningstestet och startar en Profiler-session på begäran:
På översiktssidan för Application Insights för din Azure-tjänst väljer du Prestanda på den vänstra menyn.
I fönstret Prestanda väljer du Profiler på den översta menyn för Profiler-inställningar.
När sidan Profiler-inställningar har lästs in väljer du Profil nu.
Visa spårningar
När Profiler-sessionerna har körts går du tillbaka till fönstret Prestanda .
Under Öka detaljnivå i... väljer du Profiler-spårningar för att visa spårningarna.
Spårningsutforskaren visar följande information:
| Filter | beskrivning |
|---|---|
| Profilträd v. Flamdiagram | Visa spårningarna som antingen ett träd eller i grafform. |
| Frekvent sökväg | Välj för att öppna den största lövnoden. I de flesta fall är den här noden nära en flaskhals för prestanda. |
| Ramverksberoenden | Välj för att visa var och en av de spårningsramverksberoenden som är associerade med spårningarna. |
| Dölj händelser | Skriv in strängar som ska döljas från spårningsvyn. Välj Föreslagna händelser för förslag. |
| Event | Händelse- eller funktionsnamn. Trädet visar en blandning av kod och händelser som har inträffat, till exempel SQL- och HTTP-händelser. Den översta händelsen representerar den totala varaktigheten för begäran. |
| Modul | Modulen där den spårade händelsen eller funktionen inträffade. |
| Trådtid | Tidsintervallet mellan åtgärdens start och slutet av åtgärden. |
| Tidslinje | Tiden då funktionen eller händelsen kördes i förhållande till andra funktioner. |
Läsa prestandadata
.NET Profiler använder en kombination av samplingsmetoder och instrumentation för att analysera programmets prestanda. När du utför en detaljerad samling gör .NET Profiler:
- Exempel på instruktionspekaren för varje dators CPU varje millisekunder.
- Varje exempel fångar upp trådens fullständiga anropsstack och ger detaljerad information på både höga och låga abstraktionsnivåer.
- Samlar in händelser för att spåra aktivitetskorrelation och orsakssamband, inklusive:
- Kontextväxlingshändelser
- Händelser för aktivitetsparallellt bibliotek (TPL)
- Trådpoolshändelser
Anropsstacken som visas i tidslinjevyn är resultatet av samplingen och instrumentationen. Eftersom varje exempel samlar in trådens fullständiga anropsstack innehåller den kod från Microsoft .NET Framework och andra ramverk som du refererar till.
Objektallokering (clr! JIT_New eller clr! JIT_Newarr1)
Clr! JIT_New och clr! JIT_Newarr1 är hjälpfunktioner i .NET Framework som allokerar minne från en hanterad heap.
- Clr! JIT_New anropas när ett objekt allokeras.
- Clr! JIT_Newarr1 anropas när en objektmatris allokeras.
Dessa två funktioner fungerar vanligtvis snabbt. Om clr! JIT_New eller clr! JIT_Newarr1 tar upp tid i tidslinjen kan koden allokera många objekt och förbruka stora mängder minne.
Läser in kod (clr! ThePreStub)
Clr! ThePreStub är en hjälpfunktion i .NET Framework som förbereder koden för den första körningen, som vanligtvis innehåller JIT-kompilering (just-in-time). För varje C#-metod, clr! ThePreStub bör anropas högst en gång under en process.
Om clr! ThePreStub tar extra tid för en begäran, det är den första begäran att köra den metoden. .NET Framework-körningen tar lång tid att läsa in den första metoden. Tänk på att:
- Använd en uppvärmningsprocess som kör den delen av koden innan användarna kommer åt den.
- Kör inbyggd avbildningsgenerator (ngen.exe) på dina sammansättningar.
Lås konkurrens (clr! JITutil_MonContention eller clr! JITutil_MonEnterWorker)
Clr! JITutil_MonContention eller clr! JITutil_MonEnterWorker anger att den aktuella tråden väntar på att ett lås ska släppas. Den här texten visas ofta när du:
- Kör en C# LOCK-instruktion ,
- Anropa metoden Monitor.Enter , eller
- Anropa en metod med attributet MethodImplOptions.Synchronized .
Låskonkurration uppstår vanligtvis när tråd A hämtar ett lås och tråd B försöker hämta samma lås innan tråd A släpper det.
Läser in kod ([COLD])
Om .NET Framework-körningen kör ooptimerad kod för första gången innehåller metodnamnet [COLD]:
mscorlib.ni![COLD]System.Reflection.CustomAttribute.IsDefined
För varje metod bör den visas en gång under processen, som mest.
Om det tar lång tid att läsa in kod för en begäran är det begärans initierade körning av den ooptimerade delen av metoden. Överväg att använda en uppvärmningsprocess som kör den delen av koden innan användarna kommer åt den.
Skicka HTTP-begäran
Metoder som HttpClient.Send anger att koden väntar på att en HTTP-begäran ska slutföras.
Databasåtgärd
Metoder som SqlCommand.Execute anger att koden väntar på att en databasåtgärd ska slutföras.
Väntar (AWAIT_TIME)
AWAIT_TIME anger att koden väntar på att en annan uppgift ska slutföras. Den här fördröjningen inträffar med C# AWAIT-instruktionen . När koden gör en C# AWAIT:
- Tråden varvar ned och returnerar kontrollen till trådpoolen.
- Det finns ingen blockerad tråd som väntar på att AWAIT ska slutföras.
Men logiskt sett är tråden som gjorde AWAIT "blockerad" och väntar på att åtgärden ska slutföras. Instruktionen AWAIT_TIME anger den blockerade tiden som väntar på att aktiviteten ska slutföras.
Om AWAIT_TIME verkar finnas i ramverkskoden i stället för din kod kan .NET Profiler visa:
- Den ramverkskod som används för att köra AWAIT
- Kod som används för att spela in telemetri om AWAIT
Du kan avmarkera kryssrutan Framework-beroenden överst på sidan om du bara vill visa koden och göra det enklare att se var AWAIT kommer ifrån.
Blockerad tid
BLOCKED_TIME anger att koden väntar på att en annan resurs ska vara tillgänglig. Det kan till exempel vänta på:
- Ett synkroniseringsobjekt
- En tråd som ska vara tillgänglig
- En begäran om att slutföra
Ohanterad Async
För att asynkrona anrop ska spåras mellan trådar genererar .NET Framework ETW-händelser och skickar aktivitets-ID:t mellan trådar. Eftersom ohanterad (intern) kod och vissa äldre format för asynkron kod saknar dessa händelser och aktivitets-ID:er kan .NET Profiler inte spåra tråden och funktionerna som körs i tråden. Det här objektet har etiketten Ohanterad Async i anropsstacken. Ladda ned ETW-filen för att använda PerfView för mer insikt.
CPU-tid
Processorn är upptagen med att köra anvisningarna.
Disktid
Programmet utför diskåtgärder.
Nätverkstid
Programmet utför nätverksåtgärder.
När kolumn
Kolumnen När är en visualisering av de olika inkluderande exempel som samlats in för en nod över tid. Det totala intervallet för begäran är uppdelat i 32 tids bucketar, där nodens inkluderande exempel ackumuleras. Varje bucket representeras som en stapel. Höjden på stapeln representerar ett skalat värde. För följande noder representerar fältet förbrukningen av en av resurserna under bucketen:
- Noder markerade CPU_TIME eller BLOCKED_TIME.
- Noder med en uppenbar relation till att använda en resurs (till exempel en CPU, disk eller tråd).
För dessa mått kan du få ett värde på mer än 100 % genom att använda flera resurser. Om du till exempel använder två processorer under ett intervall i genomsnitt får du 200 %.
Nästa steg
Lär dig hur du...