53 ms·
Another idea: if your content is ~5kb text, then serve it to whoever asks it. If you don't have the bandwidth, try to make it smaller, static, and put it on the
by bmacho 1y ago
Another idea: if your content is ~5kb text, then serve it to whoever asks it. If you don't have the bandwidth, try to make it smaller, static, and put it on the edge, some other people's computers.
- foul 1y agoThe fun and terrible thing about the web is that the "rockstar in temporary distress" trope can be true and can happen when you expect it the least, like, you know, when you receive a HN kiss of death. You can surely expect that a static content will be static and will not run jpegoptim on a image at any given hit (a dynamic CMS + a sudden visit from ByteDance = your server is DDoSed), but you can't expect that any idiot/idiot hive on this planet will set up a multi-country edge caching servers architecture for a small sized website just in case some blog post will hit a few million visits every ten minutes. That can easily take down a server even for static content. I concur that Anubis is a poor solution, and yet here we are, the UN it's using it to weather down requests.
- account42 1y agoPopularity-based traffic spikes tend to be very temporary and should not be something smaller sites concern themselves with.
- foul 1y agoMy example was quite vapid, but you shouldn't concentrate on that use-case. Small doesn't always mean "neglectable infos", while scrapers are always stealing CPU time.
- account42 1y agoExactly, if you have the bandwidth to serve your proof of work scripts and check the results then you also have the bandwidth to simply serve properly optimized content.