Wordpress - Destroyer of CPUs

Lately I've been delving into the WordPress ecosystem, as it seems to be the most popular CMS platform around at the moment. I've built several sites with it so far. In the process, I've gotten quite comfortable with the setup, interface, and overall operation of WordPress.

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 newest 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 a modest little website.

This is an incredibly scary result; this website 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 site which is doing approximately nothing, this is a completely unacceptable result. It's appalling.

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. The caching add-ins don't work very well under IIS because they assume they're running on a *NIX platform, but they can be coerced into working.

Does it work? Does it ever. Here's what CPU usage looks like with basic WP-Cache type functionality enabled:

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.

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.

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?

I understand that users may have umpteen thousand WordPress plugins installed, all of which demand to change on every page load. Yes, the easiest path, the path of least resistance, is to mindlessly query the database every time you're building a page. But I cannot accept that a default, bare-bones WordPress install hasn't the first clue how to cache and avoid expensive, redundant trips to the database.

It's frustrating, because caching is a completely solved problem in other programming communities. For example, the .NET framework has had page output caching and page fragment output caching baked into ASP.NET for years.

I sure am glad I started this blog with Ghost, but I shudder to think of the number of times the Failed Machine web server would have been completely incapacitated by the naive -- no, that's too tame -- brainlessly stupid dynamic rendering approach WordPress uses.

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.

Just a few days before this post; a friend pointed out that the Query Cache is extremely important to performance, and for some reason it defaulted to off (zero size) on my installation. You may also want to look into innotop and mysqlreport to ensure that all your MySQL caches are functioning at appropriate levels. It is badly needed.