WordPress Tips: Go With a Clustered Approach

 

We have been using WordPress for some time now (6 years and counting), and though we’ve had some bumps on the road, we are generally happy with it (except for the HTML editor, of course). Still, we’re happy to pass on WordPress tips when we think of them.

Back in the day, we ran everything on a single server but due to growing traffic & traffic spikes after big releases, plus the unstable nature of computer hardware, we’ve needed to go with a clustered environment instead. You know, the chaos monkey is always after you!

We made the switch about two years ago, and I think it makes sense to share the approach we took. When it comes to the LAMP stack there are 1000 ways how to solve a problem. Why not document our approach! Also when you google for WordPress cluster you find a lot of results but most are not so much about concrete solution but rather general discussions about clustering. So far the best article we’ve come across is Clustering WordPress on Amazon EC2 micro instances. 

Tips for Clustering in WordPress 

WordPress doesn’t have out of the box support for clustering, and there are parts of WordPress that freak out a little once it is running on multiple nodes. Besides some features, the product itself is perfect for clustering – it’s stateless. Also one more pain point is plugins, which might also freak out. No worries, we’ll document the shortcomings and the solutions. For the cluster we chose nginx as the load balancer and Apache with PHP for the WordPress nodes.

We also chose to use sticky sessions, meaning that a person visiting our website from some remote IP would get the same server from the cluster to answer. We booted up one server for the load balancer (lets call it LB) and two servers for WordPress nodes, lets call them server-1 and server-2. We also booted up a RDS instance (Amazon version of hosted MySQL). This became our storage for the servers. We configured WordPress on server-1 and server-2 and made them connect (DB wise) to the RDS server. Something like this below:

Upgrading WordPress and Plugins

WordPress is actively developed and sees a new release every now and then; however, now that you have a multi-node setup the upgrade is not that easy anymore. Our solution for WordPress and plugins is that we have all the source code under version control in a Mercurial repository.

We run the upgrade on one of the nodes, the master one and then commit and push the changes to the central repository. The other nodes fetch the code from central repository. In reality, we actually have more servers than just two. We also have development servers to test our own custom development before going to the production system. We do all the upgrades to WordPress on the development servers, and once we mark a change-set safe, the production nodes download the code with Mercurial.

Running WordPress in a Cluster

Running WordPress in a cluster is not a straightforward thing to do and there are certain aspects that you have to think about before doing this. The main issues we had were:

  • media uploading
  • updating WordPress and our plugins
  • HTTPS editing

Media uploading can be achieved by 3rd-party location syncing, you can use Amazon S3 to synchronise your media. WordPress and Plugin upgrades can be also synced and distributed, which is why here we chose Mercurial as a version control system instead of S3. HTTPS editing on the other hand was achieved with some load balancer configurations. Of course there are 1000 ways how to approach these problems.