La teva descàrrega és ràpida, així que per què cada clic sembla lent?

Descarregar un fitxer gran ràpidament i després trobar que cada clic és lent no és cap contradicció. La capacitat diu quant pot viatjar per segon; el temps d’anada i tornada diu quant dura un intercanvi abans que passi res útil. Millorar el primer no fa res pel segon, i el segon és el que nota una persona mentre escriu, fa clic o parla. Mesura la queixa, no la connexió.

Fitxer ràpid, clic lent: dos números diferents

Una transferència massiva manté les dades en moviment continu, així que pot informar d’una velocitat saludable fins i tot quan cada petició individual espera. Molts bancs de proves també obren diverses connexions alhora, cosa que apuja la xifra agregada mentre una sola petició continua lenta. Els dos resultats són compatibles, i citar el més alt a un usuari que es queixa de retard és com es perd la confiança.

La càrrega d’una pàgina és una cadena de petits intercanvis: resolució de noms, establiment de connexió, una petició, una resposta i després peticions dependents. Cada pas torna a pagar l’anada i tornada, així que un camí amb molt de retard sembla lent fins i tot quan té capacitat de sobres.

El túnel hi afegeix el seu propi viatge i processament, i la ruta importa més que l’etiqueta en un mapa. Dues sortides al mateix país poden tenir camins molt diferents cap a una destinació. Una diferència de vint mil·lisegons ja canvia com se sent una pàgina, tot i que amb prou feines mou una xifra de rendiment. Per això la selecció de sortida ha de seguir una mostra de latència i no una icona de bandera.

Mesura la queixa, no la connexió

Tria el mesurament que encaixi amb la frase que ha dit l’usuari. Una descàrrega lenta necessita una velocitat sostinguda en la direcció correcta; una trucada amb retard necessita les estadístiques pròpies d’aquella aplicació; una pàgina que arrenca lentament necessita els temps de resolució i d’establiment.

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

La primera ordre dóna una mostra d’anada i tornada a un amfitrió que respon de manera previsible, la segona informa del temps fins al primer byte i de la velocitat sostinguda per a una connexió, i la tercera mesura el rendiment agregat amb quatre fluxos paral·lels. Executa-les contra la mateixa destinació a la mateixa hora del dia, perquè comparar una mostra del matí amb una del vespre produeix una història i no un mesurament.

Mantén la destinació fixa quan comparis sortides. Canviar alhora el servidor i el túnel converteix una variable en dues, i el resultat no et pot dir quina va importar. Executa cada sortida almenys tres vegades, perquè una sola mostra sovint cau en un canvi d’encaminament o en un minut sorollós. La mediana és més útil que el millor cas.

Tracta l’ICMP com una pista i no com la resposta. Un amfitrió que respon pot gestionar les peticions d’eco per un camí diferent del que fa servir la teva aplicació, i una resposta perduda no és prova que totes les aplicacions perdin paquets.

La latència sota càrrega és un problema de cues

El patró que més confon la gent és una connexió que va bé en repòs i és inutilitzable durant una còpia de seguretat. Això és cua, no capacitat. Un enllaç de pujada saturat construeix un buffer davant de cada altre paquet, així que una tecla espera darrere d’un tros de la pujada.

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

La primera ordre mostreja la latència en segon pla mentre la segona satura la direcció inversa. Si els temps de ping salten durant la transferència i es recuperen després, has reproduït bufferbloat en lloc de descobrir una fallada d’encaminament. La solució sol ser un paràmetre de gestió de cues, una velocitat de fons més baixa o treure la transferència massiva del camí interactiu.

Reduir el trànsit de fons opcional sovint ajuda més que canviar de país de sortida. També és més barat, reversible i comprovable en un minut. Programa les pujades grans fora de l’horari laboral si la cua no es pot gestionar, i limita’n la velocitat si han de funcionar de dia. Un paràmetre de gestió de cues és la millor solució quan el router en suporta un.

Canvia una cosa i compara igual amb igual

Per a un retard alt en repòs, compara sortides mantenint la destinació fixa i després compara rutes per al millor candidat. Per a un rendiment baix i estable, mira en canvi la capacitat, la càrrega del servidor i el processament del client, perquè són límits diferents.

Anota què has mesurat, contra quina destinació, a quina hora i amb quins paràmetres. Una comparació sense aquests quatre fets no es pot repetir, i la persona següent començarà de zero.

Després ajusta l’eina a l’afirmació del tiquet. "Internet lent" no és un mesurament; "el primer byte va trigar 900 ms fins a aquest amfitrió mentre el rendiment era bo" sí que ho és, i apunta directament al retard i no a la capacitat.