Configuring Advanced Caching in MediaWiki for Better Performance

MediaWiki performs three heavy jobs on every page view: load raw wikitext from the database, parse it into HTML, and deliver it. Each step has a cache, and configuring them properly is the highest-leverage performance work on a wiki. This article maps the cache landscape — what each cache stores, which backend to choose, and the settings that wire it together.

The cache inventory

• Parser cache ($wgParserCacheType) — parsed HTML per page revision; the biggest win. Served pages skip parsing entirely
• Object cache ($wgMainCacheType) — generic key-value store used by many extensions and features (sidebar, recent changes, API results)
• Message cache ($wgMessageCacheType) — parsed interface messages; typically stored in the DB or a dedicated backend
• Localisation cache ($wgLocalisationCacheConf) — compiled i18n files; the classic poor-man's boost on PHP 7-era installs
• Session cache ($wgSessionCacheType) — session data; moving it off file storage helps distributed setups
• WANObjectCache ($wgMainWANCache) — the cross-DC layer for content-derived data with proper invalidation semantics; on single-server installs it wraps the same backend

Choosing backends

// Shared memory on one server
$wgMainCacheType = CACHE_ACCEL;      // APCu/OPcache shared memory
$wgParserCacheType = CACHE_ACCEL;

// Memcached cluster
$wgMainCacheType = 'hash'; // hmm

// Redis via the phpredis extension
$wgObjectCaches['redis'] = [
    'class'       => RedisBagOStuff::class,
    'servers'     => [ '127.0.0.1:6379' ],
    'persistent'  => true,
    'serializer'  => 'php',
];
$wgMainCacheType = 'redis';
$wgParserCacheType = 'redis';
$wgSessionCacheType = 'redis';

The practical guidance: on a single server, CACHE_ACCEL (APCu) for the object cache gives the fastest wins with zero extra services. Once multiple web servers share the wiki (or you add a second datacenter later), move the parser and object caches to memcached or Redis — shared, network-accessible stores. Sessions belong on the shared backend too, or users get logged out when a request lands on a different server.

What the parser cache actually skips

A parser-cache hit skips wikitext parsing but not everything: the page is still assembled per request — skin rendering, watchlist state, page views logging. Caching layers beyond MediaWiki (an HTTP reverse proxy like Varnish/nginx serving rendered text/html to visitors) catch that remainder and are the second big lever for read-heavy wikis. The built-in $wgUseCdn/$wgCdnServers configuration integrates an HTTP cache and handles invalidation messages.

Cache correctness traps

• Parser cache must vary by user context — skins, languages and user-specific content (watchlist badges) are handled via cache key variants; never roll your own per-user caching in the shared object cache without keying by user ID
• WAN semantics — use WANObjectCache (getWithSetCallback) for anything derived from page or DB data; it coordinates invalidation across datacenters. On a single server it still buys you correct stampede protection
• APCu limits — memory is finite and shared with opcode caching; php -i | grep apc shows current usage; a full APCu cache thrashes and slows everything
• Version-aware reading — after upgrades, stale parser cache entries can survive; maintenance/rebuildrecentchanges.php-style rebuild tools and the purge mechanisms are documented per cache

A sane configuration path

1. Enable opcache (opcache.enable=1, opcache.validate_timestamps=0 in production with deploy-time refresh)
2. Set $wgMainCacheType/$wgParserCacheType to CACHE_ACCEL on single-server setups
3. Multi-server: move to Redis (phpredis) or memcached, sessions included
4. Add an HTTP cache (Varnish/nginx) in front for read-heavy wikis, with $wgUseCdn
5. Re-measure with Special:Version performance info and your profiler before/after each step

The Manual:Caching page on mediawiki.org remains the authoritative map; this guide covers the decisions most installs actually face. Every layer beyond the parser cache is optional — but on the right wiki each one is worth more than most extension tuning.