So I was re-reading Jeff Eaton’s excellent article on Drupal’s method of caching. I think they way the Drupal project has elected to handle caching is a model that other CMS’s, especially those that expect to be used for a a variety of purposes, could really learn from. Briefly, caching refers to the temporary storage and reuse of data to increase the speed of an application or site. It is most useful in situations where the cost of producing the data is relatively high, and where there is a relatively frequent need for the data.
Almost all CMS’s have a caching layer. Expression Engine and WordPress (the two I work with daily) have theirs. Here’s a summary:
- Built-in caching behavior for both templates and template tags. Available query caching.
- One major DB caching module (Solspace morsels)
- No caching abstraction or API
- Caches objects and other stuff in mysql. Minimally used by default. Does not cache entire pages or parts of pages by default.
- File caching can be enabled through a configuration change.
- Various powerful plugins are avaialable that implement page caching.
Both of these approaches are reasonable, and work well enough to enable high traffic sites to run properly on these platforms. They also don’t require you to think that hard while developing themes or templates for either WP or EE, since you can apply caching later. but there is a certain lack of flexibility. Essentially, there’s a default behavior, and you then rely on various configurations or plugins to improve that default behavior. Let’s contrast that with Drupal:
Drupal has a caching API — a single set of functions for setting to, getting from and destroying cache that are then used across the entire CMS. Two good things about this: 1. you can think avtively about setting and getting cache in the normal course of developing modules and have an expectation of unified, predictable behavior whenever you invoke cache. 2. the caching system is an API, abstracted from the details of what your application actually does, and you can change the behavior of all of your site’s caching by simply replacing the code that implements the cache. For example, you could decide to do your caching using memcached, or through a DB, or using file based caching. These three implementations are well known and immediately available (I think they even come with the standard Drupal 6 install.) Says Jeff Eaton:
If you’re really hoping to squeeze the most out of your server, Drupal also supports the use of alternative caching systems. By changing a single line in your site’s settings.php file, you can point it to different implementations of the standard cache_set(), cache_get(), and cache_clear_all() functions. File-based caching, integration with the open source memcached project, and other approaches are all possible. As long as you’ve used the standard Drupal caching functions, your module’s code won’t have to be altered.
Don’t get me wrong — different caching behaviors are available in WP (and maybe even EE) as well, the problem is just that to fundamentally change cache behavior requires hacking. Drupal intentionally throws open a world of caching choices by completely abstracting its main caching mechanism.