Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Noticing when an app is only hosted in us-east-1

blog.jonlu.ca

Post reply on HN
Print view View original

51–60 of 193 posts

Re: Noticing when an app is only hosted in us-east-1

#51

Post by chrismsimpson »

To counter the top comment at the moment, being from Sydney, Australia, I totally do buy it. It also works both ways, if you want to build something with global reach but host it locally you’re immediately going to be penalised by the perceptions that come with latency. Also, I might add that the latency builds up non linearly the more throughput you’re attempting to achieve (e.g. streaming video).

Disclaimer: I am currently working for a startup attempting to build a video creation and distribution platform with global reach.

Re: Noticing when an app is only hosted in us-east-1

#52

Post by landgenoot »

I think the peering agreements of the local ISP are likely to be a factor as well.

When I moved inside Europe I suddenly noticed slow connections to Github pages. I expected that it had something to the physical location of the Github pages servers. However, when I connected to the VPN of my previous location it all was snappy again. That eliminated the physical distance as a cause.

Re: Noticing when an app is only hosted in us-east-1

#53

Post by jefozabuss »

bruce511 wrote: post #48
cbzoiav wrote: post #45

Earlier quoted context omitted.

Size isn't even the worst of it. It's number of requests. You need to go through a TCP handshake for every connection you open. You can reuse the connection but that means queuing requests and hitting the latency as a multiplier. Browsers also have a cap on parallel connections so when you get enough requests it queues either way. HTTP/2 reduces the problem with multiplexing but it still doesn't go away. If your app…

>> has to make 40 requests pulling in js files, CSS files fonts So it's 2023 and I've been concatenation all my css, and all my js, into a single css and js request since like 2005. So a call to the site results in maybe 3 or 4 requests, not 40. But I've noticed most sites don't do this. Perhaps because I was trained when we had 28k modems not 100mb fibre? Http/2 makes a big deal of multiplexing, but its less convinc…

Modules are widely supported now for js which means you could have 100 modules = 100 files instead of 1 bundle of 100 modules = 1 file, obviously this is not "the most ideal" but it allows you to skip a build step. There are also frameworks like Astro that splits your pages into tiny pieces so there are definitely some ways to add a lot of requests

Re: Noticing when an app is only hosted in us-east-1

#54

Post by onion2k »

TekMol wrote: post #8

I don't buy this. Hacker News is one of the most responsive websites I know. And it is run on a single server somewhere in the USA. While I am in Europe. If you have users in Sydney, Australia ... ... you are floored at 104ms of latency for your request When I open AirBnB with a clean browser cache, it takes several seconds until I see something useful. Those 104ms of latency don't make a dent. Reddit takes over 5 se…

Those 104ms of latency don't make a dent.

Aren't there several requests to complete though? Assuming 5 synchronous requests before the first byte of your web page is rendered (a DNS lookup, a TLS connection to establish (which requires 2 requests), then a preflight request, and finally the actual request) that's a full half a second just on the flight time regardless of all the other costs. That's an extra 10% on top of the 5s it takes for Reddit to load. Subsequent requests would be faster but generally it's the first page load people really notice.

Re: Noticing when an app is only hosted in us-east-1

#55

Post by re-thc »

littlestymaar wrote: post #49
re-thc wrote: post #26

Earlier quoted context omitted.

~150ms is usually acceptable especially if there's no Javascript and other extra delays. >=200ms is usually. where it really shows.

Keep in mind that 150ms round-trip latency means at least 600ms latency when opening a webpage because of the TCP and TLS handshake. But even 600ms is OK on today's web (or even on today's desktop apps it seems…)

> Keep in mind that 150ms round-trip latency means at least 600ms latency when opening a webpage because of the TCP and TLS handshake.

The solution there is use a CDN, even for the API. Or some anycast IP solution like Global Accelerator (AWS), Global load balancer (GCP) or Front Door (Azure).

You connect to the nearest region for HTTPS handshake and then that takes the "fastest" route back to your origin.

There's a video from AWS documenting how Slack did exactly that: youtube.com/watch?v=oVaTiRl9-v0

Re: Noticing when an app is only hosted in us-east-1

#56

Post by jaggederest »

bruce511 wrote: post #48
cbzoiav wrote: post #45

Earlier quoted context omitted.

Size isn't even the worst of it. It's number of requests. You need to go through a TCP handshake for every connection you open. You can reuse the connection but that means queuing requests and hitting the latency as a multiplier. Browsers also have a cap on parallel connections so when you get enough requests it queues either way. HTTP/2 reduces the problem with multiplexing but it still doesn't go away. If your app…

>> has to make 40 requests pulling in js files, CSS files fonts So it's 2023 and I've been concatenation all my css, and all my js, into a single css and js request since like 2005. So a call to the site results in maybe 3 or 4 requests, not 40. But I've noticed most sites don't do this. Perhaps because I was trained when we had 28k modems not 100mb fibre? Http/2 makes a big deal of multiplexing, but its less convinc…

Remember back in the old days when people used to concatenate images into imagemaps and specify the coordinates and dimensions? One image file for a whole site.

Same goes back when we could just load a single library from the Google public version (cough-jquery-cough) and then all the on-page JS was just in-tag handlers. Not that it was better but boy howdy was it faster to load.

Re: Noticing when an app is only hosted in us-east-1

#57

Post by nobody9999 »

kiwijamo wrote: post #24
re-thc wrote: post #6

Earlier quoted context omitted.

> DNS is probably 2 round trips (CNAME then A), and that has to cross the ocean via your resolver of choice I hope your DNS doesn't have to do that. Most anycast DNS should have lots of PoPs (regions) and are really fast. CDNs usually solve a lot of the static asset issues. The main issue is the database.

People should use their ISP's DNS as well which is often <5ms. I've never bothered using an off-net DNS provider for this reason given how much faster is it to use an on-net caching DNS resolver provided by my ISP.

>People should use their ISP's DNS as well which is often I've been using a local recursive resolver for the past 2-3 years and haven't seen a noticeable difference in resolution times as compared with using my ISP's resolver.

I would guess that using a local recursive resolver (although it caches as well, so that's less of an issue with items in-cache) increases resolution times, but only on the order of tens of milliseconds.

Which is peanuts compared to client/server query response times, especially if requests return data and/or javascript heavy results.

And given that many ISPs mine their customers' DNS queries and sometimes return incorrect (from the perspective of the customer) results, I'd rather not use my ISP's resolvers -- and that hasn't had any noticeable impact on responses to browser requests.

In fact, uMatrix tends to slow things down much more for me as I often have to choose which scripts/3rd party assets/etc. to allow in order to browse a particular site -- or just to abandon the attempt if there's too much cruft.

That especially annoys me when I need to load scripts from several different sites just to view text. In those cases, I usually just close the tab.

Re: Noticing when an app is only hosted in us-east-1

#58

Post by rightbyte »

the_mitsuhiko wrote: post #29

I mostly notice edge hosted apps as a problem now. Some newfangled sites have horrible cold start times if they are not too busy in Europe.

Oh the hubris of adding another level of indirection ... or maybe it is layer of abstraction. Not sure.

Re: Noticing when an app is only hosted in us-east-1

#59

Post by hosteur »

kiwijamo wrote: post #24
re-thc wrote: post #6

Earlier quoted context omitted.

> DNS is probably 2 round trips (CNAME then A), and that has to cross the ocean via your resolver of choice I hope your DNS doesn't have to do that. Most anycast DNS should have lots of PoPs (regions) and are really fast. CDNs usually solve a lot of the static asset issues. The main issue is the database.

People should use their ISP's DNS as well which is often <5ms. I've never bothered using an off-net DNS provider for this reason given how much faster is it to use an on-net caching DNS resolver provided by my ISP.

Yeah in an ideal world. But then you have isps logging and selling your dns lookups as well as blocking certain dns names etc.

I think these are the main reasons for people to use other dns providers.

Re: Noticing when an app is only hosted in us-east-1

#60

Post by mschuster91 »

bruce511 wrote: post #48
cbzoiav wrote: post #45

Earlier quoted context omitted.

Size isn't even the worst of it. It's number of requests. You need to go through a TCP handshake for every connection you open. You can reuse the connection but that means queuing requests and hitting the latency as a multiplier. Browsers also have a cap on parallel connections so when you get enough requests it queues either way. HTTP/2 reduces the problem with multiplexing but it still doesn't go away. If your app…

>> has to make 40 requests pulling in js files, CSS files fonts So it's 2023 and I've been concatenation all my css, and all my js, into a single css and js request since like 2005. So a call to the site results in maybe 3 or 4 requests, not 40. But I've noticed most sites don't do this. Perhaps because I was trained when we had 28k modems not 100mb fibre? Http/2 makes a big deal of multiplexing, but its less convinc…

> But I've noticed most sites don't do this.

Because the trend went from having Webpack produce a 5+MB single JS bundle to splitting based on the exact chunks of code that the current React view needs, particularly to improve the experience of mobile users.

Post reply on HN