Nedlastingen din er rask, så hvorfor føles hvert klikk tregt?
En stor overføring kan gå i full hastighet mens samtaler og klikk henger etter. Mål rundturtid, vedvarende hastighet og forsinkelse under last som tre separate spørsmål.
Å laste ned en stor fil raskt og deretter oppleve at hvert klikk er tregt er ingen motsetning. Kapasitet sier hvor mye som kan flyttes per sekund; rundturtid sier hvor lenge en utveksling varer før noe nyttig skjer. Å forbedre det første gjør ingenting for det andre, og det andre er det en person merker mens han skriver, klikker eller snakker. Mål klagen, ikke forbindelsen.
Rask fil, tregt klikk: to forskjellige tall
En masseoverføring holder dataene i bevegelse hele tiden, så den kan rapportere en sunn hastighet selv når hver enkelt forespørsel venter. Mange benchmarker åpner også flere forbindelser samtidig, noe som hever det samlede tallet mens én forespørsel fortsatt er treg. De to resultatene er forenlige, og å sitere det høyere til en bruker som klager over forsinkelse, er måten tillit går tapt på.
Innlasting av en side er en kjede av små utvekslinger: navneoppslag, oppsett av forbindelse, en forespørsel, et svar og deretter avhengige forespørsler. Hvert trinn betaler rundturen på nytt, så en rute med høy forsinkelse føles treg selv når den har rikelig med kapasitet.
Tunnelen legger til sin egen reise og behandling, og ruten betyr mer enn etiketten på et kart. To utganger i samme land kan ha svært forskjellige veier til én destinasjon. En forskjell på tjue millisekunder er nok til å endre hvordan en side føles, selv om den knapt flytter et gjennomstrømningstall. Derfor bør valget av utgang følge en stikkprøve av latensen og ikke et flaggikon.
Mål klagen, ikke forbindelsen
Velg målingen som passer setningen brukeren sa. En treg nedlasting trenger en vedvarende hastighet i riktig retning; en samtale som hakker trenger den aktuelle applikasjonens egne statistikker; en side som starter tregt trenger tider for navneoppslag 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 en rundturprøve til en vert som svarer forutsigbart, den andre rapporterer tiden til første byte og vedvarende hastighet for én forbindelse, og den tredje måler samlet gjennomstrømning med fire parallelle strømmer. Kjør dem mot samme destinasjon på samme tid av dagen, fordi å sammenligne en morgenprøve med en kveldsprøve gir en historie i stedet for en måling.
Hold destinasjonen fast når du sammenligner utganger. Å endre både serveren og tunnelen gjør én variabel til to, og resultatet kan ikke fortelle deg hvilken som betydde noe. Kjør hver utgang minst tre ganger, fordi en enkelt prøve ofte faller under en ruteendring eller et støyende minutt. Medianen er mer nyttig enn det beste tilfellet.
Behandle ICMP som et spor og ikke som svaret. En vert som svarer kan håndtere ekko-forespørsler på en annen rute enn den applikasjonen din bruker, og ett tapt svar er ikke bevis for at hver applikasjon mister pakker.
Latens under last er et køproblem
Mønsteret som forvirrer folk mest, er en forbindelse som føles fin i tomgang og ubrukelig under en sikkerhetskopiering. Det er kø, ikke kapasitet. En mettet opplastingslinje bygger en buffer foran hver annen pakke, så et tastetrykk venter bak en del av opplastingen.
ping -c 20 10.60.0.5 & iperf3 -c 10.60.0.5 -t 20 -R -b 20M
Den første kommandoen tar stikkprøver av latensen i bakgrunnen mens den andre metter motsatt retning. Hvis ping-tidene hopper under overføringen og kommer seg etterpå, har du gjenskapt bufferbloat i stedet for å oppdage en rutefeil. Rettelsen er vanligvis en køstyringsinnstilling, lavere bakgrunnshastighet eller å flytte masseoverføringen vekk fra den interaktive ruten.
Å redusere valgfri bakgrunnstrafikk hjelper ofte mer enn å bytte utgangsland. Det er også billigere, reversibelt og testbart på et minutt. Planlegg store opplastinger utenfor arbeidstiden hvis køen ikke kan styres, og begrens hastigheten hvis de må kjøre på dagtid. En køstyringsinnstilling er den bedre rettelsen når ruteren støtter en.
Endre én ting og sammenlign likt med likt
For høy tomgangsforsinkelse, sammenlign utganger mens destinasjonen holdes fast, og sammenlign deretter ruter for den beste kandidaten. For lav stabil gjennomstrømning, se i stedet på kapasitet, serverlast og klientbehandling, fordi det er forskjellige grenser.
Skriv ned hva du målte, mot hvilken destinasjon, på hvilket tidspunkt og med hvilke innstillinger. En sammenligning uten disse fire fakta kan ikke gjentas, og neste person starter fra null.
Tilpass deretter verktøyet til påstanden i saken. "Tregt internett" er ikke en måling; "første byte tok 900 ms til denne verten mens gjennomstrømningen var fin" er en, og den peker direkte på forsinkelse og ikke kapasitet.