Meça você mesmo
Cada número de latência neste site vem de nossas próprias sondas, que é exatamente o tipo de afirmação que você não deve aceitar por confiança. O looking glass roda em todos os 34 sites, não precisa de conta, e responde à única pergunta que importa: como é o caminho entre você e essa cidade agora mesmo?
Montar o comando
Escolha um site e uma ferramenta. Eles são executados na sua máquina, contra nossos hosts de teste publicados, que é a única medição que diz algo sobre o seu próprio caminho.
mtr -rwzbc 100 lg-ams-01.paragonvps.comUm arquivo de 1 GB de dados aleatórios incompressíveis, para medir a taxa de transferência em vez do seu compressor.
Execute cada um desses três vezes em horários diferentes antes de tirar uma conclusão. Um único traceroute durante a janela de manutenção de outra pessoa não é evidência.
O que é, e o que não é
Um host de sonda em cada site, na mesma VLAN da produção, atrás da mesma filtragem.
O looking glass é um pequeno host em cada site que executa testes em seu nome e imprime a saída bruta. Ele fica na mesma rede que as instâncias dos clientes e atrás da mesma filtragem de borda, então o que mede é o que você obteria. Sem caminho de teste otimizado, sem uplink separado, sem canto silencioso do rack.
Não é um benchmark e não é uma ferramenta de marketing. Alguns resultados são desfavoráveis: Sydney para qualquer lugar é caro em milissegundos, e Joanesburgo ainda está estabilizando seu trânsito. Esses números estão lá porque escondê-los seria inútil quando qualquer um pode executar o teste.
Todos os 34 sites, o tempo todo
Incluindo sites de pré-venda. Joanesburgo responde a sondas desde antes de ter uma única instância paga nele.
Sem conta, sem cadastro
Consistente com o resto do serviço. O único teste que exige algo de você é o iperf3, e isso precisa de um token puramente para evitar que a máquina seja usada como fonte de inundação.
Limitado, deliberadamente
Um teste por vez por endereço de origem e quatro testes por minuto. Um looking glass é um vetor de amplificação adorável se o operador não pensou nisso.
Os resultados são seus
A saída é texto simples com um link permanente que dura trinta dias. Cole-o em um ticket, ou em uma discussão com a equipe de rede de outra pessoa.
O que você pode executar
Cinco testes, escolhidos porque respondem a perguntas diferentes. Executar todos eles prova pouco; escolher o certo geralmente resolve a questão em um minuto.
Comece com MTR, não com ping
Um único ping informa sobre um único momento. Trezentos ciclos de MTR informam se o caminho está ruim, ocasionalmente ruim ou se está bom e você apenas deu azar.
Use primeiro o arquivo de teste para throughput
Um download de 1 GB via HTTPS reproduz o que a maioria das workloads reais faz. Se isso está lento, mas o iperf3 está rápido, o problema é controle de congestionamento ou middleboxes, não capacidade.
Vale a pena gastar noventa segundos com Path MTU
Uma parcela surpreendente de chamados de “o site carrega, mas uploads grandes travam” termina aqui, geralmente em um túnel esquecido entre você e nós.
| Teste | A pergunta que ele responde | Limites |
|---|---|---|
| Ping ICMP | Está acessível e qual é o round trip agora | Até 100 pacotes por execução |
| Traceroute (ICMP e UDP) | Quais saltos o caminho de ida faz saindo desse site | Máximo de 30 saltos, 3 sondas por salto |
| MTR | Perda e latência por salto ao longo do tempo em vez de em um instantâneo | Até 500 ciclos, cerca de 8 minutos |
| Alvo iperf3 | Qual throughput você pode realmente obter para esse site | Token do painel, 60 segundos, até 4 fluxos |
| Arquivo de teste | Uma resposta de throughput sem instalar nada | 100 MB e 1 GB por HTTPS |
| Sonda MTU do caminho | Se algo no meio está comendo pacotes grandes | Reporta o maior tamanho que sobrevive |
Lendo a saída sem lê-la errado
A saída do traceroute não é uma imagem do seu tráfego. É um conjunto de respostas de roteadores que tinham coisas melhores para fazer, e lê-la como se fosse um gráfico de latência produz conclusões confiantes e erradas.
A maioria das reclamações de roteamento que recebemos está correta sobre o sintoma e errada sobre o salto.
Saltos intermediários exageram
Um roteador que responde a uma sonda de traceroute está fazendo isso no seu plano de controle, que está ocupado e trata o ICMP como a menor prioridade. Quando um salto mostra 180 ms e o próximo mostra 14 ms, aquele roteador estava ocupado, não o caminho à sua frente.
Apenas a última linha é real
Perda que aparece no salto seis e desaparece no sete é resposta limitada por rate-limit, não tráfego perdido. Quando começa no salto seis e continua até o destino, envie-nos a saída.
O DNS reverso é uma dica
Códigos de aeroporto em nomes de saltos frequentemente estão defasados em anos. Trate-os como uma indicação da intenção de quem nomeou a interface, nunca como evidência de geografia.
O MPLS esconde o meio do caminho
Caminhos que cruzam um núcleo com comutação por rótulos podem parecer três saltos mais curtos do que são. A latência ainda está lá; só falta a honestidade sobre de onde ela veio.
A física define o piso
Amsterdã a Singapura é cerca de 168 ms e nenhuma quantidade de peering vai melhorar isso de forma significativa. Se sua medição estiver próxima do nosso número publicado, o caminho está funcionando corretamente e a resposta é um segundo site, não um chamado.
Rotas assimétricas, onde mora a confusão
Um traceroute mede o caminho de ida e nada mais. No entanto, cada número nele inclui a viagem de volta da resposta daquele salto, e a viagem de volta pode seguir uma rota completamente diferente pelo planeta.
O tráfego de nós para você e o tráfego de você para nós são decisões separadas tomadas por redes separadas. Nós escolhemos o que sai; as redes no meio escolhem o que volta. A maioria dos operadores entrega o tráfego na primeira oportunidade, então seu caminho de volta frequentemente deixa seu provedor em uma cidade diferente daquela onde nosso caminho entrou.
A consequência visível é um salto que parece lento enquanto seu tráfego real está bem. A pior é a invisível: congestionamento no caminho de volta aparece como latência que você passará uma tarde procurando na direção de ida.
Sempre meça as duas direções
MTR da sua máquina até a instância, e MTR do looking glass naquele site de volta ao seu endereço, idealmente ao mesmo tempo. Metade das evidências produz metade da resposta.
Assimetria por si só não é uma falha
Quase todo caminho na internet é assimétrico e quase todos funcionam. Isso se torna um problema apenas quando uma direção está congestionada, descartando pacotes ou cruzando um filtro com estado.
Só podemos influenciar o que retorna
Nossa política de roteamento controla diretamente a direção de saída. O caminho de volta muda apenas se anunciarmos de forma diferente, entregarmos em outro lugar ou pedirmos educadamente a um peer. As três coisas são possíveis; nenhuma é instantânea.
Middleboxes com estado odeiam assimetria
Se você executa um firewall que espera ver as duas direções do fluxo e o caminho de retorno deixa de atravessá-lo, você terá redefinições intermitentes que parecem exatamente uma falha de rede. Verifique isso antes de culpar alguém.
Abrindo uma reclamação de roteamento que é atendida
A primeira resposta mediana em um ticket é de 11 minutos. Uma correção de roteamento leva mais tempo, porque outra pessoa precisa concordar.
- 01
Descarte sua própria instância
Verifique carga, rastreamento de conexões, contadores de interface da própria instância e se alguma regra de filtragem sua está descartando tráfego. Algo como um em cada cinco relatos termina aqui, e termina mais rápido se você verificar primeiro.
- 02
Colete as duas direções
Pelo menos 300 ciclos de MTR do seu lado e 300 do looking glass naquele site, executados na mesma janela. Anexe o permalink em vez de um screenshot; precisamos dos números, não de uma imagem deles.
- 03
Marque o horário corretamente
UTC ou um offset explícito. “Esta manhã” descreve um momento para você e uma faixa de onze horas para nós, e correlacionar dados de fluxo com isso é adivinhação.
- 04
Diga o que mudou e quando
Sempre foi assim, ou começou na terça. Contínuo, ou entre 20:00 e 23:00 locais. Essa única frase geralmente decide se estamos olhando para uma mudança de peering ou para o congestionamento noturno de alguém.
- 05
Envie para o suporte
Envie para [email protected] ou abra um ticket no painel. Qualquer coisa que se revele um problema real de caminho é escalada para a equipe de rede na mesma hora, e você é informado sobre o que pedimos à outra rede.
O que podemos fazer: re-rotear, depreciar um trânsito, pedir a um peer que investigue, ou mover você para um site com melhor rota. Congestionamento dentro de uma rede que não tocamos está além de todas as quatro opções, e nesse caso roteamos você ao redor do problema em vez de gastar uma semana tentando estar certos.
Perguntas sobre o looking glass
Por sessenta segundos por vez, sim. O token existe para evitar que o host se torne uma fonte de inundação para alguém, não para racionar medições honestas. Testes prolongados querem sua própria instância em ambas as extremidades.
Não deveria, e se mostrar, gostaríamos de saber. O host de sonda fica na mesma VLAN e herda a mesma política. Uma diferença genuína geralmente significa uma política por prefixo aplicada ao seu endereço, o que vale um ticket.
Não no looking glass público. Peça em um ticket com um prefixo específico e um motivo, e você receberá a resposta, incluindo qual upstream estamos preferindo para ele e por quê.
Dentro dos limites de taxa, sim; os testes são de saída e inofensivos nesse volume. Usá-lo como fonte de medição para um alvo que você não controla é aceitável. Como componente de algo maior, não é.
Trinta dias, depois expiram junto com a saída armazenada. Anexe-o a um ticket enquanto ainda resolve, ou cole o texto, o que preferimos de qualquer forma.
Execute o teste, depois escolha a cidade
A latência que você mediu é melhor do que a latência publicada por alguém. Depois que os números fizerem sentido, o índice de localizações tem o estoque, o uplink e a capacidade de filtragem para cada site.