Como escolher a localização de um VPS para baixa latência

As pessoas passam horas comparando números de vCPU e depois colocam o servidor no continente errado. Para tudo que é interativo (um shell, uma API, um jogo, um bot conversando com uma exchange), a localização muitas vezes importa mais que o hardware. A boa notícia: latência é principalmente física, então dá para prever e medir antes de pagar.

A física numa linha

A luz na fibra óptica viaja cerca de 200 km por milissegundo. Os cabos não correm em linha reta e cada roteador acrescenta um pouco, então uma boa regra prática é cerca de 1 ms de ida e volta a cada 100 km de distância real.

Nenhuma quantidade de CPU resolve uma ida e volta de 200 ms. Se os seus usuários estão em Tóquio, um servidor na Alemanha vai parecer lento por mais rápido que seja.

O que significa «perto» depende do trabalho

Um site ou uma API. Perto da maioria dos seus usuários. Uma CDN esconde a distância dos arquivos estáticos, mas a primeira resposta HTML, os logins, as chamadas de API e tudo que é dinâmico continuam viajando até a origem.

Um bot de trading. Perto dos servidores de API da exchange, não de você. Onde você está é irrelevante; o bot conversa com a exchange centenas de vezes por dia. Para arbitragem, cada poucos milissegundos contam; para um bot que envia um punhado de ordens por dia, 30 ms não fazem diferença. Mais em VPS de baixa latência para bots de trading.

Um agente de IA que chama APIs de modelos. A localização quase não importa. Um modelo leva segundos para responder; 30 ms de rede são ruído. Escolha por preço e privacidade.

Um servidor de jogos. Perto dos jogadores. Abaixo de ~60 ms a maioria dos jogos vai bem; jogos de tiro competitivos querem muito menos.

Área de trabalho remota e SSH. Perto de você. Digitar com 150 ms de latência é um sofrimento.

Meça você mesmo

Da sua própria máquina, ou de um servidor perto dos seus usuários, verifique o caminho até uma localização candidata:

mtr -rwc 50 example.com

O mtr mostra cada salto com perda e latência: muito mais útil que um ping isolado, porque revela onde o atraso é adicionado.

A partir de um VPS, meça o serviço do qual você realmente depende, dividido por fase:

curl -o /dev/null -s -w 'dns %{time_namelookup}s  connect %{time_connect}s  tls %{time_appconnect}s  total %{time_total}s\n' \
  https://api.example.com/health

connect é mais ou menos uma ida e volta de rede, tls acrescenta o handshake e total inclui o tempo de processamento do próprio servidor. Se connect dá 2 ms e total 900 ms, o seu problema não é a distância.

Onde a EQVPS se encaixa

Os nossos servidores ficam na Alemanha e na Finlândia, e você escolhe a localização a cada pedido. Isso atende bem usuários em toda a Europa, razoavelmente o Oriente Médio, e muito bem as exchanges e os endpoints de API europeus. A Finlândia fica alguns milissegundos mais longe da Europa Ocidental e um pouco mais perto dos países nórdicos e bálticos; para a maioria das cargas, qualquer uma serve.

Com sinceridade: não temos localizações na Ásia nem nas Américas. Se é lá que estão os seus usuários, um servidor na Europa adiciona 80–250 ms a cada ida e volta, e você deveria hospedar mais perto deles.

A versão curta

1. Decida com quem o servidor mais conversa: usuários, uma exchange, uma API, você.
2. Coloque-o perto disso, usando ~1 ms a cada 100 km como estimativa.
3. Meça com mtr e curl -w em vez de confiar num mapa.
4. Não pague por uma CPU mais rápida para resolver um problema de distância.

Se você está escolhendo entre um plano NAT e um com IP dedicado para a mesma máquina, essa é outra questão: aqui está o teste de uma pergunta só.