Kā izmērīt tīkla latentumu: izstrādātāja praktiskais ceļvedis

Vēlaties izmērīt tīkla latentumu? Jūs varat sākt ar vienkāršiem, iebūvētiem komandrindas rīkiem, piemēram, ping un traceroute, lai ātri iegūtu informāciju par Round-Trip Time (RTT). Vai arī varat atvērt pārlūkprogrammas izstrādātāja rīkus, lai redzētu, kā aizkavējumi ietekmē to, ko jūsu lietotāji patiesībā piedzīvo.

Šīs metodes sniedz ātru, noderīgu pārskatu par to, cik ilgs laiks nepieciešams datu paketei, lai ceļotu no avota, sasniegtu galamērķi un atgrieztos atpakaļ.

Kāpēc latentuma mērīšana ir nenoliedzama

Pirms mēs pārejam pie "kā", runāsim par "kāpēc". Izstrādātājiem un tīkla inženieriem latentums nav tikai skaitlis uz ekrāna; tas ir neredzamā roka, kas veido visu lietotāja pieredzi. Mūsdienu lietojumprogrammās milisekundes ir viss. Pat neliela aizkavēšanās var būt atšķirība starp pakalpojumu, kas šķiet tūlītējs, un tādu, kas šķiet salauzts.

Pārdomājiet reālās sekas:

• API reaģētspēja: Viens lēns API izsaukums var radīt domino efektu, kavējot visu, sākot no lietotāja profila ielādes līdz kritiskas maksājuma apstrādes.
• Reāllaika datu plūsmas: Tiešsaistes spēlēm, tiešraides videoklipiem vai finanšu tirdzniecībai zems un konsekvents latentums ir absolūta pamats. Bez tā šīs lietojumprogrammas vienkārši nedarbojas.
• Lietotāju noturība: Ir tieša saikne starp lēni ielādējošām vietnēm un lietotnēm un augstākiem atteikšanās rādītājiem un pamestiem iepirkumu groziem. Šīs lietas ietekmē peļņu, smagi.

Galveno latentuma jēdzienu atšķiršana

Lai precīzi izmērītu tīkla latentumu, jums jāzina, ko skatāties. Divi vissvarīgākie jēdzieni ir Round-Trip Time (RTT) un vienvirziena latentums.

RTT ir kopējais laiks, kas nepieciešams signālam, lai dotos no punkta A uz punktu B un atpakaļ. Tas ir visizplatītākais metriks, ko jūs redzēsiet, jo to ir viegli izmērīt—jums nepieciešama piekļuve tikai vienai savienojuma pusei.

Vienvirziena latentums, kā norāda nosaukums, mēra laiku, kas nepieciešams datiem, lai ceļotu tikai vienā virzienā. Šis ir daudz sarežģītāks mērījums, jo tas prasa pilnīgi sinhronizētas pulksteņus abos galapunktos. Tomēr tas ir daudz precīzāks rādītājs asimetriskām savienojumiem, kur jūsu augšupielādes un lejupielādes ceļi uzvedas ļoti atšķirīgi.

Visas šīs svarīgums kļūst skaidrs, kad jūs veicat nopietnu slodzes veiktspējas testēšanu, kur teorija saskaras ar realitāti un šaurās vietas tiek atklātas.

Lai sniegtu dažus skaitļus, tīkla uzraudzības eksperti parasti klasificē latentumu šādi:

• Zems latentums: Zem 50 milisekundēm
• Vidējs latentums: 50-150 ms
• Augsts latentums: Virs 150 ms

No manas pieredzes ātrs tests uz tuvāko serveri var parādīt pilnīgi pieņemamu 20-40 ms. Bet šis skaitlis var viegli pieaugt līdz vairāk nekā 200 ms satiksmei, kas jāšķērso okeānam, kas var būt izšķirošs jūsu lietojumprogrammas veiktspējai.

Lai saprastu žargonu, ar ko jūs sastapsieties, šeit ir ātrs atsauce.

Galveno latentuma jēdzienu pārskats

Jēdziens	Ko tas mēra	Kāpēc tas ir svarīgi
Latentums (Ping)	Laiks, kas nepieciešams, lai viena datu pakete ceļotu no avota uz galamērķi un atpakaļ. Mērīts milisekundēs (ms).	Tas ir izejas mērījums aizkavēšanās. Zems latentums ir būtisks reāllaika lietojumprogrammām, piemēram, spēlēm, VoIP un video konferencēm.
Round-Trip Time (RTT)	Essenciāli tas pats, kas latentums, tas ir kopējais laiks, lai signāls tiktu nosūtīts plus laiks, lai saņemtu apstiprinājumu.	RTT ir visizplatītākais un praktiskais veids, kā izmērīt latentumu no viena punkta, padarot to par galveno metriku tādiem rīkiem kā ping.
Vienvirziena latentums	Laiks, kas nepieciešams, lai pakete ceļotu no avota uz galamērķi vienā virzienā.	Sniedz detalizētāku skatījumu, īpaši asimetriskos tīklos, kur augšupielādes un lejupielādes ceļiem ir atšķirīgs latentums.
Jitter	Latentuma variācija laika gaitā. Tas mēra paketes ierašanās laiku nesakritību.	Augsts jitter ir tikpat slikts kā augsts latentums straumējošiem medijiem un tiešsaistes zvaniem, izraisot raustīšanos, buferēšanu un kļūdas.
Joslas platums	Maksimālais datu daudzums, ko var pārsūtīt pa tīkla savienojumu noteiktā laika posmā. Mērīts Mbps vai Gbps.	Bieži sajaukts ar ātrumu, joslas platums attiecas uz kapacitāti. Jums var būt augsts joslas platums, bet joprojām ciest no augsta latentuma.

Šie jēdzieni ir pamatelementi, lai saprastu jebkuru tīkla veiktspējas problēmu.

Šeit ir svarīgi, lai būtu pieejami, integrēti rīki. Tā vietā, lai veiktu sarežģītas diagnostikas programmas, mūsdienu pārlūkprogrammu paplašinājumi un izstrādes rīki var sniegt jums nepieciešamās atziņas, nekad neatstājot savu darba plūsmu. Tas ir par to, lai latentuma mērīšana kļūtu par vieglu, rutīnas daļu no lieliskas programmatūras izstrādes un uzturēšanas.

Rokas darbs ar komandrindas latentuma rīkiem

Lai patiešām sajustu sava tīkla veiktspēju, jums jāatver termināls. Komandrinda ir vieta, kur atradīsiet pamata rīkus, kas sniedz jums neapstrādātus, filtrētus datus par jūsu savienojumu. Tas ir par to, lai redzētu, kas patiesībā notiek ar paketēm, kas pārvietojas starp jums un galamērķi, un tas ir būtisks pirmais solis ikvienam izstrādātājam, kurš nopietni vēlas izmērīt latentumu.

Klasiskais, galvenais rīks ir ping. Tas ir skaisti vienkārši: tas nosūta mazu datu paketi (ICMP echo pieprasījumu) uz serveri un vienkārši gaida, lai tā atgrieztos. Šis vienkāršais ceļojums ir pamats Round-Trip Time (RTT) aprēķināšanai un sniedz jums tūlītēju veselības pārbaudi par savienojumu.

Jūsu pirmais latentuma pārbaude ar Ping

Veikt ping testu nevarētu būt vieglāk. Atveriet savu termināli vai komandu uzvedni, ierakstiet ping un sekojiet tam ar domēnu, ko vēlaties pārbaudīt.

Pa noklusējumu ping turpinās darboties mūžīgi macOS un Linux, kamēr Windows nosūta tikai četras paketes un apstājas. Jebkurai reālai analīzei jums būs jākontrolē tas. Nosūtot desmit vai divdesmit paketes, jūs iegūsiet daudz uzticamāku attēlu par savienojuma stabilitāti nekā tikai dažas.

Kad tas būs pabeigts, jūs saņemsiet sakārtotu kopsavilkumu ar svarīgajiem skaitļiem:

• Nosūtītās/saņemtās paketes: Tas jums pasaka, vai ceļā tika zaudēti kādi dati. Pat neliels paketes zudums ir liels sarkans karogs tīkla problēmām.
• Round-trip min/avg/max/mdev: Šie ir jūsu galvenie latentuma statistikas dati. Jūs iegūstat labāko gadījumu laiku (min), vidējo (avg) un sliktāko gadījumu (max). mdev (vidējā novirze) ir jūsu jitter mērījums—cik daudz latentums svārstās no vienas paketes uz nākamo.

Pievērsiet uzmanību atstarpei starp jūsu minimālo un maksimālo RTT. Ja tā ir plaša, jūsu savienojums ir nestabils, pat ja vidējais izskatās labi. Šis jitter var būt daudz traucējošāks reāllaika lietojumprogrammām, piemēram, video zvaniem vai spēlēm, nekā savienojums, kas konsekventi ir nedaudz lēns.

Izplatīta kļūda ir vienkārši paskatīties uz vidējo RTT. Vidējais 50ms var šķist labi, bet, ja jūsu minimālais ir 20ms un maksimālais ir 250ms, lietotāja pieredze jutīsies raustīga un neuzticama. Vienmēr skatieties uz visu diapazonu, lai saprastu jitter.

Sekojot pēdai ar Traceroute un MTR

Tātad, ko darīt, kad ping atklāj augstu latentumu vai paketes zudumu? Jūsu nākamais uzdevums ir noskaidrot kur ir problēma. Tam ir paredzēts traceroute (vai tracert Windows). Tas kartē visu ceļu, pa kuru jūsu paketes ceļo, parādot katru "lēcienu"—katru maršrutētāju—starp jūsu mašīnu un galamērķi.

Katrs rindiņš traceroute izvadē ir lēciens, un tas parasti rāda trīs atsevišķus latentuma mērījumus līdz šim punktam. Tas ļauj jums precīzi noteikt, vai konkrēts maršrutētājs pa ceļu izraisa lielu palēninājumu vai zaudē paketes.

Bet traceroute ir vienreizējs pārskats. Lai iegūtu dinamiskāku, nepārtrauktu skatījumu, lielākā daļa tīkla profesionāļu, ko es pazīstu, zvēr pie MTR (My Traceroute). MTR ir kā superuzlādēts rīks, kas apvieno ping un traceroute. Tas pastāvīgi nosūta paketes uz katru lēcienu maršrutā, sniedzot jums tiešu, atjauninātu skatījumu par latentumu un paketes zudumu katrā punktā. Tas padara to neticami efektīvu, lai atklātu pārtraukumus, kurus vienkāršs traceroute visticamāk palaidīs garām.

Kāpēc jūsu izvēlētā rīka nozīme

Rīks, ko izvēlaties, un tas, kā jūs to konfigurējat, var radikāli mainīt jūsu rezultātus. Tas ir īpaši patiesi ultra ātrās, zema latentuma vidēs, piemēram, mākoņu datu centros.

Patiesībā ir diezgan atklājoši, cik atšķirīgi var būt skaitļi. Detalizētā eksperimentā, ko veica Google Cloud, standarta ping tests ziņoja par vidējo RTT 146 mikrosekundes. Bet, kad viņi izmantoja citu rīku, kas nosūta darījumus viens pēc otra bez pauzes, RTT samazinājās līdz tikai 66.59 mikrosekundes—vairāk nekā divreiz ātrāk!

Šis ir lielisks piemērs, kāpēc ping dažreiz var pārvērtēt latentumu. Tas parāda, ka izpratne par to, kā rīks darbojas, ir kritiska, lai iegūtu mērījumus, kuriem varat uzticēties.

Jūsu savienojuma maksimālā ātruma noteikšana ar iperf

Latentums ne vienmēr ir viss. Dažreiz jums jāzina maksimālais datu daudzums, ko jūsu savienojums patiesībā var pārsūtīt—tā joslas platums. Šim uzdevumam jums nepieciešams rīks iperf.

Kamēr ping mēra aizkavēšanos, iperf ir par caurlaidspēju. Tas darbojas, izveidojot klienta-servera savienojumu un pēc tam nosūtot pēc iespējas vairāk datu starp tiem noteiktā laika posmā.

Lai izmantotu iperf, jums būs nepieciešamas divas mašīnas:

1. Uz vienas mašīnas jūs palaidīsiet iperf servera režīmā. Tas vienkārši sēdēs un gaidīs savienojumu.
2. Uz otras mašīnas jūs palaidīsiet iperf klienta režīmā, norādot to uz servera adresi.

Klients izveidos savienojumu, un tests sāksies. Izvade jums sniedz kopējo pārsūtīto datu daudzumu un, kas ir vissvarīgāk, bitu ātrumu (jūsu joslas platumu) megabitos vai gigabitos sekundē. Tas ir ideāls veids, kā veikt slodzes testu tīkla savienojumam un noskaidrot, ko tas patiesībā spēj.

Latentuma mērīšana no lietotāja perspektīvas

Kamēr komandrindas rīki sniedz jums neapstrādātu, filtrētu skatījumu uz jūsu tīklu, vienīgais latentums, kas patiešām ir svarīgs tīmekļa lietojumprogrammai, ir tas, ko beigu lietotājs patiesībā piedzīvo. Šeit mēs pārejam no termināļa uz pašu pārlūkprogrammu. Tas, kas notiek pārlūkprogrammā, stāsta daudz bagātāku, attiecīgāku stāstu par veiktspēju.

Tas nekad nav tikai par vienas paketes ceļojumu. Latentums, ko lietotājs jūt, ir sarežģīts kokteilis no DNS meklējumiem, TCP roku spiedieniem, TLS sarunām, servera apstrādes laika un, protams, laika, kas nepieciešams, lai faktiski attēlotu saturu ekrānā. Par laimi, mūsdienu pārlūkprogrammas ir aprīkotas ar jaudīgiem iebūvētiem rīkiem, lai palīdzētu mums izpētīt šo visu procesu.

Iegremdēšanās pārlūkprogrammas izstrādātāja rīkos

Katrs galvenais pārlūks—Chrome, Firefox, Edge, Safari—ir aprīkots ar izstrādātāja rīku komplektu. "Tīkla" cilne šajos rīkos ir jūsu komandu centrs, lai saprastu, kā jūsu vietne ielādējas. Tā izklāsta visu ūdens krituma diagrammā, kas ir vizuāls katra pieprasījuma, ko pārlūkprogramma veic, lai attēlotu lapu, sadalījums.

Šis ūdens krituma skats ir nenovērtējams. Jūs varat precīzi redzēt, cik ilgs laiks katram aktīvu elementam bija nepieciešams, lai lejupielādētu, sākot no sākotnējā HTML dokumenta un CSS stiliem līdz attēliem un API izsaukumiem. Vēl svarīgāk, tas sadala katra pieprasījuma dzīves ciklu atsevišķās fāzēs:

• DNS meklējums: Laiks, kas nepieciešams, lai atrisinātu domēna nosaukumu uz IP adresi.
• Sākotnējais savienojums: Laiks, kas pavadīts, izveidojot TCP savienojumu ar serveri.
• SSL/TLS roku spiediens: Papildu laiks, kas nepieciešams, lai izveidotu drošu savienojumu.
• Laiks līdz pirmajam baitam (TTFB): Tas ir milzīgs. Tas mēra, cik ilgi pārlūkprogramma gaidīja, pirms saņēma pirmo bait datu no servera.
• Satura lejupielāde: Laiks, kas pavadīts, faktiski lejupielādējot pašu resursu.

Augsts TTFB, piemēram, ir klasiskā pazīme par lēnu aizmugurējo vai servera apstrādes problēmu—kaut kas, ko vienkāršs ping tests nekad neatklātu. Analizējot šo ūdens kritumu, jūs varat ātri pamanīt, kuri resursi bloķē attēlošanu vai vienkārši aizņem pārāk ilgu laiku, lai ielādētos.

Galvenā atziņa no manas pieredzes ir ne tikai skatīties uz kopējo ielādes laiku, bet arī meklēt garākās joslas ūdens kritumā. Viena neoptimizēta attēla vai lēna trešās puses API var turēt visu lapu gūstā, radot sliktu lietotāja pieredzi, pat ja pārējā vietne ir zibens ātra.

Programmatiska mērīšana ar Timing API

Lai iegūtu automatizētākus un precīzākus mērījumus, jūs varat izmantot pārlūkprogrammas iebūvētos JavaScript API. Navigation Timing API un Resource Timing API sniedz jums programmātisku piekļuvi tiem pašiem detalizētajiem veiktspējas datiem, kurus redzat izstrādātāja rīkos. Tas ir ideāli piemērots, lai vāktu reālo lietotāju uzraudzības (RUM) datus, lai saprastu, kā jūsu vietne darbojas reāliem apmeklētājiem visā pasaulē.

Jūs varat iegūt šos metriku ar tikai dažām JavaScript rindām, tieši pārlūkprogrammas konsolē. Lai iegūtu galvenos veiktspējas mērījumus galvenās lapas ielādei, piemēram, jūs varat izmantot performance.getEntriesByType('navigation'). Tas atgriež objektu, kas piepildīts ar vērtīgiem laika zīmēm.

No šiem datiem jūs varat aprēķināt svarīgus metriku:

• DNS meklējuma laiks: domainLookupEnd - domainLookupStart
• TCP roku spiediena laiks: connectEnd - connectStart
• Laiks līdz pirmajam baitam (TTFB): responseStart - requestStart
• Kopējais lapas ielādes laiks: loadEventEnd - startTime

Šī pieeja ļauj jums izveidot pielāgotus informācijas paneļus vai nosūtīt veiktspējas datus uz jūsu analītikas rīkiem, sniedzot jums nepārtrauktu pārskatu par jūsu lietojumprogrammas reālās pasaules veiktspēju. Tīmekļa izstrādē attēlu optimizācija ir izplatīts veids, kā uzlabot šos rādītājus; tiem, kas interesējas, mums ir noderīgs ceļvedis par to, kā izvēlēties labāko attēlu formātu jūsu vietnei.

Pārbaudes vienkāršošana ar integrētiem rīkiem

Lejupielādējot starp termināli, pārlūkprogrammas izstrādātāja rīkiem un pielāgotajiem skriptiem, var ātri apnikt. Šeit integrētās pārlūkprogrammas paplašinājumi var patiešām uzlabot jūsu darba plūsmu, apvienojot šīs pārbaudes. Piemēram, ShiftShift Extensions komplekts ietver iebūvētu Ātruma testu, ko varat atvērt nekavējoties no jebkura cilnes.

Tas sniedz jums ātru, privātumu ievērojošu veidu, kā izmērīt jūsu savienojuma lejupielādes ātrumu, augšupielādes ātrumu un latentumu, neiznākot uz atsevišķu vietni vai atverot termināli. Tā kā tas ir daļa no lielāka rīku komplekta, jūs varat veikt ātruma pārbaudi, formatēt JSON atbildi un pārbaudīt sīkdatni, viss no vienas apvienotas komandu paletes. Šāda veida integrācija padara veiktspējas pārbaudes par dabiski, bezberzes daļu ikdienas izstrādes procesā.

Kā izstrādāt latentuma testu, kas patiešām sniedz informāciju

Ikviens var izsist ping komandu un saņemt atpakaļ skaitli. Bet, ja vēlaties datus, kuriem varat uzticēties—datus, kas palīdz pieņemt reālus lēmumus—jums jābūt apdomīgākam. Viens izolēts mērījums ir tikai mirkļa attēls. Lai patiešām izprastu jūsu tīkla uzvedību, jums jādomā kā detektīvam, ņemot vērā, no kurienes jūs testējat, cik bieži jūs testējat un ko jūs patiesībā meklējat.

Labi izstrādāts tests pārvērš neapstrādātus skaitļus rīcībspējīgās atziņās. Vāji izstrādāts? Tas ir tikai troksnis.

Zemāk redzamais diagramma sadala visus mazos aizkavējumus, kas veido to, ko lietotājs jūt, kad ielādē tīmekļa lapu. Tas ir lielisks atgādinājums, ka vienkāršs tīkla ping pat nesāk stāstīt visu stāstu.

Kā redzat, no sākotnējās DNS meklēšanas līdz galīgajai renderēšanai vairāki posmi veicina kopējo gaidīšanas laiku.

Testēšanas galapunktu izvēle

Pirmais uzticamu testu noteikums ir tas, ka ģeogrāfija ir svarīga. Tests no jūsu biroja Ņujorkā uz serveri, kas atrodas netālu Ņūdžersijā, jums absolūti neko nepasaka par pieredzi jūsu klientiem Tokijā. Lai iegūtu reālistisku ainu, jums jāveic testi no dažādām vietām, kas patiešām atspoguļo jūsu lietotāju bāzi.

Jūsu galapunktu sarakstam jāaptver daži galvenie apgabali:

• Jūsu lielākie lietotāju centri: Kur dzīvo lielākā daļa jūsu klientu? Testējiet no turienes.
• Starpkontinentālie ceļi: Redziet, kas notiek, kad datiem jāšķērso okeāns. Testējiet starp Eiropu un Ziemeļameriku vai Āziju un ASV, lai izprastu ilgtermiņa veiktspēju.
• Jūsu mākoņu reģioni: Ja esat AWS, Azure vai GCP, pārbaudiet savienojamību uz un starp konkrētajiem datu centra reģioniem, uz kuriem paļaujaties.

Izkliedējot savus testus šādā veidā, tiek izveidota daudz precīzāka globālās veiktspējas karte. Tas palīdz jums pamanīt reģionā specifiskus šaurumus, kurus jūs citādi pilnībā palaistu garām. Šis ir arī labs brīdis, lai divreiz pārbaudītu savu domēna iestatījumu; jūs varat atrast noderīgus padomus par kā pārbaudīt domēna pieejamību un saistītajām konfigurācijām, lai nodrošinātu, ka viss ir kārtībā.

Atbilstošā testēšanas ritma atrašana

Tīkla apstākļi pastāvīgi mainās. Tie mainās visas dienas, nedēļas un pat minūtes laikā. Tests, kas veikts 3:00 no rīta otrdienā, var izskatīties lieliski, bet šis rezultāts ir bezjēdzīgs, ja jūsu maksimālais satiksmes apjoms ir 14:00 piektdien, kad visi ir tiešsaistē.

Lai iegūtu patiesu bāzes līmeni, jums jāveic testi konsekventi laika gaitā. Mainiet to:

• Veiciet testus pīķa darba stundās.
• Plānojiet dažus nakts apkalpošanas logiem.
• Neaizmirstiet par brīvdienām, kad satiksmes modeļi var būt pilnīgi atšķirīgi.

Veicot datu paraugu atkārtoti, jūs varat izlīdzināt nejaušos uzplūdus un kritumus. Tā ir veids, kā pamanīt atkārtotas problēmas, piemēram, tīkla sastrēgumus katru darba dienas pēcpusdienu tūlīt pēc pusdienām.

Neaizmirstiet par jitter

Vidējais latentums ir labs sākumpunkts, bet tas bieži slēpj nopietnāku problēmu: jitter. Jitter ir vienkārši svārstības jūsu latentumā laika gaitā. Padomājiet par to—stabils savienojums ar paredzamu 80ms aizkavi bieži ir daudz labāks reāllaika lietotnēm nekā tāds, kas vidēji ir 50ms, bet svārstās starp 10ms un 200ms.

Jitter ir kluss lietotāju pieredzes slepkava visam reāllaikā, piemēram, VoIP zvaniem, video konferencēm vai tiešsaistes spēlēm. Augsts jitter ir tas, kas izraisa traucētu audio, iesaldētu video un kaitinošus aizkavējumus, kas liek lietotnei justies pilnīgi salauztai, pat ja vidējais latentums izskatās labi uz papīra.

Izpratne par jitter nozīmē skatīties tālāk par vidējo. Tas ir neatzītais ļaundaris, jo tas atklāj, kāpēc vidējie rādītāji var būt tik maldinoši. Piemēram, dati no Pandora FMS rāda, ka jitter virs 30ms var palielināt paketes zuduma līmeni spēlēs līdz 15%—pietiekami, lai padarītu spēli neizspēlējamu. Standarta novirzes mērīšana jūsu latentuma rezultātos ir pirmais solis, lai noteiktu šo nestabilitāti.

Latentuma testa izstrādes kontrolsaraksts

Lai visu to apkopotu, šeit ir ātrs kontrolsaraksts, kas palīdzēs jums. Šo soļu ievērošana palīdzēs nodrošināt, ka dati, ko jūs savācat, ir gan precīzi, gan patiesi noderīgi.

Kontrolsaraksta vienums	Kāpēc tas ir svarīgi	Rīcības padoms
Definējiet skaidrus mērķus	Jūs nevarat izmērīt to, ko neesat definējis. Vai jūs risināt konkrētu problēmu vai izveidojat bāzes līmeni?	Pierakstiet savu mērķi pirms sākat. "Diagnostizēt aizkavi lietotājiem Dienvidaustrumāzijā" ir labāks mērķis nekā "pārbaudīt latentumu."
Izvēlieties dažādus galapunktus	Viens ceļš nepārstāv jūsu globālo lietotāju pieredzi.	Izvēlieties 3-5 vietas: vienu vietējo, vienu citā kontinentā un dažas jūsu galvenajos lietotāju tirgos.
Izveidojiet ritmu	Vienreizēji testi izlaida laika balstītās shēmas, piemēram, pīķa stundu sastrēgumus.	Plānojiet testus automātiski darboties katru stundu nedēļas laikā, lai noķertu pilnu tīkla uzvedības ciklu.
Mēriet jitter	Vidējie rādītāji slēpj haotisko veiktspēju, kas sabojā reāllaika lietotnes.	Ne tikai skatieties uz vidējo RTT. Aprēķiniet standarta novirzi vai izmantojiet rīku, piemēram, mtr, kas rāda min/max/vidējo latentumu.
Izmantojiet pareizos rīkus	ping ir labs ātrai pārbaudei, bet rīki, piemēram, mtr vai iperf, sniedz dziļākas atziņas.	Tīmekļa veiktspējai izmantojiet pārlūkprogrammas izstrādātāja rīkus. Neapstrādātiem tīkla ceļiem mtr ir lieliska izvēle.
Dokumentējiet visu	Jūs aizmirsīsiet "kāpēc" aiz jūsu testa sešu mēnešu laikā.	Saglabājiet vienkāršu žurnālu: datums, laiks, galapunkti, izmantotais rīks un īss ieraksts par to, ko novērojāt.

Esot metodiskam, jūs pārvietojaties no vienkāršas latentuma mērīšanas uz patiesu izpratni par to. Šī apdomīgā pieeja ir tas, kas atšķir nejaušu skaitli no uzticama veiktspējas rādītāja.

Skaitļu izpratne (un ko izvairīties)

Labi, jūs esat veikuši savus testus un jums ir liels datu apjoms. Šeit sākas īstais darbs—pārvērst šos neapstrādātos skaitļus kaut kas, kas patiešām nozīmē kaut ko. Dati stāsta jums stāstu par jūsu tīkla veselību; jums tikai jāiemācās to lasīt.

Piemēram, pēkšņs pieaugums Round-Trip Time (RTT) uz traceroute ir klasiskā norāde. Ja latentums pieaug trešajā hopā un paliek augsts līdz beigām, jūs, iespējams, esat atradis savu problēmu: tas ir trešais maršrutētājs vai saite tieši pēc tā. Bet esiet uzmanīgi. Ja tikai tas viens hops rāda augstu latentumu un galamērķis joprojām ir ātrs, tas var būt tikai maršrutētājs, kas konfigurēts, lai samazinātu tieši tādu satiksmi, kādu izmantojat jūsu tests. Tas ir izplatīts viltus trauksmes gadījums, kas var novest jūs pie nepareizām secinājumiem.

Jitter un paketes zuduma dekodēšana

Skatoties tālāk par vienkāršo RTT, jūs atradīsiet vissvarīgākās atziņas. Augsts jitter, kas ir tikai izsmalcināts vārds nesakārtotam latentumam, var būt daudz traucējošāks nekā konsekventi augsts latentums. Tas ir īpaši patiesi visam reāllaikā.

Ja jūsu rezultāti rāda vidējo RTT 40ms, bet minimālais bija 10ms un maksimālais bija 150ms, jūsu savienojums ir nestabils. Šī milzīgā variācija ir tieši tas, kas izraisa kaitinošus traucējumus video zvanos un dusmīgas aizkaves tiešsaistes spēlēs.

Paketes zudums ir vēl lielāks sarkanais karogs. Pat 1% paketes zudums var pilnībā paralizēt TCP balstītas lietotnes, piespiežot tās pastāvīgi nosūtīt datus un palēnināt visu līdz lēnai kustībai. Kad skatāties uz saviem testa rezultātiem, jebkurai reālai atšķirībai starp nosūtītajām un saņemtajām paketēm ir jābūt nekavējoties izpētītai.

Viens no lielākajiem kļūdām, ko redzu cilvēkiem, ir pieņemt, ka viens tests stāsta visu stāstu. Tīkla apstākļi pastāvīgi mainās. Tests, kas veikts 3:00 no rīta, izskatīsies pilnīgi citādi nekā tests 3:00 pēcpusdienā pīķa darba stundās. Vienīgais veids, kā iegūt patiesu veiktspējas bāzes līmeni, ir konsekventi, atkārtoti testi.

Lai novērstu problēmas, ir vērts apsvērt veltītus rīkus tīkla veiktspējas uzraudzībai. Tas maina jūsu pieeju no izmisīgas problēmu risināšanas, kad tās sabojājas, uz proaktīvu tīkla veselības uzturēšanu.

Visbiežāk sastopamās mērīšanas kļūdas

Pat ar labākajiem rīkiem pasaulē dažas vienkāršas kļūdas var padarīt jūsu rezultātus pilnīgi bezjēdzīgus. Izvairīšanās no šīm izplatītajām kļūdām ir neizbēgama, ja vēlaties datus, kuriem varat uzticēties.

• Testēšana, izmantojot Wi-Fi: Patiesībā, vienkārši nedariet to. Bezvadu savienojumi ir pazīstami ar savu nestabilitāti, pakļauti traucējumiem no visām lietām, sākot no mikroviļņu krāsnīm līdz jūsu kaimiņa maršrutētājam. Jebkurai nopietnai latentuma testēšanai pieslēdzieties ar Ethernet kabeli. Tas ir vienīgais veids, kā iegūt stabilu, uzticamu bāzes līmeni.
• VPN slodzes aizmirstšana: VPN ir lieliski drošībai, bet tie pievieno papildu pieturu un šifrēšanu jūsu satiksmes ceļojumam. Tas vienmēr palielinās latentumu. Ja jūs mēģināt diagnosticēt lietotāja lēno savienojumu, viens no jūsu pirmajiem jautājumiem būtu: "Vai jūs esat VPN?" Testēšana ar un bez tā parādīs, cik daudz aizkaves tas pievieno.
• Vietējā tīkla sastrēgumu ignorēšana: Jūsu testa rezultāti būs sagrozīti, ja kāds cits jūsu tīklā izmanto visu joslas platumu. Ja kolēģis straumē 4K video vai lejupielādē milzīgus failus, kamēr jūs testējat, jūsu latentuma skaitļi būs uzpūsti, un jūs beigsiet ar problēmu, kas nepastāv.

Vēl viens smalks, bet kritisks faktors ir rīks, ko izvēlaties. Kā mēs esam apsprieduši, dažādi rīki mēra latentumu atšķirīgi. Vienmēr esiet konsekventi ar rīkiem, ko izmantojat salīdzināšanai, un pārliecinieties, ka saprotat, ko katrs no tiem patiesībā mēra—vai tas ir vienkāršs ICMP echo vai sarežģīts, lietojumprogrammas līmeņa pieprasījums. Un atcerieties, ka veiktspēju var ietekmēt daudzas slāņi; piemēram, ja jūs izpētāt tīmekļa veiktspēju, mūsu ceļvedis par Cookie Editor Chrome Extension var parādīt, kā klienta puses elementi spēlē lomu.

Interpretējot savus rezultātus ar pareizo kontekstu un izvairoties no šīm izplatītajām kļūdām, jūs pārvietojaties tālāk par vienkāršu skaitļu vākšanu. Jūs sāksiet saprast kāpēc aiz jūsu tīkla veiktspējas, un tas ir atslēga, lai izveidotu ātrākas, uzticamākas sistēmas.

Biežāk uzdotie jautājumi par tīkla latentumu

Pat ar pareizajiem rīkiem dažas izplatītas jautājumi vienmēr šķiet parādās, kad sākat izpētīt tīkla latentumu. Apskatīsim dažus no visbiežāk dzirdētajiem, lai palīdzētu jums saprast savus rezultātus.

Kāds patiesībā ir “labs” latentuma skaitlis?

Šis ir klasiskā "atkarīgs no situācijas" jautājums, bet mēs noteikti varam noteikt dažus stabilus standartus. "Labs" latentums ir pilnīgi relatīvs attiecībā uz to, ko jūs cenšaties sasniegt.

• Ikdienišķa tīmekļa pārlūkošana: Lielākajai daļai no mums jebkas zem 100ms RTT jutīsies pilnīgi labi. Lapas ielādējas ātri, un jūs nepamanīsiet nekādu reālu aizkavi.
• Konkurētspējīgas tiešsaistes spēles: Šeit katra milisekunde ir svarīga. Nopietni spēlētāji un augstas frekvences tirgotāji meklē latentumu, kas ir labi zem 20ms. Tas ir starp uzvaru un zaudējumu.
• Video zvani un VoIP: Šeit konsekvence ir svarīga. Jums nepieciešams stabils latentums zem 150ms un zems jitter (mazāk nekā 30ms), lai izvairītos no traucējošas, nesaskaņotas sajūtas vai, vēl sliktāk, nozaudētiem zvaniem.

Kā vispārējs noteikums, lielākā daļa tīkla profesionāļu, ko pazīstu, klasificētu jebko zem 50ms kā zemu latentumu. No 50-150ms ir mēreni, un, kad jūs pārsniedzat 150ms, jūs sāksiet just vilkmi lielākajā daļā interaktīvo lietotņu.

Kāpēc mani ping un pārlūkprogrammas ātruma testa rezultāti nekad nesakrīt?

Šis ir lielisks jautājums un ļoti izplatīta neskaidrība. Tas notiek, jo komandrindas ping un pārlūkprogrammas balstīts ātruma tests ir fundamentāli atšķirīgi rīki, kas mēra atšķirīgas lietas.

Pirmkārt, tie gandrīz noteikti runā ar atšķirīgiem serveriem. Kad jūs ping domēnu, jūs sasniedzat konkrētu mērķi. Savukārt tīmekļa ātruma tests ir izstrādāts, lai atrastu ģeogrāfiski tuvāku serveri no sava tīkla, lai sniegtu jums labāko iespējamo rezultātu.

Protokoli arī ir pilnīgi atšķirīgi. Ping izmanto ļoti vieglu protokolu, ko sauc par ICMP. Lielākā daļa pārlūkprogrammu testu darbojas pār TCP, kas prasa visu iestatīšanas procesu (trīs posmu roku spiediens), lai izveidotu savienojumu. Šī sākotnējā atgriešanās un atpakaļ pievieno nedaudz laika pirms reālā testa pat sākas.

Visbeidzot, pārlūkprogrammas testi bieži iekļauj vairāk nekā tikai tīkla ceļojuma laiku. To "latentuma" skaitlis var ietvert servera apstrādes laiku vai pat nelielus aizkavējumus jūsu pārlūkprogrammā, kas var palielināt galīgo skaitli salīdzinājumā ar neapstrādātu ICMP ping.

Kā es varu patiešām samazināt savu tīkla latentumu?

Latences samazināšana ir saistīta ar pudeles kakla atrašanu un novēršanu, neatkarīgi no tā, vai tās atrodas jūsu birojā vai internetā.

Pirmais, ko jāpārbauda, ir jūsu tuvākā vide. Visefektīvākais solis, ko varat veikt, ir pāreja no Wi-Fi uz vadu Ethernet savienojumu. Tas ir izšķirošs stabilitātei un ātrumam. Ja jums jāizmanto Wi-Fi, pietuvinieties savam maršrutētājam un, ja iespējams, pārejiet uz 5GHz joslu — tā parasti ir mazāk noslogota.

Skatoties ārpus jūsu vietējā tīkla, dažreiz DNS maiņa var palīdzēt. Ātrāka DNS servera izmantošana var samazināt milisekundes no sākotnējā savienojuma laika, kad meklējat tīmekļa vietni.

Ja mēģināt uzlabot piekļuvi pakalpojumam, ko kontrolējat, atbilde ir Satura piegādes tīkls (CDN). Tas darbojas, novietojot jūsu satura kopijas fiziski tuvāk jūsu lietotājiem. Un, ja izmantojat VPN, mēģiniet to izslēgt. Šis papildu lēciens un šifrēšanas slānis gandrīz vienmēr pievieno latenci.

Es esmu redzējis, ka korporatīvie VPN pievieno pat 70ms ceļojuma laikam. Tas var pārvērst lielisku savienojumu par apgrūtinoši lēnu. Vienmēr pārbaudiet ar un bez sava VPN, lai redzētu, kādu veiktspējas samazinājumu jūs patiesībā piedzīvojat.

Kāda ir reālā atšķirība starp latenci un joslas platumu?

Šī pareizā izpratne ir pamatprincipi tīkla veiktspējas izpratnei. Ir viegli tās sajaukt, bet tās mēra divas ļoti atšķirīgas lietas.

Šeit ir analoģija, ko es vienmēr izmantoju: domājiet par to kā par šoseju.

• Joslas platums ir tas, cik daudz joslu ir šosejai. Vairāk joslu nozīmē, ka vairāk automašīnu (datu) var ceļot vienlaicīgi.
• Latence ir ātruma ierobežojums. Tas nosaka, cik ātri viena automašīna (datu pakete) var nokļūt no A uz B.

Jums var būt milzīga, desmit joslu šoseja (liels joslas platums) ar 20 mph ātruma ierobežojumu (augsta latence). Jūs varētu pārvietot tonnu datu, bet reāllaika lietas, piemēram, videozvans, būtu sāpīgi lēnas. Savukārt savienojums ar ļoti zemu latentumu jūtas neticami ātrs un atsaucīgs, pat ja tā joslas platums nav milzīgs. Jums patiešām ir nepieciešams labs līdzsvars starp abiem, lai nodrošinātu lielisku pieredzi.

---

Vai esat gatavs padarīt veiktspējas testēšanu par nevainojamu jūsu ikdienas darba plūsmas daļu? ShiftShift Extensions komplekts nodrošina jaudīgu ātruma testu, JSON formatētāju un desmitiem citu izstrādātāju rīku tieši jūsu pārlūkā, pieejamus ar vienu komandu. Pārtrauciet tabulu žonglēšanu un sāciet strādāt gudrāk. Lejupielādējiet ShiftShift Extensions bez maksas un uzlabojiet savu produktivitāti jau šodien.