Tech Note: Cloudbusting

My blog runs on a piece of software called WordPress. I love WordPress; it’s well designed, easy to use, easy to maintain. It’s good for serving blogs but it’s also great for creating small simple web sites. I’ve recommended it to a lot of organizations for their web sites, and I’ve helped several of them set those sites up.

That said, WordPress has a reputation for falling over under heavy load. It creates each page on demand, which is very taxing compared to just having the pages sitting there ready to go. This hasn’t been a problem for me given that my site’s not very active but I’m about to do something which (if it’s successful) will bring in a lot of traffic for a short period of time, and I don’t want the site to fall over during that time. I don’t want it to neilwebfail.

There are a number of ways to try to fix this problem. I’m currently trying out a caching plugin for WordPress called W3 Total Cache. W3 Total Cache uses a variety of methods to improve the performance of a WordPress web site, from Javascript and CSS combining and minifcation to database and page caching to using a CDN (Content Distribution Network).

The CDN is the most interesting part to me. With a CDN, you put files on servers (the currently hot “cloud”, though people have been doing this since before the cloud label existed) designed to get them to browsers as fast as possible. The servers may replicate the files so that they are as close (in a network topological sense, not a physical sense) as possible to the browsers that are trying to reach them.

I’ve been interested in using a CDN for some time but none of the projects I’ve been working on have needed one. They’ve all been low load, local sites. But a CDN may help my blog survive a #neilwebfail, so this is a great change to try it out.

I’ve been using Amazon’s S3 storage for some time for other projects. They also offer a service called Cloudfront which turns S3 into a CDN. W3 Total Cache knows how to work with Cloudfront, so this is what I’m turning on as of now. It looks like W3 Total Cache only uses Cloudfront to store media, CSS and Javascript files, not the actual web pages itself, which it will still aggressively cache on the server. That still helps off-load traffic from the server and helps deliver those files to browsers much quicker.

When this experiment is done I’ll report back on how it went (assuming I get to really test it the way I’m hoping to). A great thing about Amazon is that they only charge for actual use, so if I don’t see a burst of traffic I won’t be paying for service I’m not using. I’m very curious to see how much it will actually cost to survive a burst.

Two tools for helping with setup:

1. Panic’s Transmit (web site, with a free trial; Mac App Store) application for MacOS X. Besides being a very handy (S)FTP application, Transmit can talk to Amazon S3, so you can inspect and manually update what’s being stored there if you need to. If you’re not willing to pony up for Transmit (and in my opinion, it’s well worth the cost), you try Cyberduck, which is donation-ware (and also available through the Mac App Store).

2. Firefox’s Firebug and Chrome’s debug console. Use Google PageSpeed with them to see how your site is measures up.