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

181–190 of 193 posts

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

#181

Post by ttepasse »

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…

> Preview images of what?

Lazy loading images drives me a little bit nuts. Previously with JS, now build into the browser. You scroll down and then you’re waiting for an image, regardless of CDN. The latency of an additional connection is notable. It’s particularly aggravating if you’re have opened a page in a background tabs minutes or hours ago and when you start reading it, the page isn’t really there as expected but still needs to lazy load.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/im...

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

#182

Post by cbzoiav »

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…

You dropped the API calls bit.

As it stands your site has to go through a TCP handshake then send the request and get the start of the response - at minimum that's 2 round trips. It then gets the JS and CSS tags in the head of the HTML and has to request those - let's assume HTTP/2 so that's another single RT of latency (on HTTP it's at least two depending on if you queue requests or send in parallel).

On 215ms RT latency that is an absolute minimum of 645ms before your JS has even started to be parsed. For a large bundle with a load of vendor code at the top in practice were talking several seconds to getting to the code that makes the API calls to get the content needed to render the first page.

And this is before we talk about any Auth, images, opening a websocket or two and people using microservices as an excuse to require a request for nearly every field on the page... (Or worse multiple requests and applying some logic to them...).

There is a fundamental minimum RT bound to a static JS based web app that is a multiple of a server rendered page. If you cache the HTML and JS bundle it can be worth it but you still need to aggregate data sources for the page on a backend and/or host it in multiple regions.

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

#183

Post by cbzoiav »

rcme wrote: post #122
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…

HTTP/2 supports request multiplexing so you don’t need multiple connections or queuing to fetch multiple resources. The bigger issue is that a lot of requests are dependent on previous requests so all the latency adds up. E.g. when you fetch Reddit, it only downloads the JavaScript and then fetches the post content. The move away from server rendering of webpages has really made things slower.

Multiplexing isn't a golden bullet. You still hit limits.

The initial TCP window is usually around 4KB so you have the handshake SYN RT (+ another two for TLS) followed by at most 4KB of request data. Cookies, auth headers etc. can make that a relatively low number of requests before you need to wait for the next RT. You also have the TCP window on the responses and again headers for large numbers of requests eat into that.

And then as you say dependencies - load the HTML to load the CSS and JS to Auth the user to make the API calls (sometimes with their own dependency chains)...

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

#184

Post by cbzoiav »

michaelmior wrote: post #167
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…

> You can reuse the connection but that means queuing requests and hitting the latency as a multiplier. This is partially true. HTTP/2 is capable of issuing multiple requests on a single connection and retrieving multiple responses in a single packet (assuming it fits of course). So while you probably won't get the same benefit as you would with multiple parallel connections, the overhead is likely to be much less th…

From my comment.

> HTTP/2 reduces the problem with multiplexing but it still doesn't go away

Even multiplexed you hit initial TCP window limits + all the response header overhead.

And many cases you have dependencies - need the first HTML content to issue the JS request to issue the Auth request to issue the API call to issue the dependent API call...

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

#185

Post by phamilton »

onion2k wrote: post #54
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…

Just a nit, but aren't DNS lookups going to be independent of distance to us-east-1?

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

#186

Post by throwawaymobule »

The tab of browser devtools that let you simulate slow connections should probably add simulation of this kind of latency, as well as a 'simulate AWS outage' toggle if that's even possible. (don't know enough DNS to know how hard the latter is)

I guessed from the title that this would focus on redundancy, but I guess that's rarely noticable.

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

#187

Post by midoridensha »

nottorp wrote: post #71
vjk800 wrote: post #28

Earlier quoted context omitted.

HN front page isn't filled with garbage and loaded with a million lines of pointless javascript like all other sites you mentioned. HN front page is 27 kb in size while, for example, reddit is 943 kb. Performance issues with websites are entirely a self-made problem. There are plenty of fast, lean and yet very functional web pages like HN that prove that prove it.

Q1: Why would round trip latency matter so much when the modern web 45.0 adds so much overhead? Q2: Why don't we just force all the SV techbros to test their sites - AND their browsers - on a $200 notebook with eMMC storage from 2 years ago?

The SV techbros should have to test their sites on 2010-era notebooks running through two VPNs connecting through Australia and Finland.

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

#188

Post by alam2000 »

kiwijamo wrote: post #22
quickthrower2 wrote: post #17

Earlier quoted context omitted.

I think cloudflare is in front of HN these days

It is not. A simple traceroute shows traffic from Auckland, New Zealand is routed all the way to the San Diego via Los Angeles. Cloudflare sites typically have traceroutes terminating here at Auckland (best case scenario) or in some cases across the pond in Sydney, Australia. It is interesting to note however I don't observe much latency issues despite a 130ms round trip.

[dead]

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

#189

Post by re-thc »

rozenmd wrote: post #146
re-thc wrote: post #5

Earlier quoted context omitted.

Add to that Github is also in the same region as Bitbucket.

GitHub appears to distribute their traffic between us-east and eu-central: US East (N. Virginia) 62ms 200 OK Europe (Frankfurt) 62ms 200 OK US West (N. California) 175ms 200 OK Asia Pacific (Sydney) 359ms 200 OK Asia Pacific (Tokyo) 662ms 200 OK

What happened to Tokyo? :(

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

#190

Post by yuuuuuuuu »

arghwhat wrote: post #73
yuuuuuuuu wrote: post #40

Earlier quoted context omitted.

That's exactly GP's point, right? No matter us-east-1 or not, what makes things slow has nothing to do with DC location. That latency is insignificant.

HN takes - when fully cached, where it only takes 1 request - ~200ms to load, so 3/4ths of the pageload is just the roundtrip. HN user experience in EU is "meh" because HN is one of the fastest loading dynamic pages on the web to load, meant to give you whiplash from the load speed. Not all pages can load with 1 request, even when designed well, so they will be sub-"meh". HN, if hosted in EU, would have gotten a "daa…

I think you are missin the point. The typical website is so bloated that a latency of a single roundtrip is not the root cause. They may load quicker if roundtrips are faster, but that's then mainly because they make too many roundtrips.

That it makes a significant difference for HN (as in: "measurable") is because HN is so snappy in the first place.

Apart from that, being located in Europe, I agree with the other posters that claiming HN being "meh" in Europe is just nonsense. It's one of the quickest websites you can come across on this planet. Anywhere on the planet.

Post reply on HN