Jump to navigation Jump to search

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


The ObjectCache 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). These are values that are not possible (or not allowed) to be recomputed on-demand.


A cache key is said to be "verifiable" if the program is able to verify that the value is not outdated.

This applies when a key can only have one possible value, such as computing the 100th digit of Pi could be cached under key math_pi_digit:100. The result can be safely stored in high-speed access stores without coordination, because it will never need to be updated or purged. If it expires from the cache, it can be re-computed and produce the same result. The same applies to storing the wikitext of a certain revision to a page. Revision 123 has happened and will always contain the same content. If the program knows the revision ID it is looking for, a cache key like revision_content:123 could also be a verifiable cache key.


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

Local server[edit]

Accessed through ObjectCache::getLocalServerInstance().

Values in this store are only kept in the local RAM of any given web server (typically using php-apcu). These are not replicated to the other servers or clusters, and have no update or purge coordination options.

If the web server does not have php-apcu (or equivalent) installed, this interface falls back to an empty placeholder where no keys are stored. It is also set to an empty interface for maintenance scripts and other command-line modes. MediaWiki supports APCu, XCache, and WinCache.

WAN cache[edit]

Accessed through MediaWikiServices->getMainWANObjectCache().

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 getWithSet method. To invalidate caches, use key purging (not by setting a key directly).

Local cluster[edit]

Mostly for internal use only, to offer limited coordination of actions within a given data centre. This uses the same storage backend as WAN cache, but under a different key namespace, and without being any broadcasting or purging to other data centres.

Accessed through ObjectCache::getLocalClusterInstance().

Main stash[edit]

Accessed through MediaWikiServices->getMainObjectStash().

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 BagOStuff::READ_LATEST.

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


Interwiki cache[edit]

See Interwiki cache for details, and also ClearInterwikiCache.php.

Parser cache[edit]

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

See also Manual:Parser#ParserCache and purgeParserCache.php.

Revision text[edit]

  • Accessed via SqlBlobStore::getBlob.
  • Stored in the WAN cache, using key class SqlBlobStore-blob.
  • Keys are verifiable and values immutable. Cache is populated on demand.

Revision meta data[edit]

  • Accessed via RevisionStore::getKnownCurrentRevision.
  • Stored in the WAN cache, using key class revision-row-1.29.
  • Keys are verifiable (by page and revision ID) and values immutable. Cache is populated on demand.


  • Accessed via MessageBlobStore.
  • 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[edit]

ResourceLoader caches minification output of JavaScript and CSS.

  • Accessed via ResourceLoader::filter.
  • Stored locally on the server (APCu).
  • Keys are verifiable values deterministic (no purge strategy needed). Cache populated on demand.

LESS compilation cache[edit]

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

File content hasher[edit]

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

See also[edit]