No momento, estamos tentando decidir se devemos mover nosso datacenter da costa oeste para a costa leste.
No entanto, estou vendo alguns números de latência perturbadores da minha localização na costa oeste até a costa leste. Veja um exemplo de resultado, recuperando um pequeno arquivo de logotipo .png no Google Chrome e usando as ferramentas de desenvolvimento para ver quanto tempo leva a solicitação:
- Costa oeste para costa leste:
latência de 215 ms, tempo de transferência de 46 ms, total de 261 ms - Costa oeste para costa oeste:
latência de 114 ms, tempo de transferência de 41 ms, total de 155 ms
Faz sentido que Corvallis, OR esteja geograficamente mais próximo da minha localização em Berkeley, CA, então espero que a conexão seja um pouco mais rápida. servidor. Isso me parece... excessivo. Especialmente porque o tempo gasto na transferência dos dados reais aumentou apenas 10%, mas a latência aumentou 100%!
Isso parece... errado... para mim.
Encontrei alguns links aqui que foram úteis (pelo Google nada menos!) ...
- A distância de roteamento afeta significativamente o desempenho?
- Como a geografia afeta a latência da rede?
- Latência nas conexões de Internet da Europa para os EUA
... mas nada autoritário.
Então, isso é normal? Não parece normal. Qual é a latência "típica" que devo esperar ao mover pacotes de rede da costa leste <--> costa oeste dos EUA?
Velocidade da Luz:
Você não vai superar a velocidade da luz como um ponto acadêmico interessante. Este link funciona de Stanford para Boston no melhor tempo possível de ~40ms. Quando essa pessoa fez o cálculo, decidiu que a internet operava a cerca de "dentro de um fator de dois da velocidade da luz", então há cerca de 85ms de tempo de transferência.
Tamanho da janela TCP:
Se você estiver tendo problemas de velocidade de transferência, pode ser necessário aumentar o tamanho tcp da janela de recebimento. Você também pode precisar habilitar o dimensionamento de janela se esta for uma conexão de alta largura de banda com alta latência (chamada de "Long Fat Pipe"). Portanto, se você estiver transferindo um arquivo grande, precisará ter uma janela de recebimento grande o suficiente para preencher o tubo sem ter que esperar pelas atualizações da janela. Entrei em alguns detalhes sobre como calcular isso na minha resposta Tuning an Elephant .
Geografia e Latência:
Um ponto de falha de alguns CDNs (Content Distribtuion Networks) é que eles igualam latência e geografia. O Google fez muitas pesquisas com sua rede e encontrou falhas nisso, eles publicaram os resultados no white paper Moving Beyond End-to-End Path Information to Optimize CDN Performance :
BGP Peerings:
Além disso, se você começar a estudar o BGP (core internet routing protocol) e como os ISPs escolhem os peerings, descobrirá que geralmente é mais sobre finanças e política, portanto, nem sempre você pode obter a 'melhor' rota para determinadas localizações geográficas, dependendo no seu ISP. Você pode ver como seu IP está conectado a outros ISPs (Sistemas Autônomos) usando um roteador de espelho . Você também pode usar um serviço whois especial :
Também é divertido explorá-los como peerings com uma ferramenta de gui como linkrank , que fornece uma imagem da Internet ao seu redor.
Este site sugere cerca de 70-80ms de latência entre a costa leste/oeste dos EUA é típica (San Francisco a Nova York, por exemplo).
Aqui estão meus horários (estou em Londres, Inglaterra, então meus tempos na costa oeste são mais altos que no leste). Recebo uma diferença de latência de 74ms, que parece suportar o valor desse site.
Estes foram medidos usando as ferramentas de desenvolvimento do Google Chrome.
Meça com ICMP primeiro, se possível. Os testes ICMP normalmente usam uma carga útil muito pequena por padrão, não usam um handshake de três vias e não precisam interagir com outro aplicativo na pilha como o HTTP. Seja qual for o caso, é de extrema importância que os resultados HTTP não sejam misturados com os resultados ICMP. São maçãs e laranjas.
Indo pela resposta de Rich Adams e usando o site que ele recomendou, você pode ver que no backbone da AT&T, leva 72 ms para o tráfego ICMP se mover entre seus terminais SF e NY. Esse é um número razoável, mas você deve ter em mente que isso está em uma rede totalmente controlada pela AT&T. Não leva em consideração a transição para sua rede doméstica ou de escritório.
Se você fizer um ping em careers.stackoverflow.com da sua rede de origem, deverá ver algo não muito distante de 72 ms (talvez +/- 20 ms). Se for esse o caso, você provavelmente pode assumir que o caminho de rede entre vocês dois está bem e funcionando dentro dos intervalos normais. Se não, não entre em pânico e meça de alguns outros lugares. Pode ser seu provedor de internet.
Supondo que isso tenha acontecido, sua próxima etapa é lidar com a camada de aplicativo e determinar se há algo errado com a sobrecarga adicional que você está vendo com suas solicitações HTTP. Isso pode variar de aplicativo para aplicativo devido ao hardware, sistema operacional e pilha de aplicativos, mas como você tem equipamentos praticamente idênticos nas costas leste e oeste, você pode fazer com que os usuários da costa leste acessem os servidores da costa oeste e os usuários da costa oeste atinjam o leste costa. Se ambos os sites estiverem configurados corretamente, eu esperaria que todos os números fossem mais menos iguais e, portanto, demonstrasse que o que você está vendo é praticamente igual ao grosseiro.
Se esses tempos de HTTP tiverem uma grande variação, não ficaria surpreso se houvesse um problema de configuração no site com desempenho mais lento.
Agora, quando estiver nesse ponto, você pode tentar fazer uma otimização mais agressiva no lado do aplicativo para ver se esses números podem ser reduzidos. Por exemplo, se você estiver usando o IIS 7, você está aproveitando seus recursos de cache, etc.? Talvez você possa ganhar alguma coisa lá, talvez não. Quando se trata de ajustar itens de baixo nível, como janelas TCP, sou muito cético de que isso teria muito impacto para algo como o Stack Overflow. Mas ei - você não saberá até experimentar e medir.
Várias das respostas aqui estão usando ping e traceroute para suas explicações. Essas ferramentas têm seu lugar, mas não são confiáveis para medição de desempenho de rede.
Em particular, (pelo menos alguns) roteadores Juniper enviam o processamento de eventos ICMP para o plano de controle do roteador. Isso é MUITO mais lento que o plano de encaminhamento, especialmente em um roteador de backbone.
Existem outras circunstâncias em que a resposta ICMP pode ser muito mais lenta do que o desempenho real de encaminhamento de um roteador. Por exemplo, imagine um roteador totalmente de software (sem hardware de encaminhamento especializado) que está com 99% da capacidade da CPU, mas ainda está movendo o tráfego bem. Você quer que ele gaste muitos ciclos processando respostas de traceroute ou encaminhando tráfego? Portanto, processar a resposta é uma prioridade super baixa.
Como resultado, o ping/traceroute fornece limites superiores razoáveis - as coisas estão indo pelo menos tão rápido - mas eles realmente não informam o quão rápido o tráfego real está indo.
Em qualquer evento -
Aqui está um exemplo de traceroute da Universidade de Michigan (centro dos EUA) para Stanford (costa oeste dos EUA). (Acontece passar por Washington, DC (costa leste dos EUA), que fica a 500 milhas na direção "errada".)
Em particular, observe a diferença de tempo entre os resultados do traceroute do roteador de lavagem e do roteador atla (saltos 7 e 8). o caminho da rede vai primeiro para lavar e depois para atla. wash leva 50-100ms para responder, atla leva cerca de 28ms. Claramente atla está mais longe, mas seus resultados de traceroute sugerem que está mais perto.
Consulte http://www.internet2.edu/performance/ para obter muitas informações sobre medição de rede. (disclaimer, eu costumava trabalhar para internet2). Veja também: https://fasterdata.es.net/
To add some specific relevance to the original question... As you can see I had an 83 ms round-trip ping time to stanford, so we know the network can go at least this fast.
Note that the research & education network path that I took on this traceroute is likely to be faster than a commodity internet path. R&E networks generally overprovision their connections, which makes buffering in each router unlikely. Also, note the long physical path, longer than coast-to-coast, although clearly representative of real traffic.
michigan->washington, dc->atlanta->houston->los angeles->stanford
Estou vendo diferenças consistentes e estou sentado na Noruega:
Isso foi medido com o método científico preciso e comprovado de usar a visualização de recursos do Google Chrome e apenas atualizar repetidamente cada link.
Traceroute para serverfault
Traceout para carreiras
Infelizmente, agora ele começa a entrar em um loop ou outros enfeites e continua dando estrelas e tempo limite até 30 saltos e depois termina.
Observe que os traceroutes são de um host diferente dos horários no início, tive que fazer RDP no meu servidor hospedado para executá-los
everyone here has some really good point. and are correct in their own POV.
And it all comes down to there is no real exact answer here, because there are so many variable any answer given can always be proven wrong just by changing one of a hundred variables.
Like the 72ms NY to SF latency is the latency from PoP to PoP of a carrier of a packet. This does not take into account any of the other great points that some have pointed out here about congestion, packet loss, quality of service, out of order packets, or packet size, or network rerouting just between the perfect world of the PoP to PoP.
And then when you add in the last mile (generally many miles) from the PoP to your actual location within the two cities where all of these variable become much more fluid thing start to exponentially escalate out of reasonable guess-ability!
As an example I ran a test between NY city and SF of the course of a business day. I did this on a day were there was no major "incidents" occurring around the world that would cause a spike in traffic. So maybe this was not average in todays world! But nonetheless it was my test. I actually measured from one business location to another over this period, and during normal business hours of each coast.
At the same time, I monitored the circuit providers numbers on the web.
The results were latency numbers between 88 and 100 ms from door to door of the business locations. This did not include any inter office network latency numbers.
A latência das redes do provedor de serviços variou entre 70 e 80 ms. Ou seja, a latência da última milha pode ter variado entre 18 e 30 ms. Eu não correlacionei os picos e baixos exatos entre os dois ambientes.
Vejo latência de aproximadamente 80-90ms em links bem executados e bem medidos entre as costas leste e oeste.
Seria interessante ver onde você está ganhando latência - tente uma ferramenta como layer-four traceroute (lft). É provável que muito disso seja obtido na "última milha" (ou seja, em seu provedor de banda larga local).
É de se esperar que o tempo de transferência tenha sido levemente afetado - perda de pacotes e jitter são medidas mais úteis a serem observadas ao investigar diferenças de tempo de transferência entre dois locais.
Apenas por diversão, quando joguei o jogo online Lineage 2 NA lançado na Europa:
A diferença parece sustentar que até 100ms está dentro do razoável, considerando a natureza imprevisível da internet.
Usando o aclamado teste de atualização do Chrome, recebo um tempo de carregamento do documento que difere em aproximadamente 130 ms.
Horários de Nova York:
Usando o Chrome, em uma conexão residencial.
Usando lft de um VPS em um datacenter em Newark, Nova Jersey: