Enhancing MediaWiki Performance with PHP 8 and Redis Integration

Two upgrades dominate MediaWiki performance discussions: moving to a modern PHP and adding a shared memory cache. Both are worth doing, but the marketing around them deserves a realism check: PHP's JIT does not speed up MediaWiki meaningfully (the work is I/O- and parsing-bound, not CPU-bound), while Redis genuinely helps once the wiki outgrows a single PHP process. This article is the practical path: what to expect, what to configure, and how to verify the gains.

Step 1 — PHP 8.x, done properly

MediaWiki 1.43 LTS requires PHP 8.1+; 1.45 and later require 8.2+. The upgrade checklist:

• Enable opcache — opcache.enable=1, opcache.memory_consumption=256, opcache.max_accelerated_files=20000; in production set validate_timestamps=0 and clear opcache on deploy
• Skip JIT — opcache.jit can remain off; MediaWiki's hot paths are database and parser work where JIT shows no measurable benefit
• Right extensions — required PHP modules for modern MediaWiki: dom, fileinfo, iconv, intl, mbstring, openssl, xml, plus curl/redis per setup
• Verify — php -v on the web server's PHP binary (not the CLI-only one), then Special:Version for the 'PHP 8.2' line

Step 2 — Redis as the shared cache

MediaWiki talks to Redis through the phpredis PHP extension (a separate Redis PHP module); the pure-PHP predis client is a fallback with worse performance. Configure the backend in LocalSettings.php:

$wgObjectCaches['redis'] = [
    'class'      => RedisBagOStuff::class,
    'servers'    => [ '127.0.0.1:6379' ],
    'persistent' => true,
    'timeout'    => 3,
];

$wgMainCacheType    = 'redis';
$wgParserCacheType  = 'redis';
$wgSessionCacheType = 'redis';

A shared Redis instance is what makes a multi-web-server farm behave like one wiki: parser cache and sessions are visible to every PHP process, and the database stops being the bottleneck for repeat views. Single-server wikis see the same benefit but through APCu (CACHE_ACCEL) — Redis only wins once more than one server is involved, since its access cost includes the network hop.

Step 3 — Redis health and limits

• Memory cap — maxmemory 512mb + allkeys-lru eviction in redis.conf; without an eviction policy Redis stops accepting writes when full, and MediaWiki pages start rebuilding slowly
• Persistence — the object cache is disposable by design; save "" disables snapshots and avoids fsync stalls. Never treat Redis cache data as a backup of anything
• Monitoring — redis-cli INFO stats and INFO keyspace; a wiki's mediawiki:* keys should stay well under the memory cap with plenty of LRU headroom

Step 4 — measuring the real gains

The honest numbers, on a typical wiki: upgrading from PHP 7.4 to 8.2 buys single-digit-percent request time on CPU-heavy pages and a big correctness/security upgrade; moving the parser cache from DB-backed to Redis/APCu turns repeat views into near-instant responses — the difference is often 10–50× on repeat page loads, visible in the profiler as a missing 'ParserCache::get' hit path. Compare before/after with:

ab -n 500 -c 10 'https://wiki.example.org/Some_Page'

and check Special:Performance-style pages or the profiler output for cache hit rates.

Step 5 — gotchas that bite

• phpredis version skew — the Redis class API changed over versions; match the extension to the docs of your MediaWiki release line
• Sessions in Redis — once $wgSessionCacheType is Redis, clearing the Redis DB (e.g. FLUSHALL) logs everyone out; schedule it as a maintenance event, not a reflex
• Timeout handling — a slow/hung Redis degrades requests; keep timeout and retry options short so MediaWiki falls back to the DB rather than piling up
• Backups — Redis is a cache, not a store: DB dumps and images/ remain the only real backups, whatever the cache contains

PHP 8 fixes the platform's foundations; Redis fixes its repeat-view latency; neither fixes content or template problems. The order that works: upgrade PHP with opcache on, move caches to shared memory, then measure — and only then chase the exotic tuning. The caching manual and the performance manual document the remaining details.