Devo me preocupar com o acesso rápido à Internet transatlântico para meus usuários?

Question

Obviamente, é apenas um fator no mix, mas se eu hospedar um site aqui no Reino Unido, sabendo que a maioria dos meus usuários está nos EUA, quanto peso devo dar à velocidade de acesso desses usuários? (Atualmente, cerca de 70% dos usuários dos EUA, 20% do Reino Unido, o restante está todo.) O lúpulo transatlântico costumava ser um grande negócio, mas é realmente um fator importante no mundo de hoje?

Mais uma vez, reconheço que este é apenas um fator no mix geral, apenas observando quanto peso a comunidade acha que eu deveria dar a ele.

(Antes de sugerir, usar uma das grandes CDNs / clouds - Amazon s3 + ec2, Google AppEngine etc. - não é uma opção no momento.)

EDITAR : Todas as respostas são bem vindas; quaisquer histórias de experiência direta com isso seriam especialmente úteis.

    

Answer 1

Havia problemas significativos com a latência e a taxa de transferência com links transatlânticos. Hoje em dia, embora a largura de banda disponível (supondo que seu provedor / provedor tenha arranjos de peering decentes) seja tal que a taxa de transferência não é realmente um problema na maioria dos casos.

A latência ainda pode ser um problema, mas apenas se o seu aplicativo for particularmente sensível à latência. Por exemplo, o tempo de ida e volta de pequeno pacote (ou seja, um pedido padrão de ping) entre as máquinas domésticas (on-line através de um bom ISP ADSL) e o servidor que tenho no estado (como tende a ser mais barato) é geralmente em torno de 100ms (às vezes fica em algo próximo de 120 por um tempo). Para a grande maioria dos serviços baseados na Web, esse nível de latência não será um problema.

    

Answer 2

Eu não daria muito peso ... EUA / Reino Unido não é um grande salto. Mesmo transpacífico não é um fator decisivo, desde que a rede do endpoint não esteja congestionada. Um provedor de rede sólido é muito mais importante do que exatamente onde você está localizado, em termos de fornecer uma boa experiência aos usuários do site.

    

Answer 3

Eles estão reclamando que é lento? Qual é a sua velocidade limite?

Você pode considerar a configuração de um servidor de proxy / cache do squid nos EUA ou a replicação do seu site para um servidor nos EUA, se realmente for um problema importante.

Mas eu não [pessoalmente] esperaria que isso importasse muito.

    

Answer 4

Como outros mencionaram, a questão da latência pode ser um fator. Nós tivemos problemas com um CRM e SharePoint em links com latência de menos de 100M, devido ao fato de que os aplicativos são muito "chatty" e fazem muitas viagens ao abrir páginas. A maioria dos sites nos é bastante local na América do Norte. Os aceleradores de WAN nos sites interromperam as chamadas e o desempenho é bom agora e não tivemos que obter conexões mais rápidas dos provedores.

    

Answer 5

A latência é um problema. Pageloads se sentirão lentos nas conexões mais rápidas. Verifique se você tem boa conectividade nos EUA e bons pings nos EUA. Isso ajudará se você estiver localizado nos data centers Chicago , New York ou California . Chicago ou Nova York sendo preferível se seus clientes NÃO estiverem na Ásia. Execute traceroutes. Isso realmente ajuda na escolha de um host. Traceroute para last.fm (um host europeu) e google.com.

Escolha um provedor em Londres, no Reino Unido, se precisar de conexão mais rápida nos Estados Unidos.