Slashdot effect
en.wikipedia.org
Slashdot effect
1–10 of 74 posts
Re: Slashdot effect
#2Can someone with some more experience explain why this happens? The most basic webserver, like a TCP socket served from a C program, serving some files etc. can take tens of thousands of requests per second, per core, on reasonably recent hardware.
What's going on that's taking down these sites, really, when its not a quota limit?
Re: Slashdot effect
#3Kind of funny to find this on the front page of HN. Makes me wonder what percentage of today's HN readers didn't live through the Slashdot era. (I'm aware it's still around.)
Re: Slashdot effect
#4Kind of funny to find this on the front page of HN. Makes me wonder what percentage of today's HN readers didn't live through the Slashdot era. (I'm aware it's still around.)
yeah, it's around, but a ghost of its former glory.
Re: Slashdot effect
#5Can someone with some more experience explain why this happens? The most basic webserver, like a TCP socket served from a C program, serving some files etc. can take tens of thousands of requests per second, per core, on reasonably recent hardware. What's going on that's taking down these sites, really, when its not a quota limit?
In my experience, it's usually the database that gives out first. It's often a shared database, or one running on overprovisioned hardware.
The kinds of sites that go down when receiving unexpected traffic are usually built in such a way where they're making multiple DB requests to render each page. Or they have a dozen poorly configured perf-expensive WordPress plugins running. Or likely all of the above
Re: Slashdot effect
#6Can someone with some more experience explain why this happens? The most basic webserver, like a TCP socket served from a C program, serving some files etc. can take tens of thousands of requests per second, per core, on reasonably recent hardware. What's going on that's taking down these sites, really, when its not a quota limit?
The webserver was fast but PHP in the days before fast CGI didn't take all that much load to bring the server to its knees. And we didn't have cloud hosting at the time either so dynamic scaling behind a network load balancer wasn't a thing (and running multiple servers behind a reverse proxy was uncommon and expensive).
Re: Slashdot effect
#7Can someone with some more experience explain why this happens? The most basic webserver, like a TCP socket served from a C program, serving some files etc. can take tens of thousands of requests per second, per core, on reasonably recent hardware. What's going on that's taking down these sites, really, when its not a quota limit?
In the days of Apache 1.3 in the early 2000s for example every client session had a memory footprint (and in the case of php processes could be in the 1-2 megabytes easy). So there you are on a dedicated piece of hardware with limited RAM and a 10,000 connections hit you at the same time. And you have no caching strategy because you're an idiot child trying your best. Boom - Slashdotted
Re: Slashdot effect
#8Can someone with some more experience explain why this happens? The most basic webserver, like a TCP socket served from a C program, serving some files etc. can take tens of thousands of requests per second, per core, on reasonably recent hardware. What's going on that's taking down these sites, really, when its not a quota limit?
>
Can someone with some more experience explain why this happens? The most basic webserver, like a TCP socket served from a C program, serving some files etc. can take tens of thousands of requests per second, per core, on reasonably recent hardware.
At that time, it was quite common to start a new thread or even fork a new process per request/connection. Apache was prone to this:
> https://www.digitalocean.com/community/tutorials/apache-vs-n...
"mpm_prefork: This processing module spawns processes with a single thread each to handle requests. Each child can handle a single connection at a time. [...]
mpm_worker: This module spawns processes that can each manage multiple threads. Each of these threads can handle a single connection. [...]"
(this website also mentions the mpm_event MPM).
So, if you have ten thousands of processes or threads on some web server, this can easily overstrain the resources of the web server. Additionally keep in mind that at that time servers were a lot less beefy than today.
Re: Slashdot effect
#9Can someone with some more experience explain why this happens? The most basic webserver, like a TCP socket served from a C program, serving some files etc. can take tens of thousands of requests per second, per core, on reasonably recent hardware. What's going on that's taking down these sites, really, when its not a quota limit?
Hit a webserver with many thousands or tens of thousands of requests per second, and whatever the weakest link is will break: memory usage, CPU usage, database, bandwidth, billing, third-party service quotas...
Re: Slashdot effect
#10Can someone with some more experience explain why this happens? The most basic webserver, like a TCP socket served from a C program, serving some files etc. can take tens of thousands of requests per second, per core, on reasonably recent hardware. What's going on that's taking down these sites, really, when its not a quota limit?
Many blogs are completely dynamic and grab content out of a database on every request. The static site generation style fell out of early fashion when wordpress took over from moveable type, and didn't really return much until jekyll. Even today I think most blogs you see are mostly dynamic with the platforms using caching to avoid hitting the database every time.
Most people don't do performance tuning of their blogs because the average traffic is miniscule. This means that any configuration issues rear their heads when load happens. For example, having your max connections to the web server be far more than the database can support. Perhaps the machine could handle the load if properly configured, but no one did so because there was no need.