Hög DPC-latens betyder inte en långsam VPN-väg

En ljudstörning och en VPN-paus infaller inom samma tio sekunder, och ett verktyg rapporterar ett högt värde märkt DPC-latens. Frestelsen är att dra slutsatsen att drivrutinen saktar ner tunneln, eller att tunneln belastar drivrutinen. Ingen av slutsatserna följer av den siffran.

Tre mätningar är i spel här, och de delar inte samma gräns.

Tre tal, tre gränser

Ett uppskjutet proceduranrop är arbete som en drivrutin skjuter upp från sin interrupthanterare, och tiden som tillbringas i dessa rutiner är en processorlokal mätning som tillskrivs moduler och funktioner. En ekorundtur är en tidsobservation vid socketen, producerad av en nätverksstack och en fjärrsvarare. En frånkopplingshändelse är en tillståndsövergång som klienten registrerar. Var och en svarar på en fråga som de andra inte kan, och lika enheter gör dem inte utbytbara.

Den användbara disciplinen är att namnge gränsen innan du läser värdet. Skriv enheten och gränsen bredvid varandra. Om ett verktyg rapporterar millisekunder, fråga millisekunder av vad: tid inne i en rutin, tid som väntar på att köras, eller tid tills ett svar anlände.

En hög siffra i en kategori är ett spår, aldrig en diagnos.

Läs definitionen bakom rubriken

Verktygen skiljer sig i vad de kallar latens. Vissa rapporterar varaktigheten av drivrutinsrutiner, andra rapporterar schemaläggningsfördröjning, och de två storheterna kan röra sig i motsatta riktningar på samma maskin. En instrumentpanel som kallar en av dem helt enkelt DPC-latens har berättat mindre än det verkar. Därför kan två instrumentpaneler vara oeniga om en maskin som inte har förändrats alls.

Samma försiktighet gäller inom ett enda analysverktyg. Inklusiv varaktighet följer en rutin från ingång till utgång, medan exklusiv varaktighet bara summerar de fragment där rutinen själv körde. Att välja fel kolumn gör en anropare till en skyldig.

Lokalt drivrutinsarbete och nätverksfördröjning samverkar också utan att smälta samman. Överdriven interruptrelaterad aktivitet kan fördröja tidskänsligt arbete på maskinen, och en överbelastad väg kan fördröja paket, och båda kan vara sanna under en synlig paus.

Sätt varje observation i ett fönster

En spårning är bara användbar om du läser intervallet som innehåller symptomet. Registrera spårningen, klientens händelse och programmets fel med tidsstämplar, och titta sedan på samma sekunder i alla tre. Ett maximum från en timmes spårning och en frånkoppling senare samma eftermiddag är två orelaterade fakta.

wpr -start CPU -filemode
wpr -stop vpn-trace.etl
xperf -i vpn-trace.etl -a dpcisr -o dpc.txt

Öppna sedan spårningen i analysverktyget och sortera efter varaktighet inom det fönstret, i stället för efter hela inspelningen. vägledningen för CPU-analys beskriver DPC/ISR-varaktighetsvyn som tillskriver tid till moduler och funktioner.

Bekräfta vad som faktiskt hände med tunneln medan du är där. Att förlora applikationstrafik kortvarigt betyder inte att klienten startade en ny förhandling, och en lyckad liten test bevisar inte att allt annat fortsatte att fungera.

Byt komponenten som bevisen pekar ut

En upptagen modul är en plats att undersöka, inte en dom. Den utför kanske arbete som orsakas av en annan komponent eller av den belastning du genererade. Håll modulnamn, enhet, drivrutinsversion och det observerade intervallet tillsammans, för det är den uppsättningen en leverantör kan agera på.

En ändring per experiment är det enda sättet att lära av resultatet. En trådbunden jämförelse minskar omfattningen, men den ändrar radiovägen och drivrutinsaktiviteten samtidigt, så behandla den som ett spår och inte som bevis.

Behandla spårningen som känslig. Den kan innehålla processnamn och miljöuppgifter, så den hör hemma i den stödda inspelningskanalen och inte i en offentlig bilaga. Säg vilken observation spårningen skulle besvara.