Din download er hurtig, så hvorfor føles hvert klik langsomt?

At downloade en stor fil hurtigt og derefter opleve, at hvert klik er langsomt, er ikke en modsætning. Kapacitet siger, hvor meget der kan flyttes pr. sekund; rundturstid siger, hvor længe en udveksling tager, før noget nyttigt sker. Forbedring af det første gør intet for det andet, og det andet er det, en person bemærker, mens han skriver, klikker eller taler. Mål klagen, ikke forbindelsen.

Hurtig fil, langsomt klik: to forskellige tal

En masseoverførsel holder data i bevægelse hele tiden, så den kan rapportere en sund hastighed, selv når hver enkelt anmodning venter. Mange benchmarks åbner også flere forbindelser på én gang, hvilket hæver det samlede tal, mens en enkelt anmodning forbliver langsom. De to resultater er forenelige, og at citere det højere for en bruger, der klager over forsinkelse, er måden, hvorpå tillid tabes.

Indlæsning af en side er en kæde af små udvekslinger: navneopløsning, forbindelsesopsætning, en anmodning, et svar og derefter afhængige anmodninger. Hvert trin betaler rundturen igen, så en rute med høj forsinkelse føles langsom, selv når den har masser af kapacitet.

Tunnelen tilføjer sin egen rejse og behandling, og ruten betyder mere end etiketten på et kort. To udgange i samme land kan have meget forskellige veje til én destination. En forskel på tyve millisekunder er nok til at ændre, hvordan en side føles, selv om den næsten ikke flytter et gennemstrømningstal. Derfor bør valget af udgang følge en stikprøve af latenstiden frem for et flagikon.

Mål klagen, ikke forbindelsen

Vælg den måling, der passer til den sætning, brugeren sagde. En langsom download kræver en vedvarende hastighed i den rigtige retning; et opkald, der hakker, kræver den pågældende applikations egne statistikker; en side, der starter langsomt, kræver tider for navneopløsning og opsætning.

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 4

Den første kommando giver en rundturprøve til en vært, der svarer forudsigeligt, den anden rapporterer tid til første byte og vedvarende hastighed for én forbindelse, og den tredje måler den samlede gennemstrømning med fire parallelle strømme. Kør dem mod den samme destination på samme tid af dagen, fordi en sammenligning af en morgenprøve med en aftenprøve giver en historie i stedet for en måling.

Hold destinationen fast, når du sammenligner udgange. At ændre både serveren og tunnelen gør én variabel til to, og resultatet kan ikke fortælle dig, hvilken der betød noget. Kør hver udgang mindst tre gange, fordi en enkelt prøve ofte falder under en ruteændring eller et støjende minut. Medianen er mere nyttig end det bedste tilfælde.

Behandl ICMP som et spor frem for svaret. En vært, der svarer, kan håndtere ekkoanmodninger ad en anden vej end den, din applikation bruger, og et tabt svar er ikke bevis for, at hver applikation taber pakker.

Latenstid under belastning er et køproblem

Det mønster, der forvirrer folk mest, er en forbindelse, der føles fin i tomgang og ubrugelig under en sikkerhedskopiering. Det er kø, ikke kapacitet. Et mættet uplink opbygger en buffer foran hver anden pakke, så et tastetryk venter bag en del af uploadet.

ping -c 20 10.60.0.5 &
iperf3 -c 10.60.0.5 -t 20 -R -b 20M

Den første kommando tager stikprøver af latenstiden i baggrunden, mens den anden mætter den modsatte retning. Hvis ping-tiderne springer under overførslen og kommer sig bagefter, har du genskabt bufferbloat i stedet for at finde en ruteingfejl. Rettelsen er normalt en køstyringsindstilling, en lavere baggrundshastighed eller at flytte masseoverførslen væk fra den interaktive vej.

At reducere valgfri baggrundstrafik hjælper ofte mere end at skifte udgangsland. Det er også billigere, reversibelt og testbart på et minut. Planlæg store uploads uden for arbejdstiden, hvis køen ikke kan styres, og begræns deres hastighed, hvis de skal køre i løbet af dagen. En køstyringsindstilling er den bedre rettelse, når routeren understøtter en.

Ændr én ting og sammenlign ens med ens

Ved høj tomgangsforsinkelse skal du sammenligne udgange med destinationen fast og derefter sammenligne ruter for den bedste kandidat. Ved lav stabil gennemstrømning skal du i stedet se på kapacitet, serverbelastning og klientbehandling, fordi det er forskellige grænser.

Skriv ned, hvad du målte, mod hvilken destination, på hvilket tidspunkt og med hvilke indstillinger. En sammenligning uden disse fire fakta kan ikke gentages, og den næste person starter fra nul.

Tilpas derefter værktøjet til påstanden i sagen. "Langsomt internet" er ikke en måling; "den første byte tog 900 ms til denne vært, mens gennemstrømningen var fin" er en, og den peger direkte på forsinkelse frem for kapacitet.