Høj DPC-latens betyder ikke en langsom VPN-rute

En lydfejl og en VPN-pause falder inden for de samme ti sekunder, og et værktøj rapporterer et højt tal mærket DPC-latens. Fristelsen er at konkludere, at driveren bremser tunnelen, eller at tunnelen belaster driveren. Ingen af de to konklusioner følger af det tal.

Tre målinger er i spil her, og de deler ikke samme grænse.

Tre tal, tre grænser

Et udskudt procedurekald er arbejde, som en driver udskyder fra sin interrupt-handler, og den tid, der bruges inde i disse rutiner, er en processorlokal måling, som tilskrives moduler og funktioner. En ekkorundtur er en tidsmåling ved socketen, produceret af en netværksstak og en fjern svarer. En afbrydelseshændelse er en tilstandsovergang, som klienten registrerer. Hver især besvarer de et spørgsmål, som de andre ikke kan, og ens enheder gør dem ikke udskiftelige.

Den nyttige disciplin er at navngive grænsen, før du læser værdien. Skriv enheden og grænsen ved siden af hinanden. Hvis et værktøj rapporterer millisekunder, så spørg millisekunder af hvad: tid inde i en rutine, tid med at vente på at køre, eller tid indtil et svar ankom.

Et højt tal i én kategori er et spor, aldrig en diagnose.

Læs definitionen bag overskriften

Værktøjer er forskellige i det, de kalder latens. Nogle rapporterer varigheden af driverrutiner, andre rapporterer planlægningsforsinkelse, og de to størrelser kan bevæge sig i modsatte retninger på samme maskine. Et dashboard, der kalder en af dem blot DPC-latens, har fortalt dig mindre, end det ser ud til. Derfor kan to dashboards være uenige om en maskine, der slet ikke har ændret sig.

Samme forsigtighed gælder inde i et enkelt analyseværktøj. Inklusiv varighed følger en rutine fra indgang til udgang, mens eksklusiv varighed kun summerer de fragmenter, hvor rutinen selv blev udført. At vælge den forkerte kolonne gør en kalder til en synder.

Lokalt driverarbejde og netværksforsinkelse vekselvirker også uden at smelte sammen. Overdreven interruptrelateret aktivitet kan forsinke tidsfølsomt arbejde på maskinen, og en overbelastet rute kan forsinke pakker, og begge kan være sande under én synlig pause.

Sæt hver observation i ét vindue

En sporing er kun nyttig, hvis du læser det interval, der indeholder symptomet. Optag sporingen, klientens hændelse og applikationens fejl med tidsstempler, og se derefter på de samme sekunder i alle tre. Et maksimum fra en times sporing og en afbrydelse senere på eftermiddagen er to uafhængige fakta.

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

Åbn derefter sporingen i analyseværktøjet, og sortér efter varighed inden for det vindue i stedet for efter hele optagelsen. vejledningen i CPU-analyse beskriver DPC/ISR-varighedsvisningen, som tilskriver tid til moduler og funktioner.

Bekræft, hvad der faktisk skete med tunnelen, mens du er der. At miste applikationstrafik kortvarigt betyder ikke, at klienten startede en ny forhandling, og en vellykket lille test beviser ikke, at alt andet blev ved med at virke.

Skift den komponent, som evidensen peger på

Et travlt modul er et sted at undersøge, ikke en dom. Det udfører måske arbejde forårsaget af en anden komponent eller af den arbejdsbyrde, du skabte. Hold modulnavn, enhed, driverversion og det observerede interval sammen, for det sæt er det, en leverandør kan handle på.

Én ændring pr. eksperiment er den eneste måde at lære af resultatet. En kablet sammenligning indsnævrer omfanget, men den ændrer radiostien og driveraktiviteten samtidig, så behandl den som et spor, ikke som bevis.

Behandl sporingen som følsom. Den kan indeholde procesnavne og miljøoplysninger, så den hører til i den understøttede optagelseskanal og ikke i en offentlig vedhæftning. Sig, hvilken observation sporingen skulle besvare.