A Quick Bit About WordPress Caching
05 Mar 2012WordPress, being a PHP-heavy, database driven CMS, can hit some performance issues. Namely, without some basic caching turned on, WordPress can be dog slow.
Working for a shared web hoster, WordPress performance can be a problem. It sort of hits the sweet spot of everything that can possibly go wrong with shared hosting: loads of php file opens, a bunch of database requests, very little that can be easily cached up stream with a caching proxy like Varnish or Squid.
So, both out of curiosity and a desire to make things better for customers, I did some quick benchmarks of WordPress with no caching, with Hyper Cache, and with W3 Total Cache.
Based off my past experience (and, really, based off of little more than a bit of speculation), I figured Hyper Cache might perform best on shared hosting. It's simple, uses disk based caching, and doesn't seem to require a lot of overhead. I speculated it would perform a bit better than W3 Total Cache (as I thought, on a shared host) the overhead of W3 Total Cache might slow it down.
I was very wrong.
I ran a couple of tests. First, a sort of low traffic test (1000 requests, 20 at a time). The details:
Test 1, Low Traffic (1000 requests, 20 at a time)
No Caching
| Metric | Time (seconds) |
|---|---|
| Average Request | 0.8 |
| Longest Request | 3.9 |
| 80% of Requests Handled In | 1.2 |
That's not so bad, but this is a pretty light traffic load.
Hyper Cache
| Metric | Time (seconds) |
|---|---|
| Average Request | 0.4 |
| Longest Request | 3.7 |
| 80% of Requests Handled In | 0.4 |
Well, that's a good bit better, isn't it? Caching, not surprisingly, helps.
W3 Total Cache
| Metric | Time (seconds) |
|---|---|
| Average Request | 0.07 |
| Longest Request | 0.3 |
| 80% of Requests Handled In | 0.09 |
Crikey. That's not just better, that's basically as fast as you can load static content. That's insanely good.
Ok, well, under low traffic load, W3 Total Cache wins. What happens when we crank it up a bit?
Test 2, High Traffic (5000 requests, 100 at a time)
No Caching
| Metric | Time (seconds) |
|---|---|
| Average Request | 1.7 |
| Longest Request | 11.3 |
| 80% of Requests Handled In | 2.6 |
As expected, performance goes down as we start getting our big traffic influx. 11 seconds to handle the longest request, and it's about twice as bad as under light load.
Hyper Cache
| Metric | Time (seconds) |
|---|---|
| Average Request | 1.8 |
| Longest Request | 15.3 |
| 80% of Requests Handled In | 3.5 |
The first real surprise: Hyper Cache basically tips over under this load. I'm not sure why this would be (maybe Hyper Cache doesn't play well with NFS), but this is bad news for making our site run quickly.
W3 Total Cache
| Metric | Time (seconds) |
|---|---|
| Average Request | 0.3 |
| Longest Request | 3.5 |
| 80% of Requests Handled In | 0.4 |
Wow. W3 Total Cache just crushes it. Sure, it's slower than it was under light load, but it's basically still performing as well as it would if it was a static site.
That's pretty unreal performance. And, that's out of the box with almost no tuning. I'm guessing if I played a bit more, I could squeeze a bit more performance out of W3 Total Cache.
There are a million other caching plugins. I'm not sure, though, that'd I'd look much further. Even if another plugin could perform better than W3 Total Cache, it can't perform that much better. Given how widely used W3 Total Cache is, meaning loads of tips, tricks, and support on the web, I'm pretty sure this is my recommended caching plugin (and something that we might start installing automatically in our hosted WordPress install at work).