Sometimes you work something out, you fix something, and you find yourself thinking ‘Why didn’t I think of that before?’
This week has seen a case of that. An odd case where a caching plugin – which should speed a site up – actually slows it down.
I put a WordPress site live last week. This site has lots of custom post types, custom taxonomies and custom meta data. And there are some pretty complex queries that get run to traverse some hierarchical relationships.
So I was expecting some slow performance in places. But, for some reason, after the go-live, the back-end of the live site was unusably slow. Which was odd because the development site was fine.
The main difference between the two: the W3 Total Cache plugin.
I’ve had some issues with that plugin before, so I turned off database and object caching and…aha! Acceptable performance once again.
On reflection, this made some sense…of course that’s slower! The issue was that the database and object caching were caching to disk. Disk is slow, right. So if you’re doing some big database queries you’re doing lots of disk accesses. These are slow. Especially, I guess, on a shared server where the disk cache is probably not much use.
DB and object caching to RAM is, presumably, an advantage, but to disk I would guess that it’s only advantageous in certain circumstances.
I’m not sure if this is always an issue – i.e. database and object caching to disk are ALWAYS slower – or if it’s faster up to some tipping point. And I’m still slightly confused because there shouldn’t be any caching happening at all in the back-end of WordPress, where I was seeing the speed dropoff.
In any case, an interesting lesson learnt: turning caching on can sometimes slow things down! If you’re seeing admin-side slowness, you might also want to turn off database and object caching if they’re using disk as their storage.