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

My £4 a month server can handle 4.2M requests a day

mark.mcnally.je

Post reply on HN
Print view View original

51–60 of 479 posts

Re: My £4 a month server can handle 4.2M requests a day

#51

Post by tick_tock_tick »

tomrod wrote: post #33
fbrchps wrote: post #25

Earlier quoted context omitted.

Working in the space, that's one of the more frustrating things to see on HN/Reddit/etc. It's not a complex or niche thing, and especially for sites that only make profit when people can actually visit them, it's kind of a necessity to stay up as much as possible. (Obviously the sales thing doesn't apply to OP)

For those of us that are new to the space, lack background, or wear 50 hats in a startup, can you point us to best practices here?

Just throw cloudflare in front it's free.

Re: My £4 a month server can handle 4.2M requests a day

#52

Post by fabian2k »

Tenoke wrote: post #42
fbrchps wrote: post #35

Earlier quoted context omitted.

For sure, OP's site is handling this much better than most. And like I said, it's not every time that it takes multiple seconds. Some websites featured on HN/Reddit don't load at all when under load. However I was able to get it to take ~30s to load multiple times, over a period of around 10 minutes.

In their defence the sites that fail to load or take too long are usually full webapps that do a lot of work rather than just static sites.

The important message there is that if you can change your problem from serving slow dynamic content to serving static content you can gain enormous performance benefits.

Whether that means actually using static sites for stuff that can be static or just properly caching expensive things. Even dynamic content doesn't have to be slow, but many CMS are seriously inefficient without a cache. I'm not really blaming the CMSes entirely here, part of that is because they need to be extremely flexible, but once you need dozens of DB queries per page it'll fall over quickly on small hardware.

Re: My £4 a month server can handle 4.2M requests a day

#53

Post by mark_mcnally_je »

jeroenhd wrote: post #39
fbrchps wrote: post #12

I understand your excitement for being able to handle a decent amount of requests on such a small server, but just like many other websites that get on the frontpage of HN, your site is taking multiple seconds to load for me, depending on when I refresh. As you said in your post, adding caching to your site increased your throughput by ~20% (or +10/req/sec). What you and other sites seem to lack is a more distributed…

Are you sure that's related to the server itself? The page loads instantly for me and the DNS is still resolving to an OVH IP address. Timing info from Firefox: Blocked: 0ms DNS resolution: 8ms Connecting: 9ms TLS setup: 12ms Sending: 0ms Waiting: 30ms The very last resource (favicon.ico) loaded after 466ms and that's mostly because of the other files being requested only after the CSS has come in (after about 195ms)…

Nope, website has not changed at all - speaking of the Matomo tracking; that is running on a separate server and has actually crashed!

Re: My £4 a month server can handle 4.2M requests a day

#54

Post by Rd6n6 »

Re: benchmarking, sometimes the bottleneck is the machine or server that issues the requests, not the receiver that you are testing. To figure out your actual capacity, you sometimes need multiple request servers or a more powerful request server. This was the case for a project I did a few years ago. Not a critique of the blog post, just remembering something out loud

His site, https://peepopoll.com/, took about 10s to load for me. It’s also good to chart other metrics like response times while you benchmark. Requests per second isn’t the same as a low response time

Re: My £4 a month server can handle 4.2M requests a day

#55

Post by fbrchps »

tomrod wrote: post #33
fbrchps wrote: post #25

Earlier quoted context omitted.

Working in the space, that's one of the more frustrating things to see on HN/Reddit/etc. It's not a complex or niche thing, and especially for sites that only make profit when people can actually visit them, it's kind of a necessity to stay up as much as possible. (Obviously the sales thing doesn't apply to OP)

For those of us that are new to the space, lack background, or wear 50 hats in a startup, can you point us to best practices here?

I don't have a "Do all These for a Fast Website" list handy, but here are some key points I've found can be applied to most sites:

- Make sites that are fast by default: Small bytes sent over the wire, beyond just initial page load, too. Yes, that does mean that your giant Google Tag Manager/Analytics/3rd party script is bloated. Reach out to 3rd parties about reducing their payload size, it's saved me several MB over the years. Also, not writing efficient CSS is a huge killer when it comes to byte site. Devs shouldn't "leave it just in case" when it comes to code, you have version control for a reason. And when a new feature comes out, clear out the old cruft.

- Avoid unnecessary DB calls: Obviously you need to get the data onto the page somehow, but if you can server-side render, then cache that result, you're reducing the overall calls to the DB. Also, optimizing queries to return only-what-you-need responses helps reducing total bytes over the wire

- Balance between Server and Client side: Not only are servers getting more powerful, so are client devices. Some logic can be offloaded to clients in most cases, but there needs to be a balance. Business-critical logic should probably be done server side, but things like pagination & sorting -- so long as they client will likely see or use all the data -- is fine in my book. Having 2000 rows of JSON in memory is totally OK, but rendering 2000 at once might cause some issues. Again, balance

- Hopping on the latest-and-greatest bandwagon isn't the best: Devs hate re-writing the site every 6 months, and really the newest framework might not be the best for your use case. Keep up to date with new technology, but saying "not for me" is fine.

- Don't let (non technical) managers make technology decision: See above. More often than not, C-levels want to use shiny new things they read an article about on LinkedIn once, no matter if it fits the needs of the company or not. Thankfully I've only been at one place that was like that, but while I was there it was hell. Current VP was an original developer on the site back in the early 00's, so he knows how to deflect BS for us. That VP also knows that he's outdated in his knowledge by now, so he trust the Devs to make technical decisions that are best for the company.

Re: My £4 a month server can handle 4.2M requests a day

#57

Post by reilly3000 »

dreyfan wrote: post #23
ppeetteerr wrote: post #4

How did this make it to the number two spot on HackerNews?

Broadly speaking people on HN have no clue how to setup a performant httpd/app server and are impressed by abysmal performance/cost metrics like this or the MangaDex post. Everything these days is obscured through multiple layers of SaaS offerings and unnecessary bloat like kubernetes. ~10k rps (it was concurrent connections but close enough) was state of the art in 1999. Now 22 years later ~50 rps is somehow impress…

In my opinion it isn’t so much of a lost art or lamentable accretion of useless abstractions, but an increase in the scope of what web apps do these days. Most of us aren’t working on static sites or simple CMS publishing- those are a solved problem. Instead we’re building mobile banks, diagnostic systems, software tooling, 3D games, and shopping malls. The complexity is inherent in the maturity of the web and it’s many uses, as well as its global scale. Hugs of death are rare these days thanks to better architecture and infrastructure, even though the scale of users has grown 100X.

Yes there are wildly unnecessary abstractions that are used for small sites/apps, but I would contend they are artifacts of someone who it’s trying to learn something new, and/or get promoted. I have no problem with the former.

Re: My £4 a month server can handle 4.2M requests a day

#59

Post by fbrchps »

antihero wrote: post #37
fbrchps wrote: post #34

Earlier quoted context omitted.

It would also be possible for OP to spin up their own Redis cache, and have multiple POPs near their target audience, and handle DoS type attacks against their site if need be, and easily be able to brush aside bot traffic, and... Not all the above apply to a hobby-blog style site, but I wasn't referring only to OP's site in my original comment. I understand that not everyone needs to feed into "fucking Internet gate…

Could just install Varnish locally.

Haven't used Varnish myself directly, but yeah that would also work.

For OP, I'd also be interested to see the benchmarks between this £4 server, and a £8 or £10 one, same stack.

Re: My £4 a month server can handle 4.2M requests a day

#60

Post by shtps »

ezfe wrote: post #50
floren wrote: post #18

Earlier quoted context omitted.

Looks fine over here, and he doesn't have to route through a fucking Internet gatekeeper like Cloudflare or Amazon... let's enjoy this golden era before Chrome starts flagging any site which isn't fronted by a "reputable" cache like Cloudflare, Amazon, or whatever Google decides to introduce.

Oh I hate Google as much as the next guy, but that's not something they've shown any interest in doing.

Google AMP comes to mind.
Post reply on HN