Live data from Hacker News

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

blog.jonlu.ca

141–150 of 193 posts

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

#141
post #129
post #71

Earlier quoted context omitted.

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?

It matters a lot. I just spent three days on a 130kbps 1000+ms latency high packet loss connection, and RTT was one of the problems that made lots of sites I tried (practically) unusable, due to launching dependent queries in series without any retries. The other big one was gigantic interaction-blocking assets served from CDNs with aggressive timeouts. SV techbros are a fun pinata to smash, but that's a load of bull…

Pretty sure the guilt is shared. The profit seeking personal data peddlers don't choose overengineered solutions that only make sense at google scale.

I also have a feeling hardware designers could use being forced to live somewhere that's not a dust less constant temperature air conditioned office in California, but that's another matter for a different rant.

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

#142

Earlier quoted context omitted.

CDNs can actually add quite a bit of latency depending on where you're located. My server is located in Sweden, and for users in US West, access through Cloudflare adds like 100-150ms ping. It's very noticeable, bordering on intolerable for API access.

Is that CDN or DDOS protection? CDN should serve static assets near the user. Has to be quicker unless something went very wrong.

Yeah, you can't have a public search endpoint or it will get spammed into oblivion. API endpoint is not cloudflared anymore though, since I use an API key system. But anything that is anonymous is basically toast if you don't use serious bot mitigation.

Cloudflare rejects about 2.5M search queries per day from bots. About ~20k make it through, and some of those are humans.

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

#143

Earlier quoted context omitted.

There is no reason why most sites can't return one pregenerated static HTML blob. The number of async requests is a killer.

For first load? Sure, that's possible in many case. But that cannot help with interactive pages or web applications, and in other cases it can be a bandwidth/latency tradeoff. High latency is always bad and should be avoided. Serving content from the served contentinent is the minimum requirement for good UX.

This is why we added http cache headers, CDNs and caching of common assets, and cross domain requests. All of which are being assaulted for various levels of "privacy" concerns. Privacy I never asked for mind you, but I get it anyways. Though how convenient that tracking still happens, I still get ads, my content still doesn't belong to me, sites are slower, everything is an App, and the general experience and openness of the web is Down.

I exaggerate a bit to prove a point but the gist is definitely happening, we're just waking up to it slowly.

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

#144
post #72

Earlier quoted context omitted.

>If your app has to make 40 requests pulling in js files, CSS files fonts, API calls etc. to show something useful that will be visibly slow To put this in a way the common man can appreciate, imagine you're at a restaurant and you ordered some clam chowder and your waiter brings it to you. If the waiter brings you the chowder complete in one bowl, you get the chowder then and there. That is HN and most websites from…

If the waiter prioritized the spoon request, you could start eating a lot sooner.

as the content within the bowl move around as it continues to load

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

#145
post #28
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…

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.

[dead]

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

#146
post #5
post #3

Earlier quoted context omitted.

Ironic for an Australian co's GitHub alternative to be less responsive than GitHub itself in Australia.

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

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

#147
post #7

Good article! I always notice this same effect when I visit my parents in Argentina or I'm in Europe. > Using a global CDN can help get your assets to your users quicker, and most companies by this point are using something like Cloudflare or Vercel, but many still only serve static or cached content this way. Very frequently the origin server will still be a centralized monolith deployed in only one location, or the…

Another way that a global cdn helps is that your HTTPS negotiation takes place closer by.

There are (in http 1.1 at least) many back and forth steps to negotiating the HTTPS connection, the encryption key, etc. A global cdn into a cloud service (CloudFront is the example I know best) lets the user do those back and forths with a server very close to them, then handle the long haul to where the request is handled in one round trip.

Eg: putting CloudFront in front of your API calls can make them faster! Great video by slack on the topic: https://m.youtube.com/watch?v=oVaTiRl9-v0

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

#148
I remember when we first moved to the cloud from a datacenter. It was in us-east-1, and literally the day after the switch over (before we started configuring multi-region) was the first time us-east-1 had its major outage.

The owners were pissed that it had gone down and it wasn't that it went down, it was that we were basically sitting around with our thumbs up our ass. When things went down in our DC, we just fixed them or at least we could give an ETA until things went back to normal. We had absolutely nothing. We couldn't access anything, and AWS was being slow in acknowledging an issue even existed.

That was a good lesson that day: the cloud is not necessarily better.

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

#149
> In reality, the ping you’ll experience will be worse, at around 215ms (which is a pretty amazing feat in and of itself - all those factors above only double the time it takes to get from Sydney to the eastern US).

Isn't it double just because ping measures round trip time?

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

#150
post #69

Earlier quoted context omitted.

> It's number of requests. Absolutely. This is the prime hallmark of shitty, slow web. If you fight your battles here everything else will fall into place. I've started building our B2B web apps where the server returns 1 final, static HTML document in response to every resource. There are no separate js/css resource URLs at all in our products anymore. Anything we need is interpolated into the final HTML document sc…

For the record: a PWA can also be served by a single request, it's called hydration. My issue with these kinds of discussions is that they're inevitably using outright false arguments. You can make a well performing website through SSR and a backend templating language, yes. However , In a business setting with lots of developers this usually becomes an abhorrently performing website despite the SSR with the same tem…

>You can make a well performing website through SSR and a backend templating language, yes.

>However , In a business setting with lots of developers this usually becomes an abhorrently performing website despite the SSR with the same templating language.

I'm not sure this follows. It's harder to do client side rendering because your data is across a slow HTTP barrier. And the client is maintaining state which is harder than stateless.

The problem with SSR is that it's usually tied with single applications which are usually monoliths. But neither of these are requirements for SSR. If you break up your monolith into modules and/or SOA you get the best of both worlds.

But for reasons I don't understand nobody does it this way. It's either monolith + SSR or microservices + client rendering

Post reply on HN