Caching and Why We Need It
Ever since the creation of interpreted languages and the birth of dynamic web content, developers have been on the lookout for tools, workarounds, and extensions in search of a solution for a solution to bring maximum performance to the world of dynamically-generated web pages.
Perhaps the simplest, most straight-forward, and most effective of these solutions is the caching technique. In most caching implementations, the dynamic content generated by user requests to a particular URI on a server trigger the caching mechanism which then stores the generated content in a "storage facility" somewhere. Future requests to the same URI retrieve the stored content rather than spend time and effort re-creating the response.
The most-popular method of caching involves the archiving of the complete HTML response generated by the webserver and then stored as a static content on the hard drive for retrieval at a later date (usually with some mechanism responsible for expiring the content upon certain actions or after a set amount of time).
The "Object Cache"
But there’s a second form of caching where only "data" or objects that the server creates during the process of generating the response are saved. For instance, if the front page of a blog has a list of the last five posts, a blogroll, and links to the latest comments; the server can individually cache each of these in raw data format so that they can be retrieved one-by-one for future requests. WordPress has used this form of "object caching" ever since version 2.0, and it has been a rather effective measure when it comes to getting that last bit of performance and oomph out of a server.
Object caching is more flexible than full-content HTML caching because it allows for easily-invalidating only portions of cached content when they change. For instance, if a new comment is made on your blog, there is no reason for the list of recent posts to be renewed. And it makes it easier to piece together new request from older, cached data (e.g. a "single post" page on the blog may also contain a list of recent comments).
WordPress and the Object Cache
WordPress has had an in-built object cache implementation ever since WordPress 2.0 was released some years ago now. By default, it would store the results of certain SQL-dependent sections of the code to the object cache; which was a pluggable caching library delegated with the task of storing and retrieving objects by name (technically, key). In the stock WordPress implementation, the object cache stores these bits of data in the form of files on the hard disk in a temporary directory.
The Problem with File-based Object Caching
With the release of WordPress 2.0, it turned out that WordPress’s basic filesystem object-caching implementation was becoming a bit of a problem for certain users on shared hosts (which make up the largest portion of the WP userbase) as a result of increased levels of I/O activity. That and the fact that the performance benefits of a file-based object cache on a shared host were negligible resulted in WordPress 2.1 switching the behavior of the object cache to "disabled" by default. (After all, pulling data from the hard disk isn’t very different from what the database does in the first place!)
At around the same time, the first extension to the WordPress object-caching feature was released by core developer Ryan Boren. Ryan’s extension allowed for WordPress’s object cache to store data in the memory instead of on the hard drive, taking advantage of the memcached PHP extension. This extension followed with an APC alternative by Mark Jaquith, an eAccelerator implementation, and an XCache-integrated solution (the latter two by ourselves at NeoSmart Technologies).
The Demise of the File-based Object Cache
With these memory-based caching extensions, the drawbacks of WordPress’s stock filesystem object-caching implementation were no longer a necessary obstacle. While these "plugins" (extensions to the WP object cache) were generally geared towards dedicated servers rather than shared hosts as a result of the server-configuration requirements; the original file-based caching implementation hadn’t been very "shared-host"-friendly either.
As a result of a number of factors, starting with the fact that the WP file-based cache was disabled by default and the availability of other, better-performing alternatives; the built-in file-based cache was no longer a priority and fell into a state of dis-repair, culminating in its removal from the upcoming WordPress 2.5 release.
What This Means For You…
What’s been removed from the WordPress 2.5 code (download the Release Candidate!) is the file-based caching mechanism. The object cache itself has not been removed and is still available via a series of API calls, and still works 100% with the use of one or more of the memory-based caching plugins above.
Even more importantly, WordPress 2.5 actually improves on the object-caching mechanism by caching an even-larger number of objects in the code by default. So when you use an object-cache plugin with WordPress 2.5, you’re actually getting a rather nice performance boost thanks to the number of hooks and caching-wrappers injected into the code.
Bottom line: by default, WordPress 2.5 is no different than WordPress 2.1 or 2.2 – the only difference is that the file-based caching system has been removed instead of disabled. But in its stead come some nice improvements to the caching system under-the-hood that will get you better performance; along with a number of more-streamlined and well-tuned sections of PHP code in general to reduce the overall server load and decrease page load times.
So, yes, WordPress 2.5 does away with the file-based caching methodology. But it’s still faster than its predecessors, and it hasn’t done away with the caching mechanism – only refined it where necessary. Whether you use the object cache or not, either way, WordPress 2.5 will probably be a safer bet for that upcoming horse-race being closely-watched by the audience on Slashdot and Digg.