O seu download é rápido, então porque é que cada clique parece lento?

Descarregar rapidamente um ficheiro grande e depois achar cada clique lento não é uma contradição. A capacidade diz quanto pode avançar por segundo; o tempo de ida e volta diz quanto dura uma troca antes de acontecer algo útil. Melhorar o primeiro não faz nada pelo segundo, e o segundo é o que uma pessoa nota enquanto escreve, clica ou fala. Meça a queixa, não a ligação.

Ficheiro rápido, clique lento: dois números diferentes

Uma transferência em massa mantém os dados em movimento contínuo, por isso pode reportar uma velocidade saudável mesmo quando cada pedido individual espera. Muitos testes também abrem várias ligações ao mesmo tempo, o que aumenta o número agregado enquanto um pedido continua lento. Os dois resultados são compatíveis, e citar o mais alto a um utilizador que se queixa de atraso é como se perde a confiança.

O carregamento de uma página é uma cadeia de pequenas trocas: resolução de nomes, estabelecimento da ligação, um pedido, uma resposta e depois pedidos dependentes. Cada passo paga novamente a ida e volta, por isso um caminho com muito atraso parece lento mesmo quando tem capacidade de sobra.

O túnel acrescenta a sua própria viagem e processamento, e a rota importa mais do que a etiqueta num mapa. Duas saídas no mesmo país podem ter caminhos muito diferentes até um destino. Uma diferença de vinte milissegundos basta para mudar a sensação de uma página, embora quase não mexa num número de débito. Por isso a escolha da saída deve seguir uma amostra de latência e não um ícone de bandeira.

Meça a queixa, não a ligação

Escolha a medição que corresponde à frase que o utilizador disse. Um download lento precisa de uma velocidade sustentada na direção certa; uma chamada com falhas precisa das estatísticas da própria aplicação; uma página que arranca devagar precisa dos tempos de resolução e de estabelecimento.

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á uma amostra de ida e volta até um anfitrião que responde de forma previsível, o segundo reporta o tempo até ao primeiro byte e a velocidade sustentada de uma ligação, e o terceiro mede o débito agregado com quatro fluxos paralelos. Execute-os contra o mesmo destino à mesma hora do dia, porque comparar uma amostra da manhã com uma da noite produz uma história em vez de uma medição.

Mantenha o destino fixo quando compara saídas. Mudar tanto o servidor como o túnel transforma uma variável em duas, e o resultado não lhe pode dizer qual foi importante. Execute cada saída pelo menos três vezes, porque uma amostra única cai muitas vezes durante uma mudança de encaminhamento ou um minuto ruidoso. A mediana é mais útil do que o melhor caso.

Trate o ICMP como uma pista e não como a resposta. Um anfitrião que responde pode tratar os pedidos de eco por um caminho diferente do que a sua aplicação usa, e uma resposta perdida não é prova de que todas as aplicações estejam a perder pacotes.

A latência sob carga é um problema de filas

O padrão que mais confunde as pessoas é uma ligação que parece boa em repouso e inutilizável durante uma cópia de segurança. Isso é fila, não capacidade. Uma ligação de subida saturada constrói um buffer à frente de cada outro pacote, por isso uma tecla espera atrás de um pedaço do envio.

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

O primeiro comando recolhe amostras da latência em segundo plano enquanto o segundo satura a direção inversa. Se os tempos de ping saltarem durante a transferência e recuperarem depois, reproduziu o bufferbloat em vez de descobrir uma falha de encaminhamento. A correção costuma ser uma definição de gestão de filas, uma velocidade de fundo mais baixa ou tirar a transferência em massa do caminho interativo.

Reduzir o tráfego de fundo opcional ajuda muitas vezes mais do que mudar de país de saída. Também é mais barato, reversível e testável num minuto. Agende os envios grandes fora do horário de trabalho se a fila não puder ser gerida, e limite a velocidade se tiverem de correr durante o dia. Uma definição de gestão de filas é a melhor correção quando o router suporta uma.

Mude uma coisa e compare o igual com o igual

Para um atraso elevado em repouso, compare saídas mantendo o destino fixo e depois compare rotas para o melhor candidato. Para um débito baixo e estável, olhe antes para a capacidade, a carga do servidor e o processamento do cliente, porque são limites diferentes.

Anote o que mediu, contra que destino, a que hora e com que definições. Uma comparação sem estes quatro factos não pode ser repetida, e a pessoa seguinte começará do zero.

Depois ajuste a ferramenta à afirmação do ticket. "Internet lento" não é uma medição; "o primeiro byte demorou 900 ms até este anfitrião enquanto o débito estava bom" é uma, e aponta diretamente para o atraso e não para a capacidade.