TL;DR. My first blog post in a while, but committed to writing on cool topics. Presented at DevTO Jan 2014, download my WordPress Scaling presentation here.
I had a fun time giving a small little presentation on scaling WordPress blog and my experience on helping GrassRiots release Global Slavery Index 2013 on AWS. For those who attended DevTO, the slides for the presentation can be downloaded here.
I felt I haven’t done the topic justice given the short time, so I will elaborate on a few points.
1. Scaling WordPress is not an unique problem. It is just another LAMP-stack based application! The pressure points discussed and mitagation strategies will be similar any other PHP apps, such as Joomla, Drupal, or your own homebrew framework-based app. It just happens that WordPress blogs get slammed more frequently (legitimately or otherwise), and there are great plugins such as HyperDB and W3 Total Cache to make your scaling easier.
2. Determine your workload and nature of the site. The sites I launch are mostly read-only sites. Don’t treat my Visio diagram as gospel. If your site is highly dynamic and need write access frequently to disk and/or database, those become even greater stress points to tackle ahead of time. They are hard problems and solutions can be simple or complicated. Simple solutions include log and process later, and harder/real-time solution include cluster database or file systems (Percona XtraDB Cluster or GlusterFS are just two examples off the top of my head).
3. To AWS or not AWS. I have been a user and advocate of Amazon AWS solution since 2008 – before the days of EBS, CloudWatch, CloudFront, SES, SNS, Route53, and all the other cool solutions Amazon has brought on board to deal with the pains I put up with. Today it has the tools to enable almost anyone to run their datacentres through the AWS Console. That being said, it doesn’t mean AWS is the only solution out there, or the fastest. In fact, Google App Engine is wickedly fast and Windows Azure now boast the cheapest storage/delivery costs. I haven’t even mention smaller scale solutions such as VMFarms (managed VM), Linode (which I use personally, and full disclosure: the link is a referral link so that both you and I can get some Linode perks if you choose to join) and VPS hosting from many providers.
This can become a religious war. I have seen great implementations of Amazon AWS and some awfully dreadful ones. There will be people saying this cloud is better than that, or private cloud is more stable than public. Pick the solution that make sense both financially and technically. With Amazon, Google and Microsoft, a credit card is all you need to try them out.
4. If you are a sysadmin that is used to ordering servers, installing them on a rack, and provisioning servers in a co-location, you really have to think differently with cloud hosting. Your uptime is measured in number of instances running at any given time, not how long a server is up for. Prepare to lose not just instances occassionally, but availability zone outages once in a while. Your solution must cope!
5. A run book is often missed. Even if you didn’t write it for the release, get to it sooner or later. You will thank me when your instance crashes, got hacked, or did some insane things. Ok?
6. I have been asked – why not WordPress VIP? I have nothing but praises for WordPress VIP, but my topic was scaling WordPress on a relatively small budget, had 48 hours to release thise, and need to be torn down in about 10 days to a simple HA (High Availability) stack. I highly doubt they want my kind of business!
Leave a Reply