Høy DPC-latens betyr ikke en treg VPN-vei
Drivertid, ekkorundturer og sesjonshendelser får skylden for hverandre. Les hva hver teller måler før du bytter en komponent.
En lydfeil og en VPN-pause faller innenfor de samme ti sekundene, og et verktøy rapporterer et høyt tall merket DPC-latens. Fristelsen er å konkludere med at driveren bremser tunnelen, eller at tunnelen belaster driveren. Ingen av de to konklusjonene følger av tallet.
Tre målinger er i spill her, og de deler ikke samme grense.
Tre tall, tre grenser
Et utsatt prosedyrekall er arbeid en driver utsetter fra interrupt-handleren sin, og tiden som brukes inne i disse rutinene er en prosessorlokal måling tilskrevet moduler og funksjoner. En ekkorundtur er en tidsmåling ved socketen, produsert av en nettverksstakk og en ekstern svarer. En frakoblingshendelse er en tilstandsovergang klienten registrerer. Hver av dem svarer på et spørsmål de andre ikke kan, og like enheter gjør dem ikke utskiftbare.
Den nyttige disiplinen er å navngi grensen før du leser verdien. Skriv enheten og grensen ved siden av hverandre. Hvis et verktøy rapporterer millisekunder, spør millisekunder av hva: tid inne i en rutine, tid med å vente på å kjøre, eller tid til et svar ankom.
Et høyt tall i én kategori er et spor, aldri en diagnose.
Les definisjonen bak overskriften
Verktøyene er ulike i hva de kaller latens. Noen rapporterer varigheten av driverrutiner, andre rapporterer planleggingsforsinkelse, og de to størrelsene kan bevege seg i motsatte retninger på samme maskin. Et dashbord som kaller en av dem rett og slett DPC-latens, har fortalt deg mindre enn det ser ut til. Derfor kan to dashbord være uenige om en maskin som ikke har endret seg i det hele tatt.
Samme forsiktighet gjelder inne i ett enkelt analyseverktøy. Inklusiv varighet følger en rutine fra inngang til utgang, mens eksklusiv varighet bare summerer fragmentene der rutinen selv kjørte. Å velge feil kolonne gjør en kaller til en synder.
Lokalt driverarbeid og nettverksforsinkelse samvirker også uten å smelte sammen. Overdreven interruptrelatert aktivitet kan forsinke tidsfølsomt arbeid på maskinen, og en overbelastet vei kan forsinke pakker, og begge kan være sanne under én synlig pause.
Sett hver observasjon i ett vindu
En sporing er bare nyttig hvis du leser intervallet som inneholder symptomet. Ta opp sporingen, klientens hendelse og applikasjonens feil med tidsstempler, og se deretter på de samme sekundene i alle tre. Et maksimum fra en times sporing og en frakobling senere samme ettermiddag er to urelaterte fakta.
wpr -start CPU -filemode
wpr -stop vpn-trace.etl
xperf -i vpn-trace.etl -a dpcisr -o dpc.txt
Åpne deretter sporingen i analyseverktøyet og sorter etter varighet innenfor det vinduet, i stedet for etter hele opptaket. veiledningen for CPU-analyse beskriver DPC/ISR-varighetsvisningen som tilskriver tid til moduler og funksjoner.
Bekreft hva som faktisk skjedde med tunnelen, mens du er der. Å miste applikasjonstrafikk kortvarig betyr ikke at klienten startet en ny forhandling, og en vellykket liten test beviser ikke at alt annet fortsatte å virke.
Bytt komponenten som bevisene peker på
En travel modul er et sted å undersøke, ikke en dom. Den utfører kanskje arbeid forårsaket av en annen komponent, eller av arbeidsmengden du genererte. Hold modulnavn, enhet, driverversjon og det observerte intervallet sammen, for det er dette settet en leverandør kan handle på.
Én endring per eksperiment er den eneste måten å lære av resultatet. En kablet sammenligning snevrer inn omfanget, men den endrer radiostien og driveraktiviteten samtidig, så behandle den som et spor, ikke som bevis.
Behandle sporingen som sensitiv. Den kan inneholde prosessnavn og miljødetaljer, så den hører hjemme i den støttede opptakskanalen og ikke i et offentlig vedlegg. Si hvilken observasjon sporingen skulle besvare.