It worked ridiculously well before I posted it to Hacker News. ;)
What? It demonstrates that Cloudfront or Fastly can handle a lot of traffic, since they'll cache just about everything if you put it in front of a static website...
The software/service you run makes most of the difference between whether it can run on standard at-home hardware or if it needs some distributed autoscaling system (when speaking of HN homepage types of traffic). Of course, if you're serving video or large images/audio, you're going to need more than a few megabytes per second of uplink. Or if your site trains neural networks custom for every visitor, that's a special case. But for regular websites...
Just back of the envelope, if it takes 200,000 instructions to handle a request and we assume 6 cycles per instruction, then that’s about 25 requests per second.
HN is roughly 50K requests over 6 hours, so that’s roughly 2 requests per second on average. I would imagine it peaks to about 25. So in theory you should be able to handle the traffic.
http://bettermotherfuckingwebsite.com/ is 20k, ignoring http overhead.
Maybe strip that to 15k after compression, and cut some content.
Still 15000/38400 <= 3 responses per second.
Add in serial parity overhead, http overhead. Might be able to sustain 2 rps with enough cleverness.
Leaves no room for bursts
[edit] never mind, you're right, assuming an 8N1 configuration - 8 bit bytes, 1 start bit, 1 stop bit, and no parity bits.
So 3kB/s, if your site is 15kB you're looking at 5 seconds per request, or 0.2 rps.
Plus overhead. I thought my original math sounded too fast.
[0] https://www.linuxjournal.com/files/linuxjournal.com/linuxjou...
I imagine it's not just the hardware limitations, but the available software. This one, for example being MS/DOS, where there were never really any serious server-side http/tcp implementations.
On the other hand, there were very busy BBS systems running on DOS where there had been time for years of various optimizations to happen.