Object cache

MediaWiki uses caching in many components and at multiple layers. This page documents the various caches we use inside the MediaWiki PHP application.

General
The ObjectCache class provides interfaces for two kinds of caches: The document covers the first use case in an attempt to help understand which caches exists, and how they are managed. E.g. when we purge a key, how we update the value, and if the key or value can be verified.
 * 1) A place to store the result of a computation, or data fetched from an external source (for higher access speeds). This is a "cache" in the computer science definition.
 * 2) A place to store lightweight data not stored anywhere else. Also known as a stash (or "hoard" of objects).

A cache key is said to be "verifiable" if the value cannot be stale. For example, a key is verifiable if it contains a hash of the input, and the output can be deterministically recomputed.

A cache value is verifiable if the caller can inspect the value and determine whether it is still up to date. For example, by comparing an identifier that is embedded in the value.

Interfaces
These are the generic stores used by the various logical purposes described in the Uses section.

Main cache
Accessed through.

Values in this store are kept centrally in the current cluster (typically using Memcached as backend). While values are not replicated to other clusters, delete and purge events are broadcasted to other DCs main cache for cache invalidation. See WANObjectCache class reference for how to use this.

In short: Invalidate cache by purging, not by setting the new value. Each cluster will compute its own value as needed.

Local server
Accessed through.

Values in this store only kept on the local web server only (typically using APC as backend). Not replicated to the other servers or clusters.

This store defaults to a null interface if APC (or other supported PHP extensions) are not installed. It is also set to a null interface for maintenance scripts and other command-line modes. . MediaWiki supports APC, APCu, XCache, and WinCache.

Local cluster
Mostly for internal coordination within the current cluster. Accessed through.

Localisation cache
..

Parser cache

 * Accessed via the  class.
 * Backend configured by (typically MySQL).
 * Keys are canonical by page ID and populated when a page is parsed.
 * Revision ID is verified on retrieval.

Revision text cache

 * Accessed via.
 * Stored in the main cache.
 * Keys are verifiable and values immutable. Cache populated on demand.

Revision meta data cache

 * Accessed via.
 * Stored in the main cache.
 * Keys are verifiable (by page and revision ID) and values immutable. Cache populated on demand.

MessageBlobStore
..

Minification cache
ResourceLoader caches minification output of JavaScript and CSS.
 * Accessed via.
 * Stored locally on the server (APC).
 * Keys are verifiable values deterministic (no purge strategy needed). Cache populated on demand.

LESS compilation cache
ResourceLoader caches the meta data and parser output when compiling LESS files.

File content hasher
ResourceLoader caches the checksum when hashing a file's content.