Question for people that run websites that have been “hug of death”ed: would your website be able to be statically hosted on something like github pages, if no why not — if yes why do you choose not to, given it is free and would make all scaling troubles go away (or so I’ve heard).

There are two reasons why sites fall over in cases like this: CPU saturation, where the solution is better caching (which includes going fully static), and network saturation, where the solution is either to get fatter pipes or to reduce the data transferred. Hugs of death are normally due to CPU saturation.

But in this case, I suspect that the server is just saturating its network connection because of poor treatment of images.

I have JavaScript disabled so maybe it’s loading more if you have JavaScript enabled, but when you exclude images, it’s only transferring about 152KB. Images are where it goes wrong: it’s serving up a large number of images, and some of them are unreasonably large and high quality (like 34ᵗʰ place, a 1000×1000 PNG of a fractal being shown at 400×400), and most significantly it’s using quite a few multi-megabyte GIFs, which is flatly stupid and wrong and they deserve to have their site fall over for pulling that.

So the end result is at least 20MB. 20MB = 160Mb, and if your server has only a one gigabit link (very common), you can suddenly only cope with about six visitors per second (though in practice things will start falling over before that, maybe round down to five), which is not quite enough for the peaks you’ll get when high on HN, and it becomes a bit of a cascading problem, kinda like a capacitor but bad.

The solution is to treat the images properly: actually compress them, use videos instead of GIFs, that sort of thing. I reckon 3MB total is readily attainable here, which would allow you to serve 40 visitors per second, which is probably enough.

So yeah, putting your pages on a platform with really fat pipes will solve problems like this after a fashion, but I’d argue that it’s not really solving them, it’s just letting you get away with doing a bad job and shifting the burden onto users.

There was 5MB preview image limit for each submission. I was a bit surprised when my preview image went straight into the listing after review. The organizer was a bit struggling with the website (for example, there was no HTTPS for the first days of the contest and multiple people helped to get it working), hopefully next time it will improve.

Hi! I'm the host of js1024. Thank you for your advice, I'll try to fix these errors

> if yes why do you choose not to

Because there's more work in caching your dynamic server/CMS to static files and often isn't trivial. And the dynamic-rendered CMS is enough 99% of the time. You act like it's just a button you press, and you're wondering why people don't just press it.

It's also not a money-making venture. So you have very poor ROI on making your charity site endure the rare hug of death. It goes down? Oh well. It'll come back up. It's also the reason you're using some cheap CPanel setup, not deploying to a $5 VPS.

Sure I can understand not migrating existing dynamic websites to a static deployment model - don’t fix what isn’t broke. I suppose the question is more about greenfield projects, where in my experience writing a couple markdown files and pushing them to github and checking the “serve this” box is easier than managing a server.

> It's also not a money-making venture. So you have very poor ROI on making your charity site endure the rare hug of death. It goes down? Oh well. It'll come back up.

This is a very strange statement to me. My impression would be that if you’re running a charity site (or any site that makes money from being visited), you would want it to absolutely not go down during a hug of death, as that’s money out of your pocket at a time when it’s getting a ton of free publicity. Why make the site in the first place if you aren’t expecting it to provide value to either you or the viewer?

>where in my experience writing a couple markdown files and pushing them to github and checking the “serve this” box is easier than managing a server.

Making a site is more than "just some markdown files". Can you show me what you're talking about? Maybe I'm missing it. If you mean static-site generators (they aren't just a couple markdown files), they are very nerdy and have pretty bad UX for most people. I don't even use them. They are effectively developer-only, for one.

> This is a very strange statement to me.

Well, this is how things work. This goes back to the parable of the lumberjack who didn't have time to sharpen his axe, or the guy who didn't have time to write a shorter letter.

You just want to get something online that others can modify. Any additional second your pour into it is probably a waste of time. A niche website like JS1024 is down? Maybe nobody really cares. Maybe the only person willing to host this just does things this way. Oh well.

Edit: Your confusion here reminds me when I got my first dev job and was confused why the other developers never wanted to improve these obvious problems in the code. Or use new patterns. Or learn new things (16+yo VBScript app, the website was one 500k line switch statement running on IIS). "Doesn't anyone care?!" But as I got older, "I can't be fucked" or "cbf" made a lot more sense to me. Don't underestimate how often "cbf" answers your questions. ;)

Cloudfront & friends are pretty easy and cheap to do.

I was expecting an expensive hassle, but was happy to be wrong on that.

Sure most websites could easily served as static files on a server, but advocating for everything to be hosted on a single proprietary service is not a good idea.

But hosting an Apache or nginx to serve static files is easy enough and a single $5 or $10 instance on any hosting service out there could easily survive a HN frontpage.

Not advocating for any service in particular (though disclaimer I do work at msft), I’m honestly wondering why someone would choose to ship a website as a server running on a hardware time slot rental with all the setup, cost, inscalability, and management that requires, as opposed to a free cdn that gives you a website with only some markdown.

Mainly because it was not a mere markdown. You can't see right now, but it had submission forms with previews and rating forms. Yes, you can route dynamic parts to elsewhere, but it was not really static for a while.

You're assuming everyone expects to get Hug'o'Deathed. I suppose a site like the one here should expect a higher bandwidth around competition and announcement time, but for independent people who happen to get picked up on HN/Reddit/etc?

Cloudflare is free, and will take most of the hit if you can serve a reasonable amount of it yourself.

Just gotta make sure its setup to cache your html

The website is loading megabytes of images from its own domain without a CDN. R.I.P. web server.