Postgres: Saiba como descobrir qual região da Vercel tem a melhor latência para sua aplicação
Se você já criou um banco de dados Postgres dentro da Vercel, deve ter percebido que se trata de uma integração entre a Neon (neon.tech) e a Vercel. O processo de criaçao é simples, mas você pode ter se deparado com a seguinte dúvida na hora de subir seu banco: qual região escolher?
As opções de região são as abaixo, e apesar de ser óbvio que escolher um servidor nos EUA te trará menor que latência no Brasil que escolher um em Frankfurt (Alemanha), ainda fica a dúvida: qual das três opções nos EUA seria a melhor?
Bem, foi aí começou meu processo de investigação. Fazendo uma busca rápida no Google, é possível achar neste link, onde a Neon aloca alguns de seus recursos (veja depois se quiser).
São data centers (DCs) da AWS, e apersar dos nomes dos DCs da Neon não baterem com os da AWS (lista abaixo), se você pesquisar os locais, verá que a Neon na verdade optou por nomear suas regiões usando os nomes das cidades, onde se encontram os DCs, enquanto a Amazon optou pelos estados!
AWS - US East (N. Virginia) — aws-us-east-1 ---> Neon - Washington, D.C., USA - (iad1)
AWS - US East (Ohio) — aws-us-east-2 ---> Neon - Cleveland, USA - (cle1)
AWS - US West (Oregon) — aws-us-west-2 ---> Neon - Portland, USA - (pdx1)
Feito o reconhecimento de em qual data center da AWS seu banco da Neon será levantado, o próximo passo é descobrir a latência entre sua aplicação e os DCs da AWS.
Graças ao bom Pai (e a algum bom funcionário da AWS) a Amazon mantém uma lista de endereços públicos para você testar a comunicação com seus DCs, eu até fiz uma postagem no meu blog com a relação completa deles mas vou deixar a lista para os três DCs que a Neon usa a seguir também:
Para testar, execute um PING da sua aplicação para os endereços abaixo:
Neon - Washington, D.C., USA - (iad1) ---> ping ec2.us-east-1.amazonaws.com
Neon - Cleveland, USA - (cle1) ---> ping ec2.us-east-2.amazonaws.com
Neon - Portland, USA - (pdx1) ---> ping ec2.us-west-2.amazonaws.com
Aqui estão os resultados do teste a partir do servidor Linux da minha aplicação no Brasil. E já dou o spoiler que para o Brasil geralmente a menor latência é sempre de N. Virginia, que tem boas rotas para cá.
--- ec2.us-east-1.amazonaws.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 148.876/194.751/239.943/29.578 ms
--- ec2.us-east-2.amazonaws.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9011ms
rtt min/avg/max/mdev = 190.361/230.291/272.651/27.946 ms
--- ec2.us-west-2.amazonaws.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 227.054/280.382/315.725/33.063 ms
Dica final: caso você não tenha acesso ao terminal de comando do seu servidor, você pode tentar executar um PING através da sua aplicação.
