MediaWiki uses caching in many components and at multiple layers. This page documents the various caches we use inside the MediaWiki PHP application.
There are two kinds of stores described in the context of object caches in MediaWiki:
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 the 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.
MediaWiki supports storing of both primitive values (bool, int, string) and (potentially nested) structures of arrays. It is also technically possible to store plain objects (stdClass) and instances of arbitrary classes, which relies on PHP serialization, but relying on this mechanism is deprecated for security reasons (T161647), and stability reasons as it is very hard to change a class in a way that doesn't break forward or backward compatibility with cached objects of that class (e.g., T264257 etc.).
Code that writes to or reads from a cache must be both forward- and backward compatible. Typically, the code reading cached data will have the same or a newer than the code that wrote the cached data (requiring backward compatible read logic, or forwards-compatible writing ahead of time), but there are two important scenarios where the opposite is also needed:
As such, a cache may very well be written to and read from both old and new versions concurrently during this time.
Best practice:
WANObjectCache::getWithSet idiom and its "version" option, which automatically takes care of forward- and backward compatibility, including invalidating cache keys across versions of the software.
These are the abstract stores available to MediaWiki features, see the Uses section for examples.
MediaWikiServices->getLocalServerObjectCache()orMediaWikiServices->getObjectCacheFactory()->getLocalServerInstance( $fallback );.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, and WinCache.
 Warning: | This is 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 any ability to broadcast purges to other data centres. |
The local cluster cache is typically backed by Memcached, but may also use the database.
MediaWikiServices->getObjectCacheFactory()->getLocalClusterInstance().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).
See also WANObjectCache on wikitech.wikimedia.org.
MediaWikiServices->getMicroStash().CACHE_ANYTHING.Values in this store are stored centrally in the primary data centre (typically using Memcached as backend). Values are not replicated to other data centers, and data gets evicted only when the time to live (TTL) elapses.
MediaWikiServices->getMainObjectStash().Values in this store are read and written in the same data centre, with writes expected to be replicated to and from other data centres. It typically uses MySQL as backend. (See wikitech:MariaDB#x2 for Wikipedia's configuration.) By default, the objectcache table is used. It must be tolerated that reads can potentially be stale, for example due to brief unavailability of cache writes, or race conditions where overlapping requests finish out of order, or due to writes from another data center taking a second to replicate.
This store is expected to have strong persistence and is often used for data that cannot be regenerated and is not stored elsewhere. However, data stored in the MainStash must be non-critical and result in minimal user impact if lost, thus allowing for the backend to sometimes be partially unavailable or wiped if under operational pressure without causing incidents.
Session objects, which itself is accessed via SessionManager, or RequestContext->getRequest()->getSession()$wgSessionCacheType .This is not really a cache, in the sense that the data is not stored elsewhere.
See Interwiki cache for details, and also ClearInterwikiCache.php.
ParserCache class.$wgParserCacheType (typically MySQL).See Manual:Parser cache for details. See also purgeParserCache.php.
MessageCache.SqlBlobStore::getBlob.SqlBlobStore-blob.The main use case for caching revision text (as opposed to fetching directly from the text table or External Storage) is for handling cases where the text of many different pages is needed by a single web request.
This is primarily used by:
Key WANCache:v:global:SqlBlobStore-blob:<wiki>:<content address>.
"content address" refers to the content.content_address on the wiki's main database (e.g. "tt:1123").
This in turn refers to the text table or (External Storage).
To reverse engineer which page/revision this relates to, Find content.content_id for the content address (SELECT content_id FROM content WHERE content_address = "tt:963546992";), then find the revision ID for that content slot (SELECT slot_revision_id FROM slots WHERE slot_content_id = 943285896;).
The revision ID can then be used on-wiki in a url like https://en.wikipedia.org/w/index.php?oldid=951705319, or you can look it up in the revision and page tables.
RevisionStore::getKnownCurrentRevision.revision-row-1.29.Stores interface text used by ResourceLoader modules. It is similar to LocalisationCache, but includes the wiki-specific overrides. (LocalisationCache is wiki-agnostic). These overrides come from the database as wiki pages in the MediaWiki-namespace.
MessageBlobStore.MessageBlobStore.ResourceLoader caches the minified versions of raw JavaScript and CSS input files.
ResourceLoader::filter.ResourceLoader caches the meta data and parser output of LESS files it has compiled.
ResourceLoaderFileModule::compileLessFile.ResourceLoader caches the checksum of any file directly or indirectly used by a module. When serving the startup manifest to users, it needs the hashes of many thousands of files. To reduce I/O overhead, it caches this content hash locally, keyed by path and mtime.
FileContentsHasher.
