hosting tech

WordPress and caching

WordPress is one of my absolutely favorite pieces of software. It’s so simple, relatively intuitive, and knows exactly what its goal is. It’s elegant, one might say. For all of its splendor, however, it can be a serious resource hog. The fact that it is database driven means, given the right conditions, a WordPress site could cause significant load on the server that hosts your blog. You don’t understand what that means, you say? Well, allow me to explain it to you.

Every time you load a website, hosted anywhere on the planet, you are loading a series of files. Sometimes those files can reference other files, or (as in the case of a WordPress blog) databases. A database, as defined by wikipedia, is “an integrated collection of logically-related records or files consolidated into a common pool that provides data for one or more uses.”

While I could write an entire entry about the merits of good database organization (and I may later) suffice it to say: when you load the front page of, you hit the database for this blog (at a quick count in the source code) no less than 15 times, and load at least 5 different files. If my site were popular, with a modest 30 hits-per-minute (hey, a girl can dream!), my server would be serving 150 files, and getting content from the database 450 times, every minute.

That’s a lot.

The reason that’s a lot is not memory use, and not CPU use (though those might both come in to play depending on the plugins used on the site), the reason you will start to see problems with that is a thing called Disk I/O Wait.

Without getting too technical: Disk I/O (or Input/Output) is the writing to, and reading from, a hard-drive. No matter how awesome or fast your harddrive is, it can still only do one thing at a time: specifically reading or writing to a single file. This is where the ‘wait’ part gets involved. The more disk I/O is occuring, the longer a programs wait times become. How long, depends on a lot of things, but the things I’ve seen effect it most:

1) Extremely active databases.
2) Poorly designed slightly active databases.
3) {a large group of other things}
4) Failing drives.

So… with all of this potential fail, how do you keep your server stable, your site up, and your wallet *not* empty?

Enter Caching!

Caching (from wikipedia): “In computer science, a cache (pronounced /?kæ?/ kash) is a component that improves performance by transparently storing data such that future requests for that data can be served faster. The data that is stored within a cache might be values that have been computed earlier or duplicates of original values that are stored elsewhere.”

That’s right! All of the sudden that 150 file and 450 database reads go down to 1: the page that was generated previously and stored in cache. I cannot adequately express how much of a difference caching makes. I have seen servers serving a single site that got Dugg go from repreatedly crashing to serving 7Megs of traffic, just by enabling caching.

While WordPress doesn’t have any built-in caching, a number of 3rd party developers have created caching plugins for WordPress which offer various levels of simplicity and control.

WordPress SuperCache is the plugin that this site uses. You can control how often the cache refreshes and who gets to see cached pages through the wp-admin interface.

From the site:



1. Users who are not logged in.



There are more than these two out there, but the beauty of the majority of them: they are generally all easy to install, and will make both you and your webhost happy. When your site gets dugg, or get slashdoted, or gets posted to twitter by Neil Gaiman, and threatens a #NeilWebFail, your caching plugin will save your site, your stress level, and your uptime.