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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.