Slashdot effect

Perhaps the best benchmark for the maximum potential traffic of the community at that time comes from a Slashdot post by Rob Malda (CmdrTaco) on September 14, 2001 (https://news.slashdot.org/story/01/09/13/154222/handling-the...), detailing the site's traffic following the 9/11 attacks. This load on Slashdot itself represents the full attention of the userbase and was higher than the site normally experienced:

Normal Load: 18–20 dynamic page views per second.

Peak Load: 60–70 page views per second.

Daily Volume: 3 million page views (up from a daily average of 1.4 million).

To handle this higher load, Slashdot itself had to disable dynamic content and serve static HTML to survive this load. Their database could not handle the query volume.

A typical "Slashdotting" pushed 5 to 10 Mbps of traffic. Since many sites were hosted on T1 lines (1.5 Mbps), the pipe was instantly clogged, resulting in 100% packet loss for legitimate users.

I remember when Slashdot broke because they used an Unsigned Mediumint counter for a primary key and finally overflowed it with 16 million comments over the life of the site on Nov 6, 2006.

It was a different time back then when we still measured our installed RAM in megabytes.

It was also the year of the Linux on the desktop.

Or because once you get the max requests per sec out of a machine, you can often get a second machine to double rps for much cheaper than a machine that can do double the rps.

In the 20-30 year old time frame, easy to obtain servers are one to two cores, often one core per socket. SMP scalability was not a given; you could certainly run on SMP and get benefits, but depending on your load you might not get anywhere close to 2x the throughput.

A single core webserver serving static files isn't going to be much faster than 1 ms per file, so you're around 1k rps. And that's assuming you files are all cached. If you do dynamic pages, they're more likely to start closer to 10 ms, and can easily be much longer, so 100 rps is a good target.

But, if your pages are sizable, you can easily run out of bandwidth and then everything gets slow and you can hit too much concurrency and things get worse. A T3 was a very good connection back then, and it was 45 mbps. 1000 rps of 50k images is going to fill up your T3.

Load balancing, done right, is very scalable for typical http loads where client sends little and server sends lots. Direct Server Return means the load balancer only sees the traffic from the client, which significantly reduces the effort for the load balancer. Of course, you can't do a lot of fancy things with DSR, but that means your balancers aren't overloaded with fancy things. If your DSR load balancer fails, you can fail over to DNS round robin.