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.
Damn, I actually used this (on a shared host) and it worked well…
thank you very much for that really great comment about object-caching and wordpress 2.5. it is still like i used to see it, neosmart is a a really great site, worth visiting daily and i often learn something new. keep on this good special work! 🙂
sincerely
Chris
Matt, I know what you mean… Several years ago when I was hosting NeoSmart on a shared host I had seen performance benefits with the file-based caching system – but after I got Slashdotted a couple of times I learnt that my host had been wondering why there were so many excessive I/O calls from my account.
The performance improvements of file-based caching can be felt so long as the I/O overhead doesn’t exceed a certain amount – after that, it becomes more efficient to let the database grab the data from the hard-drive, because at least MySQL has some in-memory cache that it can take advantage of. At the end of the day, as I alluded-to above, both file-based caching and SQL servers grab the data from the hard drive; the difference is that the latter grabs more then sifts through it. So it’s just a precarious balance between I/O activity and CPU cycles — neither of which you really want to piss off!
Chris, I’m glad you enjoyed the article.. Thanks for sharing your feedback.
I’ve worked on another drop-in object cache extension that uses a MySQL table. Even though it sounds daft to use the database to speed up the database I’ve found it works pretty well on my shared hosting where I couldn’t use the now extinct file-based cache and the memory-based alternatives aren’t available. I’ll be making the table-based cache generally available shortly.
You’re right… that does sound confusing.
I assume you’re simply storing key-value relationships in a (temporary?) MySQL table; thus turning into more-or-less a dictionary? Temporary tables would probably perform quite-decently given that they’re stored and kept in the memory, verses normal tables which have portions cached in the memory but reside on-disk……
Now that I think about it though, it actually does make sense. After all, you’re getting memory-based (even if only partially) storage for commonly-accessed values; retrieving them with some highly-optimized compiled-C code (the MySQL engine).
Look forward to your release. Let me know when you do, and I’ll send some links your way.
Plus, WordPress 2.5 doesn’t do gzip compression anymore. Sounds like my site might end up being slower with 2.5.
So, when are you releasing your “PerformancePress” stuff? 😛
You should be gzipping output with a .htaccess file or in the httpd.ini configuration, or in php.ini (php compilation flags on Linux). They perform better….
I’ll be writing another article soon on the future of PerformancePress (the from-scratch engine that powers The NeoSmart Files‘s frontend); but don’t get too excited, in its current phase it’ll break all your display-related plugins and require you to manually integrate it into your theme. But it’s fast, eh? 😛
Matt, here’s the article I was talking about. Hopefully it’ll clear up any questions about the current state of PerformancePress:
http://neosmart.net/blog/2008/wordpress-performancepress-and-gsoc-2008/
gzipping in .htaccess on a test 2.5 install, brought page times from 0.9 to 0.1 seconds. Sweet.
I’m a lurker on the -hackers list, thanks for your file-based caching extension — I’m using it now.
Looking forwad to the MySQL-based extension!
So, will we need more xcache-memory?
I just upgraded to 2.5-RC3, and I see Wordpress doing more queries and taking longer than before. You say it’s supposed to be faster? That’s not what I see.
Omar, you’ll need to increase “xcache.var_size” for this to work. 8MB should be plenty, we have it set to 16MB on NST, and we don’t use most of it.
Bob, try using one of our object-cache extensions.
…Sorry for the late replies, guys.
I’m using shared hosting, so I don’t think I can run any of those accelerator or caching programs. Any suggestions? I’m limited to 32 MB of RAM use, and PHP5 itself uses 23 MB of that!
With today’s public release of WordPress 2.5, NeoSmart Technologies has made available a plugin that re-implements the file-based caching mechanism of previous versions of WordPress. Please see http://neosmart.net/blog/2008/file-based-extension-to-the-wordpress-object-cache/ for more info.
So do wordpress users need the wp-cache plugin to make their WP installations work more efficiently on shared hosts? This is an issue for me, as my host cant handle certain php applications like WP.
I use it also, but i haven´t got much speed improvement, so i let my WP-Cache activated..
So is WP 2.5 faster than its predecessors for users on a shared host? Mine seems faster but i’m basing this purely anecdotal.
my blog is very slow to open, I will try to find and install such cache plugin. Hope it’s useful. thanks for share..
I am on a shared host, and my account gets suspended often cos of exceeding CPU usage. What’ll be the best method or plugin to help with this situation. I’m currently using wp-cache and WP 2.5
Thanks
This article explains a lot.
I had WordPress 2.5 on a free host and they kept sending me emails saying it was killing their server.
Now I use 2.7 and still test on free hosts, but havn’t had any emails yet!
WP Super Cache is a great plugin and recommended for anyone having problems 😉
http://wordpress.org/extend/plugins/wp-super-cache/
when i extract eaccelerator cache, suddenly my wpmu’s wp-content turns blank.
no error.
the frontpage still loads fine.
Am I right that to use the object cache in 2.8 you need one of those eAccelerator/XCache plugins?
I tried to activate it on a local blog and it worked fine without any plugin reducing the process time by half, but I am hesitant on trying it on my real blog without knowing the consequences.
So my question is: Can I use the object cache without additional plugins? Does it have any drawbacks to use caching?
My VPS running Ngingx PHP-fpm APC and memcached to handle wordpress. Then installed W3 Total Cache plugin. With 200k-230k hits perday the CPU load avarage under 1.