C H A P T E R 1 6

■ ■ ■

Caching

Building pages for dynamic web sites requires numerous trips to the database to retrieve information about saved content, site settings, the current user, and so on. Saving the results of these expensive operations for later use is one of the easiest ways within the application layer to speed up a sluggish site. And it’s not just database calls that are saved: the processing of the retrieved information in PHP is avoided too. Drupal’s built-in cache API does this automatically for most core data and provides a number of tools for Drupal developers who want to leverage the API for their own purposes. For example, the memcache module (http://drupal.org/project/memcache) is an example of memorybased caching that makes use of the cache API.

■ Note This chapter covers caching within the Drupal application. Other layers of caching, such as the database’s internal caching (e.g., MySQL’s query cache), can also have a significant effect on performance. These are mentioned in Chapter 23).

Knowing When to Cache

It’s important to remember that caching is a trade-off. Caching large chunks of data will boost performance quite a bit, but only in cases where that specific chunk of data is needed a second or third time. That’s why Drupal’s built-in full-page caching is used only for anonymous visitors—registered users often require customized versions of pages, and the caching would be much less effective. Caching smaller chunks of data (e.g., the list of today’s popular articles) means less dramatic performance gains but still helps to speed up your site.

Caching works best on data that doesn’t change rapidly. A list of the week’s top stories works well. Caching a list of the last five comments posted on a busy forum is less helpful, because that information will become out of date so quickly that few visitors will be able to use the cached list before it needs to be updated. In the worst case, a bad caching strategy (e.g., caching data that changes too often) will add overhead to a site rather than reduce it.

365

CHAPTER 16 ■ CACHING

How Caching Works

Modules often have to make expensive database queries or calls to remote web services. Rather than using resources for those operations every time they occur, modules can store a cache of their data into one of the bins reserved for caching within the Drupal database, where bins are tables in the database. Standard bins include the following:

cache: This is the generic cache storage bin. This bin is used to store variables, the theme registry, locale date, a list of simple test, etc.

cache_block: This bin stores the content for various blocks.

cache_bootstrap: This bin stores information used during bootstrap.

cache_field: This bin stores loaded fields for an entity object.

cache_filter: This bin stores filtered pieces of content.

cache_form: This bin stores multistep forms.

cache_image: This bin stores information about in-progress image manipulations.

cache_menu: This bin stores the structure of visible navigation menus per page.

cache_page: This bin stores generated pages for anonymous users. This table is flushed often, whenever a page changes, at least for every node and comment submission. This is the only bin affected by the page cache settings on the administrator panel.

cache_path: This bin stores the system paths that have an alias.

cache_update: This bin stores available releases.

Modules may also create their own table and store the data there. The next time the data is needed, it can be quickly retrieved with a single query. As you’ll see later in the chapter, Drupal’s caching back end is pluggable, so although we refer to database tables here, in reality the back end may be some other storage such as flat files or a memory-based cache.

The default table to which your module can write cached information is named cache. Using this table is the best option when storing only a couple rows of cached information. When defining a new cache table for your module to use, it must be structurally identical to the default cache table while having a different table name. It’s a good idea to prepend cache_ to the table name for consistency. Let’s take a look at the database structure of the cache table; see Table 16-1.

■ Note When defining a new cache table for your module, it must be structurally identical to the default cache table.

366

CHAPTER 16 ■ CACHING

Table 16-1. cache Table Schema

*Bold indicates a primary key; italics indicate an indexed field.

The cid column stores the primary cache ID for quick retrieval. Examples of cache IDs used within the Drupal core are the URL of the page for page caching (e.g., http://example.com/?q=node/1), a string and a theme name for caching the theme registry (e.g., theme_registry:garland), or even regular strings (e.g., the contents of the variables table are cached with the primary cache ID set to variables). The important point is that the cache ID must be a unique identifier for the item being cached.

The data column stores the information you wish to cache. Complex data types such as arrays or objects need to be serialized using PHP’s serialize() function to preserve their data structure within the database (Drupal does this automatically).

The expire column takes one of the three following values:

•CACHE_PERMANENT: This value indicates that the item should not be removed until cache_clear_all() has been called with the cache ID of the permanent item to wipe.

•CACHE_TEMPORARY: This value indicates that the item should be removed the next time cache_clear_all() is called for a “general” wipe, with no minimum time enforcement imposed. Items marked CACHE_PERMANENT will not be removed from the cache.

•A Unix timestamp: Indicates that the item should be kept at least until the time provided, after which it will behave like an item marked CACHE_TEMPORARY and become eligible for deletion.

The created column is a Unix timestamp indicating the date the cache entry was created.

The serialized column indicates whether the data in the data column is in serialized form. A 0 indicates unserialized data while a 1 indicates serialized data. If the data is serialized and the value of the serialized column is 1, the cache system will unserialize the data before returning it to the caller. The cache system automatically serializes object and array data and sets the serialized column to 1 when this type of data is cached.

367