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 class provides interfaces for two kinds of caches:


 * 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).

This page 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.

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.

Local server
Accessed through.

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

This store defaults to a null interface if APCu (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 APCu, XCache, and WinCache.

WAN cache
Also known as "Main cache".

Accessed through.

Values in this store are stored centrally in the current data centre (typically using Memcached as backend). While values are not replicated to other clusters, "delete" and "purge" events for keys are broadcasted to other data centres for cache invalidation. See WANObjectCache class reference for how to use this.

In short: Compute and store values via the  method. To invalidate caches, use key purging (not by setting a key directly).

Local cluster
Mostly for internal use only, for coordination within the current data centre. This uses the same storage backend as WAN cache, but under a different key namespace, and without being linked to data centres in any way.

Accessed through.

Main stash
Accessed through.

Values in this store are stored centrally in the primary data centre, and later replicated to other data centres (typically using MySQL or Redis as backend).

By default, keys will be read from a local replica. To read from the master, use.

While this store is expected to have strong persistence, it may still be subject to LRU-style evictions.

Interwiki cache
See Interwiki cache for details, and also.

Parser cache
See also Manual:Parser and purgeParserCache.php.
 * 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

 * Accessed via.
 * Stored in the main cache.
 * Keys are verifiable (by module name and hash of message keys). Values are mutable and expire after a week. Cache populated on demand.
 * All keys are purged a LocalisationCache rebuild.
 * When MediaWiki-namespace messages are edited, relevant module keys are purged.

Minification cache
ResourceLoader caches minification output of JavaScript and CSS.
 * Accessed via.
 * Stored locally on the server (APCu).
 * 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.