High latency for Apps V2

Questions / Help
1

Hi,

I am new to fly.io and I have recently deploy a Fly app to production that runs an Express.js server. I am confused with the high latency my API request and when debugging using Fly built-in Grafana dashboard and I found that it’s routing via a region that’s I’m not setting my app to run with (ref image). I have set the instance to run in sin region but the http request is done via ams region.

Screenshot 2023-06-02 at 1.35.26 PM
Screenshot 2023-06-02 at 1.35.26 PM2776×860 136 KB

For reference, this is my fly.toml

app = "myapp"
primary_region = "sin"

[env]
  PORT = "8000"

[http_service]
  internal_port = 8000
  force_https = true

Appreciate if anyone can help in understanding how I can configure Fly to always route using sin region.

1 Like
2

Hi @pebbletech! My guess is that this is not an issue with your configuration. Rather, it appears that when you connect to Fly.io IP addresses, your internet service provider is sending the traffic to the ams region as opposed to a closer one. Our proxy in ams then has to forward your requests all the way back to the running instance of your app in sin.

(You can also check the fly-request-id HTTP header on responses from your API. The region code at the end of it is the region where your request was received. I suspect that it will be ams.)

Unfortunately, this kind of thing happens with some frequency, but we can sometimes adjust the routing information that we announce to get ISPs to pick better routes. If you’re comfortable providing any information about your location/ISP or sharing traceroute output from your location to your app (like in the first thread I linked to above), we may be able to look into it.

1 Like
3

Hey @MatthewIngwersen

Here’s my traceroute to my app.

traceroute to vesta-be.fly.dev (66.241.125.89), 64 hops max, 52 byte packets
 1  10.33.208.1 (10.33.208.1)  9.557 ms  4.804 ms  4.698 ms
 2  202.190.50.1 (202.190.50.1)  5.590 ms  6.166 ms  4.422 ms
 3  * * *
 4  223.28.43.254 (223.28.43.254)  46.251 ms  46.279 ms  52.362 ms
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
31  * * *
32  * * *
33  * * *
34  * * *
35  * * *
36  * * *
37  * * *
38  * * *
39  * * *
40  * * *
41  * * *
42  * * *
43  * * *
44  * * *
45  * * *
46  * * *
47  * * *
48  * * *
49  * * *
50  * * *
51  * * *
52  * * *
53  * * *
54  * * *
55  * * *
56  * * *
57  * * *
58  * * *
59  * * *
60  * * *
61  * * *
62  * * *
63  * * *
64  * * *

I am currently in Malaysia, Kuala Lumpur and all of my users are in the same region. I am running this traceroute from my ISP “TTNET-MY” (TT DOTCOM SDN BHD) and I suppose majority of my users either using TTNET-MY or TM (https://www.tm.com.my/) .

Here’s the statistic of my app from Grafana for the past 7 days. Most of the traffic still route to HKG and occasionally to SIN and NRT.

image

SIN is objectively faster compare the other 2 regions but I still wonder why it’s still not routing to this region.

image

Would be great if you can help us in getting this work with SIN region as latency difference is around 100ms in comparison.

4

To temporarily worked around this for IPv6, iff your app is not reliant on Fly’s HTTP/TLS handler (proxy), you can setup the DNS AAAA record to point to your Machine’s IPv6 address which doesn’t change across deploys.

fly ssh console -A <fly-private-ip> -a <appname> -C 'printenv FLY_PUBLIC_IP'

Another temporary workaround may be to host Machine in another region closer to the Malaysian peninsula: HKG / NRT / MAA / BOM.

5

I am currently using the default domain with *.fly.dev. . How do I configure the DNS in this case?

Edit: Are you saying to bypass this we should use AAAA record instead of CNAME for custom domain?

6

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.