A túa descarga é rápida, entón por que cada clic se sente lento?

Descargar un ficheiro grande rapidamente e logo atopar que cada clic é lento non é unha contradición. A capacidade di canto pode moverse por segundo; o tempo de ida e volta di canto dura un intercambio antes de que ocorra algo útil. Mellorar o primeiro non fai nada polo segundo, e o segundo é o que nota unha persoa mentres escribe, fai clic ou fala. Mide a queixa, non a conexión.

Ficheiro rápido, clic lento: dous números distintos

Unha transferencia masiva mantén os datos en movemento continuo, así que pode informar dunha velocidade saudable mesmo cando cada solicitude individual espera. Moitos benchmarks tamén abren varias conexións á vez, o que eleva a cifra agregada mentres unha soa solicitude segue lenta. Os dous resultados son compatibles, e citar o máis alto a un usuario que se queixa de atraso é como se perde a confianza.

A carga dunha páxina é unha cadea de pequenos intercambios: resolución de nomes, establecemento da conexión, unha solicitude, unha resposta e logo solicitudes dependentes. Cada paso volve pagar a ida e volta, así que un camiño con moito atraso séntese lento aínda que teña capacidade de sobra.

O túnel engade a súa propia viaxe e procesamento, e a ruta importa máis que a etiqueta nun mapa. Dúas saídas no mesmo país poden ter camiños moi distintos cara a un destino. Unha diferenza de vinte milisegundos basta para cambiar como se sente unha páxina, aínda que apenas mova unha cifra de rendemento. Por iso a selección de saída debe seguir unha mostra de latencia e non unha icona de bandeira.

Mide a queixa, non a conexión

Escolle a medición que coincida coa frase que dixo o usuario. Unha descarga lenta necesita unha velocidade sostida na dirección correcta; unha chamada con atraso necesita as estatísticas propias desa aplicación; unha páxina que arranca amodo necesita tempos de resolución e establecemento.

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

O primeiro comando dá unha mostra de ida e volta a un host que responde de forma previsible, o segundo informa do tempo ata o primeiro byte e da velocidade sostida dunha conexión, e o terceiro mide o rendemento agregado con catro fluxos paralelos. Execútaos contra o mesmo destino á mesma hora do día, porque comparar unha mostra da mañá cunha da noite produce unha historia en lugar dunha medición.

Mantén o destino fixo cando compares saídas. Cambiar tanto o servidor como o túnel converte unha variable en dúas, e o resultado non pode dicirche cal importou. Executa cada saída polo menos tres veces, porque unha soa mostra adoita caer durante un cambio de encamiñamento ou nun minuto ruidoso. A mediana é máis útil que o mellor caso.

Trata o ICMP como unha pista e non como a resposta. Un host que responde pode xestionar as solicitudes de eco por un camiño distinto do que usa a túa aplicación, e unha resposta perdida non é proba de que todas as aplicacións estean perdendo paquetes.

A latencia baixo carga é un problema de colas

O patrón que máis confunde á xente é unha conexión que se sente ben en repouso e resulta inservible durante unha copia de seguridade. Iso son colas, non capacidade. Unha ligazón de subida saturada constrúe un búfer diante de cada outro paquete, así que unha pulsación de tecla espera detrás dun anaco da subida.

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

O primeiro comando mostra a latencia en segundo plano mentres o segundo satura a dirección inversa. Se os tempos de ping saltan durante a transferencia e se recuperan despois, reproduciu bufferbloat en lugar de descubrir un fallo de encamiñamento. A solución adoita ser un axuste de xestión de colas, unha velocidade de fondo máis baixa ou sacar a transferencia masiva do camiño interactivo.

Reducir o tráfico de fondo opcional adoita axudar máis que cambiar de país de saída. Tamén é máis barato, reversible e comprobable nun minuto. Programa as subidas grandes fóra do horario laboral se a cola non se pode xestionar, e limita a súa velocidade se deben funcionar de día. Un axuste de xestión de colas é a mellor solución cando o router admite un.

Cambia unha cousa e compara o igual co igual

Para un atraso alto en repouso, compara saídas mantendo o destino fixo e despois compara rutas para o mellor candidato. Para un rendemento baixo e estable, mira en cambio a capacidade, a carga do servidor e o procesamento do cliente, porque son límites distintos.

Anota que mediste, contra que destino, a que hora e con que axustes. Unha comparación sen eses catro feitos non se pode repetir, e a seguinte persoa comezará de cero.

Despois axusta a ferramenta á afirmación do ticket. "Internet lento" non é unha medición; "o primeiro byte tardou 900 ms ata este host mentres o rendemento era bo" si o é, e apunta directamente ao atraso e non á capacidade.