Optimizing your WordPress site with W3 Total Cache to handle traffic

In my previous post, I walked you through setting up WordPress on Amazon Web Services (AWS), using an EC2 micro instance with Ubuntu and NGINX with a separate RDS micro instance running MySQL.

Recall the AWS Architecture image I created that showed how we were going to setup the WordPress site?

AWS Architecture
Proposed AWS Architecture

Each zone consists of an EC2, RDS, and S3 instance.  So let’s spin up an S3 instance in the Oregon zone to complete the package.  Create a new bucket and call it whatever you want, but it needs to be something that someone else in that zone hasn’t used.

S3 Instance
S3 Instance with a unique bucket

Now, there are multiple ways to utilizing S3 with WordPress, but we’re going to use the W3 Total Cache plugin to handle multiple things.  Before we can use the plugin, we’re going to have to make sure that everything on the server is setup to support it.

Before we begin though, let’s take a quick break and do a quick load test on the server, but we can’t test load on a blank WordPress site, so lets get some test blog posts.  I used this websites test posts and supplemented lots of images.  You can download my test post file here.  After you have imported the test posts and images, let’s head over to http://loadimpact.com and run a test on our server.  After the load impact test is finished, you can also run a test on http://blitz.io.

Initial Load Impact test on WordPress on AWS/NGINX
Initial Load Impact test on WordPress on AWS/NGINX
Blitz.io test on WordPress running on AWS/NGINX
Blitz.io test on WordPress running on AWS/NGINX

What do these tests tell us?  The first one from Load Impact shows us that even with 50 concurrent users on the site, the load time of the site remains consistently at around 400ms.  The Blitz IO test shows us the WordPress site can handle approximately 127k hits/day or about 1 user/sec.

Pingdom.com is also a very useful site.  In addition to their alerts, they have a great waterfall tool that shows all the elements on a page and how long each one takes.  http://pingdom.com.

Pingdom Waterfall on WordPress AWS/NGINX
Pingdom Waterfall on WordPress AWS/NGINX

Results for the WordPress site straight out of the box aren’t that bad.  We’ll run these tests again after we make some modifications to the site and see how they improve.

Step 1 – W3 Total Cache Plugin for WordPress

Login to your WordPress site by going to http://YOUR_EC2_ELASTIC_IP/wp-admin and click on Plugins from the left navigation.  Then click on “Add New” from the upper left of main screen and in the search plugins box, type in W3 Total Cache.  It should be listed as the first search result, go ahead and install the plugin and activate it.

Now, you’ll notice that on the left hand navigation, you’ll have a “Performance” section at the bottom.  This is the W3 Total Cache Plugin settings tab, so click on it and let’s configure it.

1) Page Cache – click on “enable” and select APC since we’ve enabled it on our servers.
2) Minify – click on “enable” and then for Minify mode, select Manual so we can specify the S3 bucket for a CDN.  For the Minify Cache Method, select APC once again since our server is configured for it. For HTML minifier, leave it at default and choose default for JS and CSS.
3) Database Cache – click on “enable” and select APC.
4) Object Cache – same as above.
5) Browser Cache – same as above.
6) CDN – click on “enable” and select “Amazon Simple Storage Server”
7) Under Miscellaneous – leave everything as default, but you might want to take advantage of using the Google Page Speed dashboard widget.  You’ll have to enable it on your Google account. Click on the APIs Console link from the plugin page and you’ll be taken to your Google account, find the Google Page Speed API and enable it.  Then copy the API key and paste it into the field.

When you hit save all settings, the page will refresh and you’ll see notices at the top.

W3 Total Cache Plugin notices
W3 Total Cache Plugin notices

The red one says that you must provide the Access Key, Secret Key and Bucket for the CDN.  So lets go back to your AWS Console to get that information.  When you are at your AWS Console, click on your name in the upper right and select Security Credentials.  Scroll down a little on the page and you’ll see the Access Credentials.

AWS Access Credentials
AWS Access Credentials

Back on your WordPress blog, click on the CDN link under the Performance section of your navigation.  Now fill in the Access Key ID, Secret Key, and Bucket Name.  I’ve selected to always use HTTP to reduce the SSL latency.  Now click on “Test S3 upload” and you should see a Test Passed message.

CDN Credentials
CDN Credentials

Click on Save all Settings and now let’s clean it up.

At the top of your W3 Total Cache page, you’ll see a bunch of notices.  Let’s take a look at these.

1) Export the Media Library – this will move all your images and media files that you uploaded to the new S3 bucket.  Click on it and new window pops up and you’ll see how many files are in your media library.  I had 8.

Media Library export
Media Library export

2) WP-Includes – go ahead and click on that button to generate a new pop-up window.  I have 298 files to move to the S3 bucket.

WP-Includes files export
WP-Includes files export

3) Click on Theme files and export those.  Click on Custom files, but you shouldn’t have any of those yet.  After you are done, you can hide the message.

4) Deploy – Click on this to make all the changes on your production site.  All links to images and external files will be modified in your post to reflect the S3 location.

Let’s do a sanity check by loading your website and viewing the properties of an image file.

Verifying the S3
Verifying the S3

Now, lets re-run those 3 tests.

1) http://loadimpact.com – the updated report shows that the W3 settings helped improve the response rate of the site when it was loaded with 50 concurrent users.  The response rate from 400ms after the initial install to 100ms.  A very good improvement in regards to the effort put in.

Load Impact test after installing W3 Total Cache
Load Impact test after installing W3 Total Cache

2) http://blitz.io – the updated report from Blitz.io shows the site is a bit more responsive and is able to handle about 157k hits/day, up from 128k hits/day before installing and configuring W3 Total Cache.

Blitz.io testing after W3 Total Cache
Blitz.io testing after W3 Total Cache

3) http://pingdom.com – the updated waterfall report shows that the site load time went from 1.16s to 2.01s.  This is due to the latency from S3 on the initial requests of the image and media files.  There is a trade off here, of the site being ultra responsive versus being resilient.

Pingdom Waterfall report after W3 Total Cache
Pingdom Waterfall report after W3 Total Cache

So by installing a simple WordPress plugin, we were able to optimize the site to handle more traffic and be a bit more resilient.  Next up, let’s take a look at enhancing the WordPress dashboard to make monitoring the site easier.