WordPress Caching For High Performance EC2 Micro Instances

February 15, 2011 ~ Dan Ackerson

Chevrolet Camaro....full blown, just a few horses von SoulRider.222 bei Flickr

For the price, it’s hard to beat the EC2 Micro instance. But, if you have even a little bit of traffic, don’t expect to run a stock AMI without feeling some performance pain. After migrating this blog, we noticed that being logged in (meaning no wordpress cache hits) literally slowed the server down to a crawl. Just clicking around wp-admin a few times would drive load up to 12-13 and stuck the virtual server in 98%st. Apache connections were tweaked, mysql database settings optimized – traffic was really light (2-3 users) and the damn thing was unreachable! It was time for some PHP acceleration…

W3 Total Cache for WordPress

We switched to W3TC from WP Super Cache over a year ago. Besides offering more caching options (minify of static resources, embedded CDN setup), it’s also possible to use a combination of memcache and opcode caching. Back then, we didn’t have need of such heavy-duty, but it was nice knowing they were just a couple of clicks away.

Fast forward to 2011 – after our well-received devops series, we’ve seen some explosive growth. The continuing problems I described above had to be solved if we were to continue to grow our audience. As this system is a WordPress server, a PHP accelerator seemed the most logical solution.

APC Opcode Caching to the rescue

W3TC recommends APC Opcode caching and our Ubuntu based instance allowed us to easily install it:

apt-get install php-apc

W3TC offers a default configuration which you can append right to the php.ini:
sudo cat /opt/bitnami/apps/wordpress/htdocs/wp-content/plugins/w3-total-cache/ini/apc.ini >> /opt/bitnami/php/etc/php.ini
Restart Apache, to register the changes:
sudo /opt/bitnami/ctlscript.sh restart apache

Now, you should see the Opcode selectable in the W3TC options:

We use the “Opcode: APC for caching” setting for Page, Minify and Object caching and leave Database alone (as recommended in the fine print).

After restart, Matthias and I clicked around a bit. Wow, what a difference! Both in the front-end and wp-admin. Whether logged-in or not, the site was noticeably more performant and sluggish clicks in the backend were much snappier. It’s fun again to write posts, manage tags and scour comments for spam!

Professional Grade Virtual Computing for “Free”

EC2 setup : Migrate Your WordPress Blog to a Bitnami EC2 Instance
Backups : Poor Man’s Automated Snapshots for EC2
Monitoring : Cloudkick Monitoring for EC2

Published by Dan Ackerson

View all posts by Dan Ackerson

9 thoughts on “WordPress Caching For High Performance EC2 Micro Instances”

Pingback: Tweets that mention Wordpress Caching For High Performance EC2 Micro Instances — Agile Web Development & Operations -- Topsy.com
Joseph Scott says:

February 15, 2011 at 6:57 pm

If you are using PHP for any sort of production web site you need to be using an opcode cache. That should be a standard part of a production server setup.

LikeLike

Reply
Nabil says:

February 16, 2011 at 1:47 pm

I have a VPS that is even cheaper than an AWS Micro Instance (assuming you are paying)
RAM/Burst: 128MB / 256MB
Disk Space: 5GB
Bandwidth: Unmetered (1mbit)
Price is less than $3/mo (@Dan, email me if you want the link)
This is plenty enough for running a mid-scale WordPress Site

The AWS Micro instance have 610 MB of RAM of which – from my experience – More than 400 is already taken by other processes running on the box !!!

LikeLike

Reply
1. Matthias Marschall says:
  
  February 16, 2011 at 2:05 pm
  
  Nabil, we’re using the free offer by amazon. There are always cheaper offers around but we really like the AWS offering as we’re using it in our day jobs, too. And snapshots, failover IP addresses, and the like cannot be found at every other hosting provider.
  
  LikeLike
  
  Reply
Lazy Man and Money says:

March 13, 2011 at 7:35 am

I just switched over to the Bitnami AMI on EC2 as well. I think that it comes with the APC module included. All I had to do was uncomment the extension in the php.ini file, restart the server and tell W3TC to use it.

It took about 3 minutes and the performance improvement was dramatic. I still can’t get away with a micro instance, though. Wish there was a mid-tier between micro and small. The small instance is performing well… but it’s late on a weekend… hardly a fair test.

LikeLike

Reply
Rob Allred says:

April 6, 2011 at 7:47 pm

I was having the same problems and it was a huge bummer, your write up seems to have saved the day. I will report back with results later, but for now thank you.

LikeLike

Reply
Matthew McEachen says:

July 5, 2011 at 12:29 am

Thanks for the post — but the APC installation instructions are incomplete. Rather than just installing gcc and autoconf, you should either `apt-get install build-essentials` and then `pecl install apc`, or simpler, just `apt-get install php-apc`.

FWIW, pecl currently installs version 3.1.9, and natty (Ubuntu 11.04) installs 3.1.3.

LikeLike

Reply
Dan Ackerson says:

July 5, 2011 at 6:20 am

Thanks for that Matthew! I’ve updated the post accordingly.

LikeLike

Reply
mazhar says:

July 9, 2014 at 7:44 am

Hi Dan, nice article about WordPress caching, im currently using a lot.of ec2 micro t1 servers, now that people at aws have stopped the t1 series of servers after launching the t2 series, im planning to test them on a ubuntu stack with nginx and memcache, will try and use a few points from this post lets see how it goes.

LikeLike

Reply