34SP.com Blog

WordPress Hosting switches to Redis

When our WordPress Hosting plan came out of beta testing, our stack had been through rigorous testing, with each component not only tested on its own but compared to alternatives.

At the time we tested Memcached and Redis, with both giving very similar levels of performance and stability.  At the time a choice was made to use Memcached over Redis as it was ultimately simpler and fitted in with the ethos of single responsibility.  Memcached also had the advantage of familiarity as our staff have used it on other projects.

Move forward a few months, and we believe we made the right choice.  That being said, we recently made the decision to change over to Redis and would like to take this opportunity to explain that choice.

Whilst we did have a few interesting edge cases, the main motivation for a move to Redis is a precursor for an upgrade to PHP7.  Until recently the main reason for not upgrading PHP has been that Memcached support in PHP7 is poor.  Redis on the other hand has good support and mature client in PHP7.  The ability for us to have slightly more control and configuration has come really as an added bonus.

 

What has changed?

From client’s perspective, nothing has changed.  The object cache is still being put into a KVS (Key Value Storage) system, we have just swapped out the backend for an alternative.  In a few niche circumstances you might even notice some performance improvements.

Behind the scenes this was a carefully planned update and switching out a major component of our stack caused more then a few raised eyebrows within the office.  Prior to switching we needed to work out if any current clients were using Memcached separately from our object cache. We had two scenarios for deployments if we did find people using it and would have reached out to affected clients before making any changes.  Through a combination of searching codebases of all clients for specific code implementations and interrogating Memcached for unknown keys, what we actually found were only a couple of custom implementations and in both cases they were staff members’ code!

With confidence that we could actually do a straight swap, we began what is akin to the trick of pulling the tablecloth off the table and leaving all the tableware in place.

The first stage was to install both Redis and the relevant PHP module, as well as placing our configuration onto all containers.  Once this was completed and we confirmed every container was running Redis, we switched the object-cache.php in all containers and monitored everything as Redis started populating with WordPress objects.

Whilst Memcached is still running on containers, the contents of the cache will be slowly expiring.  Another build will be run in a week’s time to stop and remove Memcached from the containers, freeing up a little bit of memory on each.

We are pleased to say that the whole process has gone without a hitch and no issues have been reported on any containers.

The upgrade to PHP7 will be a lot more involved.  We could only switch from Memcached to Redis in the way we did because we had a reasonable level of confidence that it would not cause any issues.  The move to PHP7 will be staggered and initially we will have to provide a convenient way to switch between versions 5.6 (as is used now) and 7.  This work is ongoing but expect a post soon with timeline for the PHP7 upgrade.

If you have any questions or worries then please do get in touch with our support team who will be more then happy to help.