WordPress in the Cloud: Part 4, Performance

In the previous posts in this series, we’ve covered how to get a basic install of WordPress up and running in the cloud, how to install themes, and how to install plugins. The biggest hurdle when deploying legacy applications to the cloud is dealing with the filesystem. Fortunately, by freezing the state of the filesystem before we deploy, we can work around this. And by adapting our code to write to external data storage, we can remove our run-time dependency on the file system.

The techniques we’ve covered so far will work great for any sort of cloud environment, be that a fully managed cloud like Engine Yard, or a private cloud that you run on premises. The key detail is that your servers are virtualised, and you’re treating them like cattle instead of pets. If you do this, you’re able to benefit from fault tolerance, high availability, and flexible scaling.

But often, that’s not enough. We also need to think about ways to improve performance. And to do that, we’re going to explore the world of add-ons and third-party services.

New Relic

If we want to improve performance, it’s important to understand exactly how our site is performing. It’s hard to optimise something you’re not measuring, after all!

New Relic provides detailed analytics that allow you to monitor, troubleshoot, and fine tune your application performance in real time. An agent runs on each of your app instances and monitors CPU, memory, network utilisation, and so on. This data is sent back to New Relic where powerful visualisations and reports allow you to understand it.

Fortunately, Engine Yard provides New Relic via an add-on, meaning you can get set up in a matter of seconds. The standard plan is provided for free for all Engine Yard accounts, and a 14-day trial of the pro plan is also available.

Visit the New Relic add-on page, log in, and click Set it up to continue. If you’ve been following along with this series, or already have an app deployed on Engine Yard, you should see a screen like this:

Go ahead and click Activate to continue. Once that’s done, visit your Engine Yard dashboard, and navigate to your app. Once there, click the Apply button, and that will apply the pending configuration changes and activate the New Relic agent.

Wait for your configuration to be applied. Just for good measure, visit your blog and click around a few pages. This generates a bit of sample data so that we have something to look at in New Relic. Wait a few minutes and then go back to the New Relic add-on page. Select New Relic Dashboard from the right-hand navigation.

You should now be in your New Relic dashboard and you should see your app listed front and centre. Click on its name to be taken to the app dashboard. It should look a little something like this:

This is an overview of your app performance metrics. Feel free to click around, or read the New Relic documentation if you want to get a feel for what’s available here. We’ll come back to New Relic in the next post in this series, when we’ll be doing some benchmarking.

CloudFlare

Next we’ll look at caching. As you may have heard, caching is very important for WordPress if you want to run a high-performance site. There are lots of options available to you, but you need to be careful about how the caching is being done and whether that’s compatible with the cloud. WP Super Cache for instance, uses the filesystem to store cache files. That will work to a certain extent, but it does mean that each application instance has to manage its own local cache, which is suboptimal.

Instead, we’re going to use a third-party service called CloudFlare to manage our cache for us. CloudFlare also provides a number of other benefits, such as distributed denial-of-service (DDoS) protection, an application security firewall, request analytics, network request optimisation, and SSL. It even comes with a built-in Content Distribution Network (CDN) to speed things up for your end-users. Best of all, the starter plan is completely free!

A quick visual overview:

Let’s start by installing the CloudFlare WordPress plugin. This ensures that WordPress is configured optimally to work with CloudFlare. It also means that whenever you mark spam on your blog, that information is fed back to CloudFlare so that you’re getting the best threat protection possible.

Start your dev server:

$ php -S 127.0.0.1:8080 -t ./

But wait! When you do this, you might get an error message from WordPress telling you to upgrade the entire installation. This can happen when the whole install is out of date. Just in case this happens to you, let’s take a little diversion and shave that yak. It also gives us a perfect opportunity to revisit our method of freezing filesystem state.

Shave That Yak

We put our current task on hold, and switch to upgrading WordPress. The WordPress side is easy: just follow the instructions like normal as they appear in your WordPress admin interface. Once you’ve finished upgrading, go to the console again and use Git to see what changed:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

  modified:   license.txt
  modified:   readme.html
  modified:   wp-activate.php
[...]
  wp-includes/js/tinymce/tinymce.min.js
  wp-includes/js/wpdialog.js
  wp-includes/js/wpdialog.min.js

no changes added to commit (use "git add" and/or "git commit -a")

Check through the list of changed files to make sure you’re happy, and then add all the changes to Git, and commit back to the repository:

$ git add -A
$ git commit -m 'Upgrade to WordPress 3.9.1'
[master ecadd6d] Upgrade to WordPress 3.9.1
 842 files changed, 87356 insertions(+), 70984 deletions(-)
 create mode 100644 wp-admin/css/about-rtl.css
 create mode 100644 wp-admin/css/about.css
 create mode 100644 wp-admin/css/admin-menu-rtl.css
[...]
 create mode 100644 wp-includes/js/wpdialog.min.js
 rewrite wp-includes/js/wplink.min.js (100%)
 rewrite wp-includes/ms-settings.php (74%)
$ git push

Now visit your Engine Yard dashboard, navigate to your app, and select Deploy to redeploy your code. Once that’s done, visit your production blog and try to log in.

You should see something like this:

Don’t worry! This is entirely normal. WordPress has detected that you’ve updated your files but the database has not been upgraded. So go ahead and click Update WordPress Database. You should be presented with a screen telling you that everything worked.

Congratulations. You just upgraded WordPress in the cloud! This exact same process can be used for updating themes and plugins.

Back On Track

Okay, so you should have a fully up-to-date WordPress install both in production and on your local machine. Visit your dev site, log in to the admin interface, and navigate to Plugins, Add New. Type “CloudFlare” into the search box and hit Search. Locate the CloudFlare plugin and select Install Now. Once the confirmation screen pops up, select Activate Plugin.

Once that’s done, check your local filesystem to see what changed, add the files to Git, commit, and push back to your repository. Log in to your Engine Yard dashboard, navigate to your app, and select Deploy to redeploy your code. Once that’s done, visit your production blog and log in. Select Plugins and find the CloudFlare plugin. Click Activate again, to activate it on your production site.

Once that’s done, select CloudFlare on the left-hand nav, under Plugins. At this point, we need to create a CloudFlare account so that we have details to configure our WordPress site with.

If you haven’t already, head on over to CloudFlare and register for an account. You’ll need to set up some custom DNS before you add your website, as CloudFlare will not allow you to add the Amazon Web Services (AWS) URL of your application master directly.

Follow the instructions on screen, and when told to do so, update your domain so that you’re using CloudFlare’s name servers. This is the key to how CloudFlare works. All traffic is routed through CloudFlare’s infrastructure, and only passed through to your application servers when it is necessary and safe to do so.

While you wait for the name server records to update (which might take up to 24 hours) you can log back in to your production WordPress admin and configure your CloudFlare settings. Configure your domain name as you configured it on CloudFlare. If you want to be able to turn on development mode, you can also provide your CloudFlare API key and API email, which is is available from your CloudFlare account page.

If everything worked, you should see a screen like this:

Congratulations again. You have a working CloudFlare configuration. This means that any external traffic is going to hit the CloudFlare caches before it reaches your blog. This should take a significant amount of load off your app, and should improve site performance.

Conclusion

In this post we used two third-party solutions to help us improve the performance of our site. We set up New Relic, which allows us to monitor the real time performance data of our app, giving us crucial insight into how our app is performing under pressure. And then, as a preventative measure, we put our app behind an awesome accelerator cache.

In the next post in this series we’re going to take a look at exactly what sort of performance gains you can expect from a setup like this. We’ll benchmark our site before and after the addition of CloudFlare, and we’ll use New Relic to get a better look at what’s going on behind the scenes.

Have you used app performance tools in production before? Do you have any experiences to share? Is there anything else you’d add to a WordPress setup in the cloud to get maximal performance?