Dela via

Visa Application Insights Profiler-data

  • Artikel

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 Profiler ska kunna ladda upp spårningar måste tjänsten aktivt hantera begäranden.

Om du nyligen har aktiverat Profiler 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:

  1. På översiktssidan för Application Insights för din Azure-tjänst väljer du Prestanda på den vänstra menyn.

  2. I fönstret Prestanda väljer du Profiler på den översta menyn för Profiler-inställningar.

    Screenshot of the Profiler button from the Performance pane.

  3. När sidan Profiler-inställningar har lästs in väljer du Profil nu.

    Screenshot of Profiler page features and settings.

Visa spårningar

  1. När Profiler-sessionerna har körts går du tillbaka till fönstret Prestanda .

  2. Under Öka detaljnivå i... väljer du Profiler-spårningar för att visa spårningarna.

    Screenshot of trace explorer page.

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

Profiler använder en kombination av samplingsmetoder och instrumentation för att analysera programmets prestanda. Profileraren utför en detaljerad samling:

  • 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 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:t kan 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...

Konfigurera profileringsinställningar