Live data from Hacker News

Where's the fastest place to put my server? How much does it matter?

calpaterson.com

11–20 of 124 posts

Re: Where's the fastest place to put my server? How much does it matter?

#11
post #8

Shameless plug: https://fly.io We built Fly _specifically_ so you can run servers close to your users. We do a lot for you on the network side, too, like terminate TLS in all our regions. One thing to note, though, is that latencies between cities are surprisingly different than their theoretical max. We have apps on Fly with lots of South American users. It's frequently faster for people in Argentina to connect to M…

> It's frequently faster for people in Argentina to connect to Miami than it is to hit Sao Paulo or Santiago.

Yeah, most networks in South America don't interconnect with networks in other countries. They mostly connect in Miami, because international connectivity is difficult to arrange, and if you can only manage to connect to one other country, it needs to be the US. Africa likely goes to Europe rather than the US? But same thing, it's hard to connect, so first you have to connect to where the content is. And there's not (currently) enough network stability and capacity to just connect to your neighbors and rely on them to get you to the US/EU either.

I don't know if it's current, but in Japan there used to be two dominant networks, but they weren't both available at the same PoP. You would need a Tokyo-A pop to get to one, and a Tokyo-B pop to get to the other; and it was difficult to interconnect those pops.

Re: Where's the fastest place to put my server? How much does it matter?

#12
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.

Re: Where's the fastest place to put my server? How much does it matter?

#13
>Here's a table of latencies from London to other world cities with more than 5 million people, comparing against the theoretical maximum speed, the speed of light:

This is a flawed comparison because it looks like he's comparing ping latency (round trip time) with speed of light (one trip), so the "Slowdown factor" columns is off by a factor of two.

Re: Where's the fastest place to put my server? How much does it matter?

#15
post #9

Can you elaborate more about the server in Finland? How does it work? The ones I have seen are super expensive and the only thing they provide over putting server at home is the network quality. Any ideas where we can get a inexpensive data center that can on/off the system and give good network?

My guess, the author uses hetzner

Re: Where's the fastest place to put my server? How much does it matter?

#16
post #12

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.

This is one of those comments that's difficult to interpret the meaning of... until you read the commenter's name.

(Love your work)

Re: Where's the fastest place to put my server? How much does it matter?

#17

Right now, due to vast CDN footprints, PoPs would be the fastest place to run a "web server": S3+Cloudfront / Lambda at Edge, Cloudflare Workers, StackPath EdgeEngine etc Soon the fastest place is going to be the 5G Edge with products like vapor.io Kinetic Edge Colo, AWS Wavelength, Google Anthos for Telecommunications already making a push for it. Ex: https://cloud.google.com/blog/topics/anthos/anthos-for-telec...

The edge is getting to be really important for high quality interactions, but there are some caveats.

In systems in which there is common shared state between all participants (e.g. Fortnite), you fundamentally must have a form of centralized authority somewhere. In these cases, you do not gain very much by pushing things to the edge if most interactions require taking a round trip through the business state machine.

This realization is why I really enjoy the renewed push for server-side hosting technologies. Accept the fundamental physics constraints, bring all the state under 1 roof, and think differently about the footprint of a global-scale application. AWS solved this problem by making their regions more-or-less 100% standalone. The only major thing that really spans all regions is account/session management, but consider that there arent serious UX constraints around a login attempt taking more than 150ms.

Re: Where's the fastest place to put my server? How much does it matter?

#18

Earlier quoted context omitted.

By today’s standards, in a nation rich in high speed connections, perhaps.

1 MB = 1 megabyte 1 Mb = 1 megabit 1 mB = 1 millibyte 1 mb = 1 millibit

In Europe a megabit is usually written mbit

Re: Where's the fastest place to put my server? How much does it matter?

#19

Earlier quoted context omitted.

By today’s standards, in a nation rich in high speed connections, perhaps.

1 MB = 1 megabyte 1 Mb = 1 megabit 1 mB = 1 millibyte 1 mb = 1 millibit

1 mB = 1 millibucket

Re: Where's the fastest place to put my server? How much does it matter?

#20
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 does not travel through a fiber optic cable at the speed of light. This is because light actually bends around the cable when transmitted. These are called cosine losses, and mean the light travels roughly 5/3 the actual cable distance. So, multiply again by 5/3. (This is why HFT firms use microwave links for long distances.)

If you multiply the theoretical maxes by 3.33, you'll see that they're very close to the actual latencies you're observing. New York -> London becomes 62.7 ms optimal, so you're only 13% slower than the theoretical max.

Here on the west coast, I typically see within 10% of the theoretical min for data going over the Seattle -> Japan submarine cables.

Post reply on HN