This just shouldn't happen: the server is quite fast, has unlimited bandwidth and is nowhere near capacity storage-wise. Why should it keep falling down?
And then, via Daring Fireball, I found this Coding Horror article—Behold WordPress, Destroyer of CPUs.
I've been thoroughly impressed with the community around WordPress, and the software itself is remarkably polished. That's not to say that I haven't run into a few egregious bugs in the 2.5 release, but on the whole, the experience has been good bordering on pleasant.
Or at least it was, until I noticed how much CPU time the PHP FastCGI process was using for modest little old blog.stackoverflow.com.
For context, this is running on a Windows Web Server 2008 virtual machine with a single core of a 2.13 GHz Xeon 3210 entirely dedicated to it.
This is an incredibly scary result; blog.stackoverflow.com is getting, at best, a moderate trickle of incoming traffic. It's barely linked anywhere! With that kind of CPU load level, this site would fall over instantaneously if it got remotely popular, or God forbid, anywhere near the front page of a social bookmarking website.
For a bare-bones blog which is doing approximately nothing, this is a completely unacceptable result. It's appalling.
And now that I think about it, my server only really started crashing regularly when I started to install WordPress blogs on it (for a variety of other reasons, mainly to do with design, I wouldn't touch WP with a bargepole if I had the option).
And, thinking about it further, the server has been crashing proportionately more, the more WP blogs I have installed. And now, I'm pretty sure that I know why.
There is a solution, which I have just implemented on Timmy's blog and I shall try to roll out to the others when I have time.
As evidence of what a systemic problem this is, there's an entire cottage industry built around shoehorning better caching behavior into WordPress. Take your pick: WP-Cache, WP-Super-Cache, or Bad Behavior.
It is WP Super-Cache that I have installed, and I shall be monitoring how it goes. The results should be good, as Jeff illustrates.
Does it work? Does it ever. Here's what CPU usage looks like with basic WP-Cache type functionality enabled:
But this is a little known problem, right? Wrong.
I'm not alone; just do a web search on WordPress CPU usage or WordPress Digg Effect and you'll find page after page of horror stories, most (all?) of which are solved by the swift and judicious application of the WP-Cache plugins.
Thanks a fucking bunch, WordPress; are you going to do anything about it?
It's not like this a new issue. Personally, I think it's absolutely irresponsible that WP-Cache like functionality isn't already built into WordPress. I would not even consider deploying WordPress anywhere without it. And yet, according to a recent podcast, Matt Mullenweg dismisses it out of hand and hand-wavingly alludes to vague TechCrunch server reconfigurations.
Well, thanks a fucking bunch, WP team. You cunts.
A default WordPress install will query the database twenty times every time you refresh the page, even if not one single element on that page has changed. Doesn't that strike you as a bad idea? Maybe even, dare I say it, sloppy programming?
Twenty fucking times? That's not sloppy programming: that's nearer to a DoS attack on my bloody server.
And because WP programmers can't be arsed to fix this, all of my customers suffer when the server goes down and I can't actually go anywhere without constantly having to check that my machine hasn't crashed?
You selfish bunch of fucking cunts.
What I just don't understand is why, after all these years, and all these documented problems, WordPress hasn't folded WP-Cache into the core. If you're ever planning to have traffic of any size on a WordPress blog, consider yourselves warned.
I'm warned. And armed. And about to spend a few hours trying to install what should be an unnecessary plugin into my hosted WP blogs.
And, by the way, I'm also really fucking annoyed...