Alta DPC-latento ne signifas malrapidan VPN-vojon
Pelilaj tempoj, eĥaj rondiroj kaj sesiaj eventoj kulpigas unu la alian. Legu, kion ĉiu nombrilo mezuras, antaŭ ol ŝanĝi komponanton.
Sona fuŝo kaj VPN-paŭzo okazas en la samaj dek sekundoj, kaj helpilo raportas altan nombron kun la etikedo DPC-latento. La tento estas konkludi, ke la pelilo malrapidigas la tunelon, aŭ ke la tunelo ŝarĝas la pelilon. Neniu el la du konkludoj sekvas el tiu nombro.
Tri mezuroj ĉeestas ĉi tie, kaj ili ne dividas saman limon.
Tri nombroj, tri limoj
Prokrastita procedura voko estas laboro, kiun pelilo prokrastas el sia interrompa traktilo, kaj la tempo pasigita ene de tiuj rutinoj estas procesor-loka mezuro atribuita al moduloj kaj funkcioj. Eĥa rondiro estas tempobservo ĉe la ingo, produktita de reta stako kaj fora respondanto. Malkonekta evento estas stata transiro registrita de la kliento. Ĉiu respondas demandon, kiun la aliaj ne povas, kaj samaj unuoj ne igas ilin interŝanĝeblaj.
La utila disciplino estas nomi la limon antaŭ legi la valoron. Skribu la unuon kaj la limon unu apud la alia. Se ilo raportas milisekundojn, demandu milisekundojn de kio: tempo ene de rutino, tempo atendanta ruliĝon, aŭ tempo ĝis alveno de respondo.
Alta nombro en unu kategorio estas spuro, neniam diagnozo.
Legu la difinon malantaŭ la titolo
Helpiloj malsamas pri tio, kion ili nomas latento. Iuj raportas la daŭron de pelilaj rutinoj, aliaj raportas planan prokraston, kaj la du kvantoj povas moviĝi en kontraŭaj direktoj sur la sama maŝino. Panelo, kiu nomas unu el ili simple DPC-latento, diris al vi malpli ol ĝi ŝajnas. Du paneloj do povas malkonsenti pri maŝino, kiu tute ne ŝanĝiĝis.
La sama singardo validas ene de unu analiza ilo. Inkluziva daŭro sekvas rutinon de eniro ĝis eliro, dum ekskluziva daŭro sumas nur la fragmentojn, en kiuj la rutino mem plenumis. Elekti la malĝustan kolumnon igas vokanton kulpulo.
Loka pelila laboro kaj reta prokrasto ankaŭ interagas sen kunfandiĝi. Troa interromp-rilata agado povas prokrasti temp-senteman laboron sur la maŝino, kaj kongestita vojo povas prokrasti pakojn, kaj ambaŭ povas esti veraj dum unu videbla paŭzo.
Metu ĉiun observon en unu fenestron
Spuro nur utilas, se vi legas la intervalon, kiu enhavas la simptomon. Registru la spuron, la eventon de la kliento kaj la fiaskon de la aplikaĵo kun tempaj markoj, poste rigardu la samajn sekundojn en ĉiuj tri. Maksimumo el unuhora spuro kaj malkonekto poste tiun posttagmezon estas du nerilataj faktoj.
wpr -start CPU -filemode
wpr -stop vpn-trace.etl
xperf -i vpn-trace.etl -a dpcisr -o dpc.txt
Poste malfermu la spuron en la analiza ilo kaj ordigu laŭ daŭro ene de tiu fenestro, anstataŭ laŭ la tuta registro. La gvidilo pri CPU-analizo priskribas la DPC/ISR-daŭran vidon, kiu atribuas tempon al moduloj kaj funkcioj.
Konfirmu, kio fakte okazis al la tunelo dum vi estas tie. Perdi aplikaĵan trafikon mallonge ne signifas, ke la kliento komencis novan intertraktadon, kaj sukcesa malgranda provo ne pruvas, ke ĉio alia daŭre funkciis.
Ŝanĝu la komponanton, kiun la pruvoj nomas
Okupata modulo estas loko por esplori, ne verdikto. Ĝi eble faras laboron kaŭzitan de alia komponanto aŭ de la ŝarĝo, kiun vi generis. Tenu kune la modulnomo, la aparato, la pelila versio kaj la observita intervalo, ĉar tiu aro estas tio, pri kio provizanto povas agi.
Unu ŝanĝo por eksperimento estas la sola maniero lerni el la rezulto. Kabla komparo mallarĝigas la amplekson, sed ĝi samtempe ŝanĝas la radio-vojon kaj la pelilan agadon, do traktu ĝin kiel spuron, ne kiel pruvon.
Traktu la spuron kiel senteman. Ĝi povas enhavi procesajn nomojn kaj detalojn pri la medio, do ĝi apartenas al la subtenata registra kanalo, ne al publika aldonaĵo. Diru, kiun observon la spuro devis respondi.