So, i’ve been trying to figure out why there’s a added 200ms latency when i connect to my Fly Postgres DB from outside the Fly network, using a different VPS provider in the same region (FRA) as where my Fly DB is. When using a Fly machine the query runs at 10-30ms (targetting .internal), when I run the same query from outside Fly, it runs at 240-250ms. It’s a simple query that returns 30 rows with some minor data. Nothing fancy.
I expect some additional latency, but an added 200ms? Really? Am I missing something here? I would still expect sub 100ms to be honest.
Running the same query from my local machine (AMS) region, the added latency is about the same.
Trying to figure out if this is what to expect, or there’s a underlying issue here.
Thanks for the links. It seems to go through Paris, France. But is it really adding that much latency? I’m getting a consitent 200ms difference between my Fly PG and the external VPS, compared to my Fly Machine talking directly to the Fly PG.
Your traceroute screenshot shows ~13ms latency which is much less than 200. So something else must be going on internal to your app to make those numbers add up. Is your app doing something like looping through 15 serialized queries (N+1) for each request?
@wjordan thanks for pointing that out. That got me thinking.
I tried switching out my db driver. I’m using Node and was using postgres (postgres.js). When switching it out for node-postgres i already saw a decrease in latency. I even decreased it further by properly setting up connection pooling. i’m now getting 50-60ms - between my VPS and Fly PG - when there are connections in the pool. And now even sub 10ms on the local connection between Fly machines.
I guess the local connection between my Fly Machine (API) and Fly PG (DB) was so fast i didn’t even notice i actually needed proper connection pooling.
