Je download is snel, dus waarom voelt elke klik traag?

Een groot bestand snel downloaden en dan elke klik traag vinden is geen tegenspraak. Capaciteit zegt hoeveel er per seconde kan bewegen; retourtijd zegt hoe lang een uitwisseling duurt voordat er iets nuttigs gebeurt. Het eerste verbeteren doet niets voor het tweede, en het tweede is wat iemand merkt tijdens het typen, klikken of praten. Meet de klacht, niet de verbinding.

Snel bestand, trage klik: twee verschillende getallen

Een bulkoverdracht houdt de gegevens continu in beweging, dus kan een gezonde snelheid melden zelfs wanneer elk afzonderlijk verzoek wacht. Veel benchmarks openen ook meerdere verbindingen tegelijk, wat het totale getal verhoogt terwijl één verzoek traag blijft. De twee resultaten zijn verenigbaar, en het hogere getal citeren aan een gebruiker die klaagt over vertraging is hoe vertrouwen verloren gaat.

Het laden van een pagina is een keten van kleine uitwisselingen: naamresolutie, verbindingsopbouw, een verzoek, een antwoord en dan afhankelijke verzoeken. Elke stap betaalt de retourtijd opnieuw, dus een pad met hoge vertraging voelt traag ook als het ruim capaciteit heeft.

De tunnel voegt zijn eigen reis en verwerking toe, en de route is belangrijker dan het label op een kaart. Twee uitgangen in hetzelfde land kunnen heel verschillende paden naar één bestemming hebben. Een verschil van twintig milliseconden is genoeg om te veranderen hoe een pagina voelt, ook al beweegt het nauwelijks een doorvoergetal. Daarom moet de keuze van een uitgang een latentiemonster volgen en niet een vlagpictogram.

Meet de klacht, niet de verbinding

Kies de meting die past bij de zin die de gebruiker zei. Een trage download heeft een volgehouden snelheid in de juiste richting nodig; een haperend gesprek heeft de eigen statistieken van die toepassing nodig; een pagina die langzaam start heeft resolutie- en opbouwtijden nodig.

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

De eerste opdracht geeft een retourtijdmonster naar een host die voorspelbaar reageert, de tweede meldt de tijd tot de eerste byte en de volgehouden snelheid voor één verbinding, en de derde meet de totale doorvoer met vier parallelle stromen. Voer ze uit tegen dezelfde bestemming op hetzelfde tijdstip van de dag, want een ochtendmonster vergelijken met een avondmonster levert een verhaal op in plaats van een meting.

Houd de bestemming vast bij het vergelijken van uitgangen. Zowel de server als de tunnel veranderen maakt van één variabele twee, en het resultaat kan je niet zeggen welke telde. Voer elke uitgang minstens drie keer uit, want een enkel monster valt vaak tijdens een routewijziging of een luidruchtige minuut. De mediaan is nuttiger dan het beste geval.

Behandel ICMP als een aanwijzing en niet als het antwoord. Een host die antwoordt kan echo-verzoeken via een ander pad afhandelen dan het pad dat je toepassing gebruikt, en één verloren antwoord is geen bewijs dat elke toepassing pakketten verliest.

Latentie onder belasting is een wachtrijprobleem

Het patroon dat mensen het meest verwart is een verbinding die goed aanvoelt in rust en onbruikbaar tijdens een back-up. Dat is wachtrij, geen capaciteit. Een verzadigde uplink bouwt een buffer voor elk ander pakket, dus een toetsaanslag wacht achter een stuk van de upload.

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

De eerste opdracht bemonstert de latentie op de achtergrond terwijl de tweede de tegenovergestelde richting verzadigt. Als de ping-tijden tijdens de overdracht springen en daarna herstellen, heb je bufferbloat gereproduceerd in plaats van een routeringsfout ontdekt. De oplossing is meestal een wachtrijbeheerinstelling, een lagere achtergrondsnelheid of de bulkoverdracht van het interactieve pad halen.

Optioneel achtergrondverkeer verminderen helpt vaak meer dan het uitgangsland wisselen. Het is ook goedkoper, omkeerbaar en in een minuut te testen. Plan grote uploads buiten werktijd als de wachtrij niet beheerd kan worden, en beperk hun snelheid als ze overdag moeten lopen. Een wachtrijbeheerinstelling is de betere oplossing wanneer de router er een ondersteunt.

Verander één ding en vergelijk gelijk met gelijk

Voor hoge vertraging in rust vergelijk je uitgangen met de bestemming vast, en daarna vergelijk je routes voor de beste kandidaat. Voor lage stabiele doorvoer kijk je juist naar capaciteit, serverbelasting en clientverwerking, want dat zijn andere grenzen.

Schrijf op wat je hebt gemeten, tegen welke bestemming, op welk tijdstip en met welke instellingen. Een vergelijking zonder die vier feiten kan niet worden herhaald, en de volgende persoon begint bij nul.

Pas daarna het gereedschap aan op de bewering in het ticket. "Traag internet" is geen meting; "de eerste byte kostte 900 ms naar deze host terwijl de doorvoer goed was" is er een, en het wijst direct op vertraging en niet op capaciteit.