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”
In case you missed my other posts on acquiring, maintaining, backing-up and monitoring your virtual server, here’s the complete list:
- EC2 setup : Migrate Your WordPress Blog to a Bitnami EC2 Instance
- Backups : Poor Man’s Automated Snapshots for EC2
- Monitoring : Cloudkick Monitoring for EC2
9 thoughts on “WordPress Caching For High Performance EC2 Micro Instances”
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.
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 !!!
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.
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.
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.
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.
Thanks for that Matthew! I’ve updated the post accordingly.
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.