En av de enkleste måtene å gjøre produksjonen litt mer forståelig er å forstå tidsstempler. Nesten hver analysator viser pakke ganger på tre måter samtidig: " Absolute tid ", " relativ tid " og " deltatid ". Til pålydende, disse feltene er ganske enkelt, men det tar litt mer tenkte å få nyttig informasjon fra dem:
Absolutt tid er den tiden av dagen pakken ble sett av analysatoren. Selv om dette kan høres nyttig, er det sjelden slik. Du kan bruke denne hvis du feilsøker og ønsket å se etter pakker som sendes samtidig som noen hendelse i en annen logg, som Windows Event Viewer på en server. Problemet er, med hundretusener av pakker per sekund zoome rundt, hvis analysator er noen sekunder (eller sannsynlig minutter) av det er vanskelig å si med sikkerhet at en bestemt pakke var involvert i problemet. Dette kan også drive deg gal hvis flere tidssoner er involvert. NTP er din venn.
Relativ tid er tiden siden begynnelsen av fangst. Det er, virker det som om absolutt tid, men den første pakken i filen vil vanligvis være på 0 sekunder. Relativ tid er nyttig for å analysere programytelse på en jobb eller oppgave nivå. For eksempel kan du trekke den relative tiden av den første pakken i en database overføring fra den relative tidspunktet for den siste pakken og fortelle hvor lang tid overføringen tok.
Delta er tiden siden forrige rammen. dvs. hvis ramme 100 har en Delta på 35 ms, så var det 35 ms med stillhet mellom rammer 99 og 100. Denne informasjonen er svært nyttig for å identifisere nettverksproblemer knyttet til ventetid, men det er et triks. Med potensielt tusenvis av samtaler som skjer, hva du virkelig ønsker å vite er deltaet tiden fra den siste pakken i samme økt, men oddsen er sterke at den siste pakken analysatoren så var fra en annen samtale. Så, for å bruke denne informasjonen, må du filtrere etter samtalen.
Så, når du får dine filtre satt til en enkelt samtale, skanne ned Delta tidsfeltet og få en følelse for hvor lang tid det tar klienten og serveren for å svare på hverandre. En veldig typisk mønster er for alternerende lange og korte delta ganger. Det vil si, har en pakke en forholdsvis kort tid, og den neste pakke har en forholdsvis lang tid, så det neste har en forholdsvis kort tid, etc. Det viktige man kan lære av dette feltet, og mønsteret er hvorvidt den serveren venter på nettverk, eller nettverket venter på serveren.
Tom Lancaster, CCIE # 8829 CNX # 1105, er en konsulent med 15 års erfaring i nettverk bransjen, og co -author av flere bøker om nettverk, senest, etter CCSP TM. Secure PIX og sikker VPN Study guide utgitt av Sybex