I was looking through the Docs, researching latency, performance, benchmarks, metrics, and I was considering doing a study (before production) on the cost-benefit relationship regarding the machine’s location with proximity. However, I couldn’t find much information. I know there’s Flyctl Ping, but it’s not very clear in the Docs how it works. I saw that it accesses the Gateway and can also access the applications, but it doesn’t show the trace. I also noticed that there are RTT measurements between the Edge and the Worker. I would like a guide or some orientation on how to properly conduct this basic study of costs and latency, the relationship between the two. I’m not sure if I’ll be able to find this. Any ideas?
1 Like
This would be an excellent addition to Fly’s official documentation, perhaps as an appendix or coda to their nascent/tentative decision outreach docs section.
In the meantime, here are a few tidbits that I’m using in my own (hobby, in this case) analysis…
1. The all-pairs RTT (round-trip times) chart is a great raw resource for understanding how much network latency would be added if you, say, placed a server in Los Angeles instead of Mexico City.
[Aside: You may have implied that you’ve seen this one already; I’ve highlighted it here, since it’s not widely advertized.]
2. In the other direction, the costs are available in JSON, if you dig into the source code of the pricing page:
const regionMarkups = {
"iad": 1,
"ewr": 1,
"ams": 1.038461538,
"arn": 1.038461538,
"bom": 1.076923077,
"mad": 1.096153846,
"yul": 1.115384615,
"yyz": 1.115384615,
"lhr": 1.134615385,
"cdg": 1.134615385,
"fra": 1.153846154,
"sjc": 1.192307692,
"lax": 1.199519231,
"atl": 1.25,
"bos": 1.25,
"ord": 1.25,
"dfw": 1.25,
"den": 1.25,
"mia": 1.25,
"phx": 1.25,
"sea": 1.25,
"sin": 1.269230769,
"syd": 1.269230769,
"jnb": 1.302884615,
"nrt": 1.307692308,
"otp": 1.326923077,
"waw": 1.326923077,
"gdl": 1.350961538,
"qro": 1.350961538,
"hkg": 1.403846154,
"bog": 1.615384615,
"gig": 1.615384615,
"gru": 1.615384615,
"scl": 1.697115385,
"eze": 1.858173077,
};
These are, sensibly enough, stated as fractional markups. E.g., a 1.35 means that qro will be 35% more expensive than NYC, starting in November.
The main missing piece is the relationship between latency and utility (benefit). This is application-dependent and generally not straightforward, but a useful starting point is to think of it in terms of what difference your particular users would notice. Can they really distinguish between 30 ms and 40 ms? Would it bother them?
Finally, if you haven’t encountered the broader concepts of Pareto Optimality and the formal “facility location” problem (from Operations Research), those are both foundational topics, in their different ways.
Anyway, this skipped many important factors (like shared vs. dedicated CPUs and pre-purchased discount blocks), but I didn’t want to leave this question completely hanging either…
Hope this helps a little!
3 Likes
About the RTT, I knew about it, although… I know it’s not easy to find references. Regarding the prices in percentage in JSON, I wasn’t aware of that. It really helps a lot to have this percentage relation to get an idea of the difference compared to the base price. I still need to read the Pareto and operations articless. And you didn’t mention the usefulness of pinging the gateway and directly to the application. I tried to understand how it works and its utility, but I couldn’t find a real use for the feature. The RTT tables seem much more useful to me. I’m not sure if I’m correct
The RTT tables are what you want.
Basically, “ping” is a traditional reflex when running into network problems. The introduction post for fly ping, its user-mode WireGuard implementation, motivated it with the example of verifying minimal connectivity to the gateway node. My own impression is that fly doctor, fly dig, fly ssh console, and fly pg connect have now mostly superseded it, as recommended diagnostics.
To my knowledge, fly ping was never intended for benchmarking…
1 Like
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.