Last Friday, I did a webcast as a part of the PHP TEK Webcast series. The webcast was on Caching for WordPress. We had a good turnout, and there were lots of questions about the best plugins to use for WordPress caching.
For me, every WordPress blog should have APC installed on it, hands down. APC almost doubles the response rate for WordPress by itself; APC is easy to install and freely available, stable and exceptional. Along with APC I also recommend either WP-Super-Cache or W3 Total Cache. WP-Super-Cache is great for sites that simply want to do static caching; W3 Total Cache is for sites that want to make use of S3 or other caches (like the APC User Cache).
Anyone who has worked with WordPress knows that it’s greatest strength is also one of it’s greatest weaknesses: it’s architecture. The same architecture that makes it easy to include literally hundreds of plugins also makes it slow, resource-intensive and bulky. Unlike Drupal, WordPress doesn’t have a built-in caching mechanism. What is a developer to do?
On Friday, I’ll be presenting a webcast called “Caching for WordPress.” In this webcast, we’ll talk about ways to make WordPress perform better, including aspects of caching from the application perspective and from the content perspective. There will be a discussion of caching plugins available, as well as a discussion of the WordPress API and what it offers by way of caching opportunities.
One of the things I’m always looking for is ways to improve performance with the applications I write. While a few applications are write-heavy, most are read-heavy: that is, reading the database is the predominant behavior (for example, this WordPress blog reads the database far more often than it writes to the database). Additionally, Zend Framework is (comparatively) slow at handling requests, offering a throughput of about 67 requests per second on my machine, while loading static pages came in at a whopping 750 requests per second.*
So, given this performance difference, how do we improve the performance of Zend Framework while still retaining its functionality and ease-of-use? Well, we employ caching, of course!
Now that we know we want to scale our application, we first need to make sure it’s running at peak performance. There are a number of things that we can and must do in order to ensure that the newly scaled application uses resources appropriately, runs efficiently, and, most importantly, does not require excessive resources which will amount to extra costs.
The intuitive will note that many if not most of these suggestions are performance enhancements, not scaling techniques. Why then are they in an series about scaling? Scaling is about more than just adding hardware. It’s also about making sure your system runs better. You can add lots and lots of hardware but you will someday be unable to compensate for bad queries and poor optimization. So before we start adding servers, let’s take a look under the hood.