51–60 of 124 posts
Instead of having your users go through the public internet, they connect to some proxy which is closeby and sends the traffic through the „privat“ line.
Earlier quoted context omitted.
Also a couple of things to note: 1. Submarine cables can't go in a straight line, since they've got to, you know, go down to the bottom of the ocean. (Which, you may have heard, is quite deep.) Also, a cable with a length of several thousand miles tends to have some slack. 2. Your packets may take a very curvy route from one city to another, even when they're not geographically that distant. This may be because your…
For point 1, is the depth of the ocean significant compared to the distances traversed? My back-of-the-envelope math suggests it’s less than half a percent for a cable from New York to England. (6 miles down + 6 miles up, divided by rough great circle distance of 2600 nautical miles.) I would think a bigger factor would be that the cables (IIRC) don't go in straight lines (which you did allude to).
Splitting static content into smaller files allows for better cache utilization, but increases page load times due to higher latency when those items aren't cached. Bundling content reduces roundtrip penalties (latency, various per-request processing overheads) at the cost of greater bandwidth usage.
Wealthier users usually are latency-limited, as opposed to bandwidth-limited. Mobile users and poorer users in wealthier countries are usually limited on both. Users in poorer countries have it even worse.
The only way that you can "win" appears to be by making your content as static and as simple as possible.
Minor note---you can get much tighter theoretical minimum latencies than the ones listed in your table. 1. The table's mins divide straight line distance by the speed of light. This gives you the time it takes for light to travel in a straight line from, say, London to New York. However, your "real latencies" are roundtrip ("ping") latencies. Thus, you need to multiply all the theoretical latencies by two. 2. Data do…
#2 is great background! But these cosine losses are I suppose not a theoretical limit but a limitation of fibre optics so I won't include that (but I will link to your comment!).
Many years ago (2006 and 2009, respectively) I had to choose European and Asian locations for rsync.net storage arrays. My primary, overriding criteria in choosing locations was what would be the coolest, most interesting place to visit for installs and maintenance . I chose Zurich and Hong Kong. Measured results have exceeded my initial models.
I’ve nothing against Switzerland (it’s nice) but you’re the first person I’ve ever come across to suggest Zurich (or anywhere in Switzerland) as the coolest and most interesting place in Europe! I’m genuinely interested to hear more.
Many years ago (2006 and 2009, respectively) I had to choose European and Asian locations for rsync.net storage arrays. My primary, overriding criteria in choosing locations was what would be the coolest, most interesting place to visit for installs and maintenance . I chose Zurich and Hong Kong. Measured results have exceeded my initial models.
I’ve nothing against Switzerland (it’s nice) but you’re the first person I’ve ever come across to suggest Zurich (or anywhere in Switzerland) as the coolest and most interesting place in Europe! I’m genuinely interested to hear more.
Zurich is very quick and convenient to any of Chamonix (straight west) Davos/St.Moritz (south), Cervina/Zermatt (southwest) or Südtirol (southeast).
Earlier quoted context omitted.
The applications I work on do several database calls for single user HTTP request. Shouldn't the application server be as close as possible to the database, rather than to the user? I struggle to think of an example where your model is useful, unless your application has no database.
It can work as a "smart cache" - like for example: https://fly.io/docs/app-guides/graphql-edge-caching-apollo/ I'm not entirely convinced this is a great idea (and apparently the example uses plain http between the graphql prox/cache and openlibrary.org - that might be considered a bug, I suppose: https://github.com/fly-apps/edge-apollo-cache/blob/master/sr... At any rate I'd assume whatever source you're proxying (e…
But: while you can very easily use TLS to backhaul to an API, a more "modern" Fly.io way to solve this problem is with WireGuard gateways; it's trivial --- I'd argue, easier than configuring SSH certs --- to get a WireGuard link from your cache app on Fly back to AWS, GCP, or wherever your non-Fly legacy database lives.
I really think WireGuard is going to change a lot of the ways we design systems like this.
Earlier quoted context omitted.
For point 1, is the depth of the ocean significant compared to the distances traversed? My back-of-the-envelope math suggests it’s less than half a percent for a cable from New York to England. (6 miles down + 6 miles up, divided by rough great circle distance of 2600 nautical miles.) I would think a bigger factor would be that the cables (IIRC) don't go in straight lines (which you did allude to).
Correct. The ocean bottom is relatively flat once away from the continents. Also, the submarine cable actually has a very slight advantage over a surface cable as at several thousand feet below it is following a slightly smaller radius curve. I'm waiting for the HFT firm to bore a literally strait hole between London and New York. Then we know that HFT has gone too far.
Minor note---you can get much tighter theoretical minimum latencies than the ones listed in your table. 1. The table's mins divide straight line distance by the speed of light. This gives you the time it takes for light to travel in a straight line from, say, London to New York. However, your "real latencies" are roundtrip ("ping") latencies. Thus, you need to multiply all the theoretical latencies by two. 2. Data do…
Also a couple of things to note: 1. Submarine cables can't go in a straight line, since they've got to, you know, go down to the bottom of the ocean. (Which, you may have heard, is quite deep.) Also, a cable with a length of several thousand miles tends to have some slack. 2. Your packets may take a very curvy route from one city to another, even when they're not geographically that distant. This may be because your…
Ha, it only just struck me that could have been an NSA-type routing issue!?!
Earlier quoted context omitted.
I’ve nothing against Switzerland (it’s nice) but you’re the first person I’ve ever come across to suggest Zurich (or anywhere in Switzerland) as the coolest and most interesting place in Europe! I’m genuinely interested to hear more.
Presumably, it's 'of the list of places with a data-center meeting the specs we require' which, I imagine, limits the range of options somewhat.
Amsterdam, Frankfurt and (perhaps surprisingly) Marseilles are the places to go if you want to optimize for routing.
Equinix has datacenters, with he.net POP, in all three places. You could do a lot worse than standardizing, globally, on EQX datacenters and he.net connectivity ...