Din nedladdning är snabb, så varför känns varje klick långsamt?

Att ladda ner en stor fil snabbt och sedan uppleva att varje klick är långsamt är ingen motsägelse. Kapacitet säger hur mycket som kan flyttas per sekund; rundturstid säger hur länge ett utbyte varar innan något användbart händer. Att förbättra det första gör ingenting för det andra, och det andra är det en person märker medan hen skriver, klickar eller pratar. Mät klagomålet, inte anslutningen.

Snabb fil, långsamt klick: två olika tal

En massöverföring håller data i rörelse hela tiden, så den kan rapportera en sund hastighet även när varje enskild begäran väntar. Många benchmarkar öppnar också flera anslutningar samtidigt, vilket höjer den sammanlagda siffran medan en enda begäran förblir långsam. De två resultaten är förenliga, och att citera det högre för en användare som klagar på fördröjning är hur förtroende går förlorat.

En sidladdning är en kedja av små utbyten: namnsökning, anslutningsuppkoppling, en begäran, ett svar och sedan beroende begäranden. Varje steg betalar rundturen igen, så en väg med hög fördröjning känns långsam även när den har gott om kapacitet.

Tunneln lägger till sin egen resa och bearbetning, och rutten spelar större roll än etiketten på en karta. Två utgångar i samma land kan ha mycket olika vägar till en destination. En skillnad på tjugo millisekunder räcker för att ändra hur en sida känns, även om den knappt rör en genomströmningssiffra. Därför bör valet av utgång följa ett svarstidsprov och inte en flaggikon.

Mät klagomålet, inte anslutningen

Välj den mätning som passar meningen användaren sa. En långsam nedladdning behöver en uthållig hastighet i rätt riktning; ett samtal som hackar behöver just den applikationens egen statistik; en sida som startar långsamt behöver tider för namnsökning och uppkoppling.

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

Det första kommandot ger ett rundtursprov till en värd som svarar förutsägbart, det andra rapporterar tiden till första byten och uthållig hastighet för en anslutning, och det tredje mäter den sammanlagda genomströmningen med fyra parallella strömmar. Kör dem mot samma destination vid samma tid på dygnet, eftersom en jämförelse mellan ett morgonprov och ett kvällsprov ger en historia i stället för en mätning.

Håll destinationen fast när du jämför utgångar. Att ändra både servern och tunneln gör en variabel till två, och resultatet kan inte säga vilken som spelade roll. Kör varje utgång minst tre gånger, eftersom ett enda prov ofta hamnar under en ruttändring eller en bullrig minut. Medianen är mer användbar än det bästa fallet.

Behandla ICMP som en ledtråd och inte som svaret. En värd som svarar kan hantera eko-förfrågningar på en annan väg än den din applikation använder, och ett förlorat svar är inte bevis för att varje applikation tappar paket.

Fördröjning under belastning är ett köproblem

Mönstret som förvirrar folk mest är en anslutning som känns bra i vila och oanvändbar under en säkerhetskopiering. Det är kö, inte kapacitet. En mättad upplänk bygger en buffert framför varje annat paket, så ett tangenttryck väntar bakom en del av uppladdningen.

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

Det första kommandot tar prov på svarstiden i bakgrunden medan det andra mättar motsatt riktning. Om ping-tiderna hoppar under överföringen och återhämtar sig efteråt har du återskapat bufferbloat i stället för att hitta ett routingfel. Åtgärden är oftast en köhanteringsinställning, en lägre bakgrundshastighet eller att flytta massöverföringen bort från den interaktiva vägen.

Att minska valfri bakgrundstrafik hjälper ofta mer än att byta utgångsland. Det är också billigare, reversibelt och testbart på en minut. Schemalägg stora uppladdningar utanför arbetstid om kön inte kan hanteras, och begränsa deras hastighet om de måste köras på dagen. En köhanteringsinställning är den bättre åtgärden när routern stöder en.

Ändra en sak och jämför lika med lika

För hög fördröjning i vila, jämför utgångar med destinationen fast och jämför sedan rutter för den bästa kandidaten. För låg stabil genomströmning, titta i stället på kapacitet, serverbelastning och klientbearbetning, eftersom det är olika gränser.

Skriv ner vad du mätte, mot vilken destination, vid vilken tid och med vilka inställningar. En jämförelse utan dessa fyra fakta kan inte upprepas, och nästa person börjar från noll.

Anpassa sedan verktyget till påståendet i ärendet. "Långsamt internet" är ingen mätning; "första byten tog 900 ms till den här värden medan genomströmningen var bra" är en, och den pekar direkt på fördröjning och inte på kapacitet.