Hi all, relatively new fly.io user here and was wondering where best to deploy my app, hence the title: how find the nearest/fastest region to setup app, thanks!
Do you mean nearest to you?
If so, when you do fly launch, I think it suggests the nearest region by default.
I don’t think so, fly launch gives a list of regions
This is probably just a coincidence, but fly version 0.1.84, it gives me a list of regions, but has selected otp by default, which is nearest to me.
That’s interesting! What’s highlighted by default is amsterdam but I am in asia (philippines) though
I used a VPN to connect to US, but I also got Amsterdam.
When I connected to Japan, I got Tokyo, which was okay.
Sorry I couldn’t help more, but hope somebody from the Fly team gets to this soon.
Thanks anyways! I actually tried singapore and hk and both were still slow like (300-700ms) for a hello world go app right now im settling with france (kinda weird it’s faster?) but yeah hope fly.io team can help me figure out what’s the best way to setup deployments, cheers!
Hey @vasallius and @redjonzaci—the default region in flyctl prompts is the region that your ISP sends your traffic to, which is determined by whatever your ISP considers the “best” path to the Fly.io network. That “best” path is decided by a fairly complicated process, and while it often leads to the Fly.io region closest to you geographically (or with the best ping times), that’s not always the case.
@vasallius you can visit debug.fly.dev and check the Fly-Region header printed there to verify that you’re being routed to ams. (Amsterdam is a significant Internet hub, so I wouldn’t be surprised to see traffic getting sent there. Here’s another example of that happening.)
If you’re able to provide a traceroute to debug.fly.dev, we can sometimes work with our network providers to try to improve the routing.
1 Like
Hi Matthew, thanks for the reply!
Here’s my debug.fly.dev, I’m assuming the best region is indeed france? (cdg)
So if 99% of my users are gonna be in the Philippines is it better to just spend all the free VMs (3) on that region? Instead of say spreading 1 VM across the top 3 nearest regions? I would really want to avoid cold starts as well, do you have any tips for this? I run a compute heavy api, thanks!
Since it’s probably difficult to determine ahead-of-time exactly what regions your customers’ traffic will be sent to—e.g. different ISPs in the Philippines might route traffic to different spots—I might suggest starting with the three in cdg and then taking an experimental approach to adjusting it.
We have some built-in metrics accessible through your app’s dashboard and through a managed Grafana instance. You can use some of these to determine what regions customer traffic is hitting. In particular, you can check the “Edge” column of the “Data out” table in the Grafana “Fly App” dashboard. You can also try the following query using the Grafana “Explore” page, which will give you a graph of the number of HTTP responses sent through each region over time:
sum by (region) (fly_edge_http_responses_count)
Based on these, you can adjust the regions of your VMs to match over time.
To keep your Machines running all the time (so that they don’t have to start up when a request arrives), you can set auto_stop_machines = false in the appropriate service or http_service section of your fly.toml. Generally speaking you’d be charged for them running all the time then, but if you’re within the free-tier limits then this won’t matter.
(I might be misunderstanding what you mean by “cold starts”; if so, please let me know!)
Thanks for this! I’ve tried turning auto_stop_machines = false and having min_machines_running = 1 but the 1st call to the api is always relatively slower, would this be considered as a cold start?
Ah, okay! I might need you to clarify what you mean by the “first” call here, but off the top of my head:
Do you mean the first call on a particular connection (i.e., does your client reuse an existing connection for subsequent requests)? If so, perhaps you’re observing the additional time required to connect to the API (for the TCP handshake, TLS handshake, and possibly DNS resolution)?
Something like this (left: before, right: after)
i expected that the api would always ~1000ms but the “first” calls are always slow like 3-5s, is this a cold start? I’m not well versed with networking so would really want to understand what’s happening
So in the “before” graph it does look like connection setup is taking about a second to complete, but it’s not enough to account for the entire difference. The “transfer start” bars indicate that most of the extra time is the client waiting for the first byte of the response.
It’s always possible that something unusual is happening with the network, but the most probable explanation is that your app itself is taking longer to process the request on the left than on the right. That does seem like some kind of cold start problem.
Have you tried profiling/timing your API on the server side?
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.