Dela via

Felsöka långsamma sidsvar och låser sig

gäller för: Internet Information Services (IIS), ASP.NET, ASP.NET Core

Den här artikeln innehåller vägledning om hur du samlar in och analyserar data för att felsöka långsamma sidsvar och problem med låsning.

Fastställa rätt felsökningsguide

Sid långsamhet och låser sig kan åtföljas av ett eller flera av följande villkor. Det är viktigt att identifiera dessa villkor så att du kan fokusera felsökningen i enlighet med detta. Ta reda på vilket av dessa villkor som bäst beskriver problemet du felsöker och följ lämplig felsökningsguide.

Datainsamling

Här är en lista över användbara data att samla in för långsamma sidsvar eller låsningssituationer. Alla dessa data krävs inte för varje problem. Du kan samla in data beroende på situationen.

IIS-loggfångare

IIS Log Catcher samlar in olika historiska loggar och konfigurationsdata samtidigt, inklusive IIS-webbloggarna, som är särskilt användbara för att diagnostisera problem med långsamma sidsvar. Den samlar också in alla .config filer, vilket kan bidra till att ge en förståelse för de olika webbprogrammen på servern och hur de konfigureras. Om FREB-loggning redan har konfigurerats ingår ÄVEN FREB-loggar med IIS Log Catcher-data. IIS Log Catcher samlar också in händelseloggarna system och program.

Ladda ned verktyget IIS Log Catcher och använd det för att samla in data genom att följa anvisningar.

Konfigurationsfiler

applicationhost.config och web.config samlas in som en del av IIS Log Catcher-data. Dessa filer är användbara för att förstå konfigurationen av IIS och de enskilda webbprogrammen på servern.

Om verktyget IIS Log Catcher inte automatiskt samlar in konfigurationsfilerna måste du samla in dem manuellt.

Filen applicationhost.config finns på c:\windows\system32\inetsrv\config\. De web.config filerna finns i rotkatalogen för varje program. För standardwebbplatsens program finns till exempel filen web.config i c:\inetpub\wwwroot. Rotkatalogerna för program kan finnas var som helst i filsystemet. Om du vill identifiera rotkatalogen för en viss plats kontrollerar du applicationhost.config filen för plats och dess attributet physicalPath eller granskar inställningarna i IIS-hanteraren.

IIS-webbloggar (W3SVC-loggar)

Samla in IIS-loggar från en tidpunkt då långsamheten inträffar. Detta kan vara användbart för att bekräfta att det tidsbegränsade fältet återspeglar långsamheten. Det kan också hjälpa dig att begränsa sidan eller sidorna som svarar långsamt.

Om verktyget IIS Log Catcher inte automatiskt samlar in webbloggarna måste du samla in dem manuellt.

Som standard finns dessa loggar i c:\inetpub\logs\logfiles. Varje webbplats har en egen katalog med namnet W3SVC# där # är SiteID. Loggplatsen är dock anpassningsbar. För att hitta de anpassade loggplatserna kan du behöva granska applicationhost.config-filen för logFile och katalog inställningar som anger var loggarna lagras.

Händelseloggar för Windows-system, program och säkerhet

Dessa samlas in som en del av IIS Log Catcher-data. Även om händelseloggarna vanligtvis inte används vid felsökning av långsamma sidsvar och låser sig, är det bästa praxis att fortsätta samla in dem eftersom de kan användas senare i felsökningen.

Om IIS Log Catcher-verktyget inte samlar in händelseloggar automatiskt måste du samla in dem manuellt.

Samla in händelseloggar direkt från Loggboken. Spara dem som .evtx filer och visa dem i Loggboken på din egen server.

Fiddler-verktygsspårning eller Microsoft Edge HAR-spårning

Tidslinjevyn i dessa spårningar kan hjälpa dig att begränsa vilken sida eller vilka sidor i webbprogrammet som är långsamma. Detta hjälper till att samla in FREB-loggar för endast långsamma sidor.

Fiddler Classic är ett webbläsartillägg från tredje part som fungerar som proxy för webbläsaren. Fiddler börjar samla in data så snart de har öppnats. Följ dessa steg för att samla in spårningar av SSL-krypterade begäranden med Fiddler Classic:

  1. Ladda ned och installera Fiddler Classic.
  2. Öppna Fiddler Classic, välj Tools>Options>HTTPSoch markera kryssrutan Capture HTTPS CONNECTs och Dekryptera HTTPS-trafik.
  3. Välj OK.
  4. Återskapa långsamheten när du kör Fiddler.
  5. Välj Fil>Spara>alla sessioner om du vill spara alla sessioner som en .saz fil.

Microsoft Edge- eller Chrome-webbläsare kan samla in HAR-spårningar direkt. Följ dessa steg för att samla in HAR-spårningar:

  1. Öppna webbläsaren och välj F12 för att öppna Utvecklarverktyg.
  2. Välj >Bevara loggen.
  3. Återskapa problemet med långsamhet.
  4. Välj Exportera HAR- för att spara spårningen som en .HAR fil. .HAR filer kan importeras till Microsoft Edge eller Chrome för senare granskning.

FREB-loggar (Failed Request Trace)

FREB-loggar kan hjälpa dig att identifiera vilken IIS-modul som tar längst tid att bearbeta begäran. Den kan identifiera långsamheten i autentiseringen eller i själva programkoden.

Spårning av misslyckade förfrågningar är en IIS-modul. Den är tillgänglig för användning när spårningsmodulen är installerad. Spårning kan installeras från Serverhanteraren eller genom att köra följande PowerShell-kommando:

Add-WindowsFeature -Name Web-Http-Tracing

Innan du konfigurerar en FREB-regel kontrollerar du W3SVC-loggarna för att identifiera begäranden som tar lång tid att slutföra. Identifiera enskilda sidbegäranden som är långsamma med hjälp av fälten cs-uri-stem och time-taken.

  • Om du kan identifiera några specifika sidor som är långsamma skapa en FREB-regel för den specifika sidan eller sidorna. Om du skapar regeln för en viss sida ska du inte använda tidsåtgången i FREB-regeln. Använd i stället statuskoden från W3SVC-loggarna.

  • Om du inte kan identifiera en specifik sida för att skapa FREB-regeln kan du använda allt innehåll och ange en tid som tas i FREB-regeln i stället, vilket ger dig loggar över alla begäranden som tar mer än den angivna tiden att slutföra.

    Anmärkning

    Den här metoden kan ge dig falska positiva identifieringar. Observera också att när du skapar FREB-loggar baserat på tidsåtgången upphör loggen när begäran når den angivna tiden. Om den angivna tiden är för kort kan du inte identifiera var långsamheten inträffar.

Problemet är pågående, lätt att återskapa eller frekvent

Anmärkning

FREB-loggar som utlöses av någon statuskodregel ger en vy över alla moduler som inträffar längs IIS-pipelinen under en begärandelivslängd, tillsammans med den tid varje modul tar.

FREB-loggar som utlöses av en viss tidsåtgångsregel (till exempel 20 sekunder) visar bara information upp till det värdet, vilket innebär att allt som denna begäran går igenom utöver den här tiden inte kommer att vara tillgängligt i loggen.

  • Om svaret tas emot efter en viss fördröjning (till exempel 30 sekunder) följer du dessa steg för att diagnostisera problemet:

    1. Kontrollera statuskoden för det mottagna svaret.

      Använd utvecklarverktyg för webbläsare eller IIS-loggar för att fastställa statuskoden för det fördröjda svaret.

    2. Konfigurera FREB:er baserat på statuskoden i steg 1.

    3. Visa de genererade FREB:erna för att förstå vilken modul som orsakar långsamheten.

      Om du inte är bekant med hur du tolkar FREB kan du läsa Läsa en FREB-logg, en spårning av misslyckade förfrågningar: IIS-begärandebearbetning av pipelinekörning.

    Om du upptäcker att någon modul från tredje part orsakar långsamheten kontaktar du tredje part för att undersöka problemet. Men om långsamheten beror på programkoden måste du samla in minnesdumpar för ytterligare undersökning.

  • Om inget svar tas emot alls (fullständigt låser sig) eller tas emot efter en mycket lång tid följer du dessa steg för att diagnostisera problemet:

    1. Konfigurera FREB baserat på en specifik tidsregel.

      Det tidströskelvärde som du anger för FREB-loggar bör vara högre än vad som anses vara normal eller acceptabel tid för svaret. Om du vet att det är normalt och förväntas att ett svar tar 10 sekunder konfigurerar du FREB:er ett högre tal som 20 sekunder eller 30 sekunder.

    2. Fortsätt med samma analyssteg som ovan.

Problemet är tillfälligt eller svårt att återskapa

Om ett problem är tillfälligt eller svårt att återskapa kan det vara ineffektivt att vänta på att det ska hända igen bara för att samla in FREB-loggar. Det kan ta veckor eller månader innan problemet uppstår igen, och om FREB-loggarna är otillräckliga måste du vänta igen för att samla in minnesdumpar. För att undvika den här fördröjningen rekommenderar vi att du genererar minnesdumpar under den första förekomsten av problemet.

Om begäranden normalt tar millisekunder men ibland tar 1 eller några sekunder kan det vara svårt att undersöka den här långsamheten. Det kanske inte är praktiskt att generera minnesdumpar under sådana långsamma perioder eftersom:

  • Felsökningsprogram lägger till omkostnader, vilket kan bidra till långsamheten i viss utsträckning.
  • Den ursprungliga långsamheten och omkostnaderna kan överlappa varandra.
  • Det är kanske inte möjligt att generera flera minnesdumpar inom en begärandelivslängd.

Du kan använda PerfView för att samla in ETW-spårningar i stället. Du kan dock fortfarande vara mycket begränsad i undersökningen om tiden är för fördelad i stället för att koncentreras till en viss åtgärd.

Kontrollera alltid IIS-loggarna efter mycket långsamma begäranden och felsöka dem, eftersom detta indirekt kan lösa problem med kortare långsamhet.

Detaljerade steg för att samla in FREB-loggar baserat på tidsåtgång

Viktigt!

Om du vill konfigurera FREB-loggar kontrollerar du att spårningsrolltjänsten är installerad för IIS.

Följ dessa steg för att installera spårningsrolltjänsten för IIS:

  1. Öppna Serverhanteraren och välj Hantera>Lägg till roller och funktioner.
  2. I fönstret Lägg till roller och funktioner väljer du Nästa tills du når sidan Serverroller .
  3. Expandera Webbserver (IIS)>Webbserverhälsa>och diagnostik och markera kryssrutan Spårning.
  4. Välj Nästa för efterföljande steg och välj sedan Installera.

När spårningsrolltjänsten har installerats följer du dessa steg för att samla in FREB:

  1. Öppna kommandofönstret Kör.

  2. Starta inetmgr.

  3. I IIS-hanteraren går du till fönstret Anslutningar , expanderar datornamnet, expanderar Webbplatser och väljer sedan målwebbplatsen.

    Skärmbild av målwebbplatsen i IIS-hanteraren.

  4. Dubbelklicka på Spårningsregler för misslyckade förfrågningar.

    Skärmbild av standardwebbplatsens startsida.

  5. I fönstret Åtgärder väljer du Lägg till.

  6. I guiden Lägg till spårningsregel för misslyckad begäran går du till sidan Ange innehåll till spårning och väljer Allt innehåll>Nästa.

    Skärmbild av sidan Ange innehåll till spårning i fönstret Lägg till spårningsregel för misslyckade förfrågningar.

  7. På sidan Definiera spårningsvillkor uppdaterar du fältet tid det tar enligt den tid som du märker att begäran eller sidan tar och väljer Nästa.

    Om begäran till exempel tar mindre än en sekund, men nu tar 20 sekunder, skriver du 20 i fältet Tidsåtgång.

  8. På sidan Välj spårningsproviders går du till Providers och markerar alla kryssrutor. Under Områden kontrollerar du att alla kryssrutor är markerade för varje provider. Under Utförlighet väljer du Utförligt. Välj Slutför.

  9. Aktivera spårning av misslyckade begäranden för platsen och konfigurera Loggfilskatalogen:

    1. I fönstret Anslutningar expanderar du datornamnet, expanderar Webbplatser och väljer sedan Standardwebbplats.

    2. I fönstret Åtgärder går du till Konfigurera och väljer Spårning av misslyckade förfrågningar.

      Skärmbild av spårningsalternativet För misslyckad begäran.

    3. I dialogrutan Redigera inställningar för spårning av misslyckade begäranden markerar du kryssrutan Aktivera, anger fältet Katalog till %SystemDrive%\inetpub\logs\FailedReqLogFiles och anger Maximalt antal spårningsfiler till 1 000.

      Skärmbild av fönstret Redigera webbplats med misslyckade spårningsinställningar för begäranden.

    4. Välj OK.

Fullständig processdumpning i användarläge

En serie processdumpar (2–4) som tas när begäranden är långsamma eller låsta kan tala om för dig vilket metodanrop i programmet som är långsamt. Det kan också tyda på fördröjningar i fjärrbegäranden till fjärrwebbtjänster eller serverdelsdatabaser.

Problemet är enkelt att återskapa

Om problemet kan återskapas eller för närvarande inträffar kan du samla in flera manuella dumpar av arbetsprocessen som är värd för apppoolen.

Försök att utrymme dumpar cirka 30 sekunders mellanrum, men tänk på den totala långsamheten. Om den totala långsamheten är kortare (till exempel 20 till 30 sekunder totalt) dumpar utrymmet närmare varandra för att passa minst två dumpar inom den långsamma perioden.

Du kan också använda ProcDump, särskilt när du inte kan installera DebugDiag på servern eller om installationen kräver det.

Om problemet är mer tillfälligt bör du överväga att samla in både FREB-spårningar och dumpar. Eller om det är enklare att använda ProcDump följer du stegen i Konfigurera FREB för att utlösa minnesdumpar med hjälp av ProcDump.exe avsnittet (konfigurera FREB för tidsåtgång i stället för statuskod).

Problemet är inte enkelt att återskapa

Om problemet inte är enkelt att återskapa kan du använda FREB-regeln för att generera dumpar baserat på den tid det tar. Mer information finns i Använda FREB för att generera en dump på en tidskrävande begäran.

Viktigt!

När du konfigurerar FREB för tidsåtgång justerar du den tid det tar att utlösare beroende på hur långsamma svar är. Detta säkerställer att endast problematiska begäranden samlas in och minimerar falska positiva identifieringar.

Deadlock identifierade låsningar

Försiktighet

  • Om långsamhet åtföljs av hög CPU bör du undvika att samla in loggar när processoranvändningen är extremt hög (till exempel >=95), eftersom detta kan leda till att servern låser sig eller misslyckas med att samla in loggar på grund av otillräckliga CPU-resurser.

  • Om du samlar in loggar manuellt kontrollerar du att CPU-användningen är lägre än tröskelvärdet för att underlätta RDP-åtkomst till servern. Om det behövs kan du prova att återanvända programpoolen före logginsamlingen, men var medveten om effekten på befintliga begäranden och förklara det för kunderna.

  • Om processorn når ett sådant värde inom några sekunder efter återvinningen bör du överväga att minska belastningen mot processen (oavsett om det är ett belastningstest eller en produktionsbelastning).

  • På samma sätt, om långsamhet åtföljs av högt minne, försök att undvika att samla in minnesdumpar med hög w3wp.exe minnesförbrukning som >10 GB om möjligt (eller hög total serverminnesförbrukning > 95%). Om problem kan återskapas med lägre minne kan du överväga att återanvända apppoolen eller minska belastningen om det hjälper som nämnts.

  • Använd inte Aktivitetshanteraren för att samla in dumpar. Även om de genererade dumparna ibland är användbara är de i många fall inte det. Mer specialiserade verktyg som DebugDiag och Procdump har bättre förståelse för hanterad kod och kan ge mer detaljerad information som är specifikt relaterad till ASP.NET-program. Dessutom tar dessa två verktyg hand om processbitnessen och du behöver inte oroa dig. Om 64-bitarsprocessen i Aktivitetshanteraren används för att generera dumpar av en 32-bitarsprocess, eller tvärtom, är dumparna värdelösa.

Andra data

Samla in följande dataalternativ om det behövs:

  • PerfView-spårningar

    PerfView kan hjälpa till att isolera problem med långsamma prestanda i själva webbprogrammet. PerfView-spårningar samlas in under en tid av långsamhet. Dessa spårningar visar de enskilda metoder eller funktioner som är långsamma.

  • Nätverksspårningar

    Nätverksspårningar är användbara när du spårar långsamma sidsvar och låser sig i samband med nätverksproblem.

  • Prestandaövervakarens logg

    PerfMon-loggning är användbart när du spårar långsamma sidsvar och låser sig i samband med hög CPU- eller hög minnesanvändning.

Tidsutlösare

För att lösa problemet är det viktigt att fastställa lämpligt tidsvärde som utlöser genereringen av minnesdumpar.

Detta innebär att förstå svarstiderna från dina IIS-loggar (Internet Information Services) under perioder då problemet var närvarande och när det inte var det.

Följ dessa steg för att identifiera lämplig tidsutlösare:

  1. Granska IIS-loggar:

    Analysera dina IIS-loggar över olika tidsintervall för att observera svarstiderna. Identifiera vilken förväntad svarstid som är under normala omständigheter.

  2. Identifiera skillnader i svarstid:

    När problemet uppstår bör du notera de minsta, högsta och vanligaste svarstiderna.

  3. Ange ett utlösande mål:

    Sträva efter att generera minst två minnesdumpar i följd under den period då den långsamma begäran är aktiv.

    Om det till exempel är vanligt att ett svar tar 10 sekunder fokuserar du på svarstider som överskrider den här varaktigheten. Om ett problem gör att svarstiden sträcker sig till 60 sekunder eller mer kan du samla in minnesdumpar med intervaller som 30, 40 och 50 sekunder.

  4. Undvik falska positiva identifieringar:

    Det är viktigt att inte initiera en minnesdump vid något högre tider som 11 eller 12 sekunder, eftersom detta kan leda till falska positiva identifieringar. Målet är att samla in dumparna under den problematiska perioden utan att avsluta begäran i förtid.

  5. Identifiera tidpunkten för dumpar:

    Kontrollera att dumpar inte utlöses i slutet av begärans livslängd, eftersom begäran kan slutföras innan efterföljande dumpar genereras.

  6. Utvärdera de vanligaste långsamma svaren:

    Om den långsammaste svarstiden inte inträffar ofta fokuserar du på den vanligaste långsamma svarstiden som observerats i IIS-loggarna.

Anmärkning

  • Du kan behöva flera försök för att få en bra uppsättning minnesdumpar som är användbara.
  • Se till att du har tillräckligt med utrymme på den enhet som du väljer för att lagra de genererade minnesdumparen. Varje minnesdump har samma storlek som processen vid tidpunkten för genereringen. Om till exempel processens storlek är 1 GB vid tidpunkten för genereringen av minnesdumpar kräver generering av tre dumpar 4 GB utrymme.

Generera minnesdumpar manuellt med hjälp av DebugDiag

Om du kan utlösa den långsamma begäran och veta hur länge du ska pausa innan du startar genereringen av minnesdumpar följer du dessa steg.

Om du inte kan utlösa begäran (till exempel att klienten är en mobilapp, du inte har åtkomst till den och problemet inte bara kan återskapas från webbläsaren), utan på något sätt vet när problemet uppstår följer du dessa steg för att bekräfta långsamhet:

  1. Följ de här stegen för att aktivera övervakaren för begäran:

    1. Öppna Serverhanteraren.
    2. Välj Hantera i det övre högra hörnet och välj Lägg till roller och funktioner>Nästa.
    3. Välj rollbaserad eller funktionsbaserad installation>Nästai fönstret Lägg till roller och funktioner.
    4. Välj den server som du vill konfigurera från serverpoolen.
    5. I avsnittet Välj serverroller expanderar du Web Server (IIS)>Web Server>Health and Diagnostics.
    6. Under Hälsa och diagnostikmarkerar du kryssrutan Förfrågningsövervakaren.
    7. Välj Nästa>Nästa>Installera för att aktivera funktionen Förfrågningsövervakare.

När installationen är klar kan du behöva starta om IIS. Du kan starta om den genom att öppna en kommandotolk och skriva iisreset.exe.

  1. Öppna IIS-hanteraren och välj servernamnet till vänster.
  2. Dubbelklicka på Arbetsprocesser.
  3. Dubbelklicka på programpoolen i fråga och välj kolumnen Time Förflutit.

Mer information finns i Använda RSCA för att hjälpa dig att förstå vad dina IIS-serverbegäranden gör.

Om långsamheten bekräftas tar du minnesdumparna manuellt. Detta garanterar dock inte att dumparna innehåller samma problematiska begäran under dess livslängd och därför kan flera försök behövas om dumpar görs manuellt (även när automatiserade, ibland flera försök behövs).

Följ dessa steg för att ta minnesdumparna manuellt:

  1. Ladda ned och installera felsökningsdiagnostikverktyget v2 Uppdatering 3.2.

  2. När en minnesläcka uppstår öppnar du DebugDiag 2-samlingen från Start-menyn :

    Skärmbild av samlingen DebugDiag 2.

    Anmärkning

    Om du behöver ändra sökvägen där dumpar genereras väljer du Verktygsalternativ>>Manuell användardump Spara mapp för att ändra den.

  3. Välj fliken Processer .

  4. Leta upp w3wp-processen med kolumnen Process-ID för programmet i fråga.

    Ersätt <PID> med den faktiska PID:en för den w3wp.exe process som har det höga minnesproblemet. Mer information om hur du hämtar PID finns i Identifiera hög minnesanvändning.

  5. Högerklicka på w3wp-processen , välj Skapa Userdump-serien och ange följande alternativ (justera talen efter behov). Välj inte Spara och stäng.

    Skärmbild av Konfigurera UserDump-serien.

  6. Återskapa långsamheten och välj Spara & Stäng när begärandena är långsamma.

    Om du inte vet hur du återskapar långsamheten och det sker snabbt och ofta väntar du på att långsamheten ska börja innan du väljer Spara & Stäng. Dumpar börjar samlas in så snart Spara & Stäng har valts.

Konfigurera FREB för att utlösa minnesdumpar med hjälp av ProcDump.exe

Det här avsnittet innehåller stegvisa instruktioner om hur du konfigurerar FREB (Failed Request Tracing Rules) för att utlösa minnesdumpar med hjälp av ProcDump.exe. Den här metoden är särskilt användbar när du inte kan installera vissa program som DebugDiag på servern.

Följ de här stegen för att konfigurera FREB att köra en anpassad åtgärd, till exempel ProcDump.exe, för att generera minnesdumpar när specifika regler uppfylls.

  1. Konfigurera FREB:er för lämpligt tidsvärde för begäran. Se till att ange en tidsbegripen regel i stället för en statuskod.

  2. Följ dessa steg för att aktivera anpassade åtgärder:

    1. Öppna IIS-hanteraren och välj servernamnet till vänster på skärmen.

    2. Dubbelklicka på ikonen Configuration Editor.

    3. Gå till avsnittet applicationHost/sites och välj sedan knappen ... (ellips).

      Skärmbild av konfigurationsredigeraren.

    4. Välj den webbplats som du redan har lagt till spårningsregeln misslyckades till.

      skärmbild av samlingsredigeraren.

    5. Ange customActionsEnabled till True.

    6. Ladda ned ProcDump och kopiera den körbara filen till sökvägen C:\procDump. Skapa en katalog med namnet myDumps under C:\-enheten.

      Varning

      Du måste placera ProcDump-verktyget i en mappsökväg som inte innehåller blanksteg. Annars är det omöjligt att köra ProcDump via FREB. Till exempel är C:\procDump en bra sökvägsmapp medan C:\Process Dump inte är det.

  3. Ange den anpassade åtgärden för ProcDump:

    1. Ange åtgärden på server- eller platsnivå och välj knappen ... enligt följande skärmbild:

      Skärmbild av konfigurationsredigeraren på servernivå.

    2. Välj länken Lägg till under fönstret Åtgärd och fyll i egenskaperna enligt följande skärmbild:

      Skärmbild av egenskaper i Samlingsredigeraren.

      • CustomActionExe: Ange värdet till sökvägen till den körbara ProcDump-filen.

      • customActionParams: Ange värdet till -accepteula -ma %1% C:\myDumps -n 3.

        Det här kommandot genererar tre på varandra följande dumpar med 10 sekunders mellanrum. Om du behöver ändra avståndet lägger du till -s följt av antalet sekunder.

Dataanalys

Det här avsnittet innehåller vägledning om hur du använder olika verktyg för att analysera data för att diagnostisera och felsöka långsamma sidsvar och låsningsproblem i IIS.

IIS-webbloggar (W3SVC-loggar)

När du analyserar W3SVC-loggar finns det ett par mål.

  • Kontrollera att begäranden körs långsamt. Granska de tidsbegränsade värdena för att bekräfta hur lång tid det tar att köra begäranden.
  • Identifiera vilka sidor som körs långsamt. Använd cs-uri-stem värden tillsammans med tidsåtgång för att identifiera långsamma sidor efter namn.

Den tid det tar loggas i millisekunder. 1 000 millisekunder = 1 sekund. När du letar efter begäranden som tar mer än 30 sekunder att slutföra letar du efter tidsåtgångsvärden som är större än 30 000 millisekunder.

Det finns två verktyg för att analysera W3SVC-loggar, Excel och Log Parser 2.2.

Analysera en enda W3SVC-logg med Excel

Följ dessa steg för att analysera en enda W3SVC-logg med Excel:

  1. Öppna W3SVC-loggar i Excel.
  2. Markera och ta bort de tre översta raderna (alla bör börja med ett # tecken). Se till att behålla raden som börjar med #Fields.
  3. Välj kolumnen A. I menyfliksområdet Data väljer du Text till Kolumner.
  4. I guiden Konvertera text till kolumnerväljer du Avgränsad>Nästa.
  5. I Avgränsaremarkerar du kryssrutan Blanksteg och avmarkerar alla andra kontroller och väljer sedan Slutför.
  6. Markera cellen A1, högerklicka på den och välj Ta bort från snabbmenyn.
  7. När du uppmanas till det väljer du Skift-celler som är kvar.
  8. Välj rad 1. I menyfliksområdet Data väljer du Filtrera.

Nu kan du använda filtren för tidsåtgång för att identifiera alla begäranden som är större än önskat antal sekunder.

Analysera flera W3SVC-loggar med log parser

Om du har flera loggar för att analysera eller en enda loggfil som är för stor för att kunna öppnas av Excel kan du överväga att använda Log Parser 2.2 (Microsoft Download Center). Det är ett kraftfullt verktyg som gör att du kan köra SQL-formaterade frågor för att extrahera data från olika typer av loggfiler, inklusive W3SVC-loggar.

Följ dessa steg om du vill använda Log Parser 2.2:

  1. Ladda ned och installera Log Parser 2.2 (Microsoft Download Center).

  2. Öppna kommandotolken och gå till installationskatalogen för Log Parser.

  3. Kör frågor i kommandotolken fönstret. Här är några frågeexempel:

    • De vanligaste begärda sidorna

      "C:\Program Files (x86)\Log Parser 2.2\logparser.exe" -i:W3C -o:CSV "SELECT TOP 100 cs-uri-stem as URL-Requested, COUNT(*) AS Num-Requests, MAX(time-taken) As Max-Time-Taken, MIN(time-taken) As Min-Time-Taken, Avg(time-taken) As Average-Time-Taken FROM *.log GROUP BY URL-Requested ORDER By Num-Requests DESC" -q:ON > Top100Pages.csv

    • Långsammaste sidor

      REM "C:\Program Files (x86)\Log Parser 2.2\logparser.exe" -i:W3C -o:CSV "SELECT TOP 25 cs-uri-stem as URL-Requested, COUNT(*) AS Num-Requests, MAX(time-taken) As Max-Time-Taken, MIN(time-taken) As Min-Time-Taken, Avg(time-taken) As Average-Time-Taken FROM *.log GROUP BY URL-Requested ORDER By Average-Time-Taken DESC" -q:ON > Slowest25Pages.csv

    • ALLA begäranden över 15 sekunder

      REM "C:\Program Files (x86)\Log Parser 2.2\logparser.exe" -i:W3C -o:W3C "SELECT * FROM *.log WHERE Time-Taken > 14999 ORDER BY Time-Taken DESC" -q:ON > LongRunningRequests.log

Fiddler-spårningar eller HAR-spårningar från Microsoft Edge eller Chrome

Fiddler Classic har ett par alternativ för att visa prestandainformation. När du har samlat in en spårning i Fiddler granskar du filen .saz i Fiddler. Det finns två relevanta flikar i Fiddler. Den första är fliken Statistik. Välj flera begäranden (eller ramar) i en spårning, och fliken Statistik innehåller viss prestandastatistik på en enkel sammanfattningssida.

Den andra Fiddler-fliken för felsökning av prestandaproblem är fliken tidslinje. Om du väljer fliken Tidslinje och flera begäranden (eller ramar) i en spårning visas ett stapeldiagram som visar hur lång tid det tar för klienten att ta emot svar för varje begäran.

F12 Developer Tools är inbyggda i både Microsoft Edge och Chrome. I fall där det inte går att installera Fiddler Classic kanske dessa verktyg redan är tillgängliga för kunden för felsökning. F12 Developer Tools liknar Fiddler eftersom de ger en vy på klientsidan av begäranden som görs. Har-filer för utvecklarverktyg visar en tidslinje överst i nätverksrapporten, vilket ger en visuell representation av den tid webbläsaren väntar på enskilda begäranden. HAR-filen visar också en TIME- kolumn som hjälper dig att identifiera långsamma begäranden.

FREB-loggar (Failed Request Trace)

FREB-spårningar är .xml filer och formateras av .xsl-formatmallen i FREB-loggkatalogen. Använd ett verktyg som FrebSbS för att visa dessa loggar. Mer information om hur du läser en FREB-logg finns i Läsa en FREB-logg, en spårning av misslyckade förfrågningar: IIS-begärandebearbetning av pipelinekörning.

Fullständiga minnesdumpar

Analysprogrammet DebugDiag 2 kan analysera dumpar för låser sig eller prestandaproblem.

Följ dessa steg för att analysera en enskild dump i en låsningssituation:

  1. Använd knappen Lägg till datafiler för att läsa in en dump i DebugDiag 2 Analysis.
  2. Välj CrashHangAnalysis.
  3. Välj Starta analys.
  4. När DebugDiag slutför sin analys öppnas en rapport i Microsoft Edge.

Följ dessa steg för att analysera en serie dumpar i ett prestandaproblem:

  1. Använd knappen Lägg till datafiler för att lägga till flera dumpar av samma process
  2. Välj PerfAnalysis.
  3. Välj Starta analys.
  4. När DebugDiag slutför sin analys öppnas en rapport i Microsoft Edge.

Det är enklare och mer förståeligt att bara köra en typ av analysregel i taget.

Anmärkning

Om du behöver en mer detaljerad analys kan du använda WinDbg för att granska dumpar.

Ansvarsfriskrivning för information från tredje part

Produkter från tredje part som beskrivs i den här artikeln tillverkas av företag som är oberoende av Microsoft. Microsoft ger ingen garanti, underförstådd eller på annat sätt, om dessa produkters prestanda eller tillförlitlighet.