Nedlastinga di er snøgg, så kvifor kjennest kvart klikk tregt?
Ei stor overføring kan gå i full fart medan samtalar og klikk heng etter. Mål rundturtid, varig hastigheit og forseinking under last som tre separate spørsmål.
Å laste ned ei stor fil snøgt og deretter oppleve at kvart klikk er tregt er inga motsetning. Kapasitet seier kor mykje som kan flyttast per sekund; rundturtid seier kor lenge ei utveksling varer før noko nyttig skjer. Å betre det første gjer ingenting for det andre, og det andre er det ein person merkar medan han skriv, klikkar eller snakkar. Mål klaga, ikkje sambandet.
Snøgg fil, tregt klikk: to ulike tal
Ei masseoverføring held dataa i rørsle heile tida, så ho kan rapportere ein sunn hastigheit sjølv når kvar einskild førespurnad ventar. Mange benchmarkar opnar òg fleire samband samstundes, noko som hevar det samla talet medan éin førespurnad framleis er treg. Dei to resultata er sameinlege, og å sitere det høgare til ein brukar som klagar over forseinking, er måten tillit går tapt på.
Innlasting av ei side er ei kjede av små utvekslingar: namneoppslag, oppsett av samband, ein førespurnad, eit svar og deretter avhengige førespurnader. Kvart steg betaler rundturen på nytt, så ein rute med høg forseinking kjennest treg sjølv når han har rikeleg kapasitet.
Tunnelen legg til si eiga reise og handsaming, og ruta tyder meir enn etiketten på eit kart. To utgangar i same land kan ha svært ulike vegar til éin destinasjon. Ein skilnad på tjue millisekund er nok til å endre korleis ei side kjennest, sjølv om han knapt flyttar eit gjennomstrøymingstal. Difor bør valet av utgang følgje ein stikkprøve av latensen og ikkje eit flaggikon.
Mål klaga, ikkje sambandet
Vel målinga som passar setninga brukaren sa. Ei treg nedlasting treng ein varig hastigheit i rett retning; ein samtale som hakkar treng statistikkane til den aktuelle applikasjonen; ei side som startar tregt treng tider for namneoppslag og oppsett.
ping -c 20 10.60.0.5
curl -sS -o /dev/null -w 'ttfb=%{time_starttransfer} rate=%{speed_download}\n' https://files.plant.example/1gb.bin
iperf3 -c 10.60.0.5 -t 10 -P 4Den første kommandoen gir ei rundturprøve til ein vert som svarar føreseieleg, den andre rapporterer tida til første byte og varig hastigheit for eitt samband, og den tredje måler samla gjennomstrøyming med fire parallelle straumar. Køyr dei mot same destinasjon på same tid av dagen, fordi å samanlikne ei morgonprøve med ei kveldsprøve gir ei historie i staden for ei måling.
Hald destinasjonen fast når du samanliknar utgangar. Å endre både tenaren og tunnelen gjer éin variabel til to, og resultatet kan ikkje fortelje deg kva som tydde noko. Køyr kvar utgang minst tre gonger, fordi ei enkel prøve ofte fell under ei ruteendring eller eit støyande minutt. Medianen er meir nyttig enn det beste tilfellet.
Handsam ICMP som eit spor og ikkje som svaret. Ein vert som svarar kan handsame ekko-førespurnader på ei anna rute enn den applikasjonen din brukar, og eitt tapt svar er ikkje prov for at kvar applikasjon mistar pakkar.
Latens under last er eit køproblem
Mønsteret som forvirrar folk mest, er eit samband som kjennest fint i tomgang og ubrukeleg under ein tryggleikskopi. Det er kø, ikkje kapasitet. Ei metta opplastingslinje byggjer ein buffer framfor kvar annan pakke, så eit tastetrykk ventar bak ein del av opplastinga.
ping -c 20 10.60.0.5 & iperf3 -c 10.60.0.5 -t 20 -R -b 20M
Den første kommandoen tek stikkprøver av latensen i bakgrunnen medan den andre mettar motsett retning. Viss ping-tidene hoppar under overføringa og kjem seg etterpå, har du attskapt bufferbloat i staden for å oppdage ein rutefeil. Rettelsen er vanlegvis ei køstyringsinnstilling, lågare bakgrunnshastigheit eller å flytte masseoverføringa vekk frå den interaktive ruta.
Å redusere valfri bakgrunnstrafikk hjelper ofte meir enn å byte utgangsland. Det er òg billegare, reversibelt og testbart på eit minutt. Planlegg store opplastingar utanfor arbeidstida viss køen ikkje kan styrast, og avgrens hastigheita viss dei må køyre på dagtid. Ei køstyringsinnstilling er den betre rettelsen når ruteren støttar ei.
Endre éin ting og samanlikn likt med likt
For høg tomgangsforseinking, samanlikn utgangar medan destinasjonen blir halden fast, og samanlikn deretter ruter for den beste kandidaten. For låg stabil gjennomstrøyming, sjå i staden på kapasitet, tenarlast og klienthandsaming, fordi det er ulike grenser.
Skriv ned kva du målte, mot kva destinasjon, på kva tidspunkt og med kva innstillingar. Ei samanlikning utan desse fire fakta kan ikkje gjentakast, og neste person startar frå null.
Tilpass deretter verktøyet til påstanden i saka. "Tregt internett" er ikkje ei måling; "første byte tok 900 ms til denne verten medan gjennomstrøyminga var fin" er ei, og ho peikar direkte på forseinking og ikkje kapasitet.