Last week, I went a little upgrade-crazy with the VPS that hosts this site. With SPDY 3.1 support in nginx 1.5, I upgraded. I also bumped PHP from 5.4 to 5.5.
The latter change is significant because PHP 5.5 drops support for APC, and I was using APC for both opcode caching at the PHP level and object caching at the WordPress level (thanks to Jaquith’s plugin). Since I’d lost my object cache, I’d also lost my page cache because I was using Batcache. Nice job, Erick.
Almost a year ago, I contributed two small changes to Eric Mann’s WordPress Redis Backend plugin. With Redis already running on my VPS for reasons unrelated to WordPress, it seemed an obvious choice over competing persistent caching options.
I spent some time updating Eric’s plugin (see https://github.com/ethitter/wordpress-redis-backend/commits/master for the fun I’ve had) and sent a massive pull request back with my changes. I’ve been using the plugin for a few days now without incident, though I wouldn’t rush to switch over just yet unless you’re adventurous. I’d watch Eric’s repo if you’re interested in what comes of my efforts.
4 thoughts on “Redis Object Cache for WordPress, the Accidental Effect of PHP 5.5”
There is still APC support to a lesser extent in 5.5, with https://github.com/krakjoe/apcu which provides APC without the opcache. All the apc_store, apc_fetch functions are there, thus avoiding having to do a lot of the code changes on upgrade
True. I wasn’t aware of that option ahead of time, but would have been had I bothered to Google. 🙂 I may have taken the APCu route as it would’ve been, as you noted, a simpler transition.
I’d already contributed a bit to the Redis object cache plugin, and had Redis running for unrelated reasons on the server, so it seemed like a fun challenge. I was also in the mood to code something, so the timing was good. I’ve had an interest in caching and scaling WordPress for a while, which particularly drew my interest to completing the plugin.
I’m just curious, any particular reason why you didn’t go the memcached way? Seems really popular these days. I know, you already had Redis on the VPS “lying around” but still 🙂
Also, would you consider Varnish a viable solution for caching the whole page instead of “just” objects?
As I noted in my reply to Paul and you also mentioned, the choice of Redis over Memcache was largely driven by the presence of Redis on the server anyway. I’d contributed some small patches to Eric Mann’s Redis object cache plugin already, so the need for a new object cache seemed a good opportunity to build out the plugin.
I have no personal experience with Varnish, but it isn’t my first choice for full-page caching in WordPress. With an object cache in place, I prefer to use a plugin like Batcache to cache rendered pages in the object cache (though that plugin’s description mentions Memcache, it works with any proper object cache). Doing so keeps all of the caching backend in one system, and page invalidations are a lot easier when they can be done from within WP using the hooks available and a
wp_cache_delete()call. In general, I find an integrated cache solution easier to manage and better to program for given the flexibility having access to the cache system from within WordPress provides.
Comments are closed.