Speeding Up MediaWiki with Redis: Installation, Configuration, and Best Practices
Why add Redis to MediaWiki?
MediaWiki performs many expensive operations – parsing wikitext, running extensions, and handling job queues. A fast, in‑memory key‑value store reduces database load and cuts page‑render time. Redis offers low latency, built‑in persistence options, and can serve as object cache, session store, and job queue backend.
Prerequisites
- Ubuntu/Debian or a compatible Linux distribution.
- Root or sudo access to install packages.
- PHP with the
php-redisextension (orpredisfor pure PHP). - Access to edit
LocalSettings.phpon the MediaWiki instance.
Installing Redis
sudo apt-get update
sudo apt-get install redis-server php-redisThe package installs a default Redis instance listening on 127.0.0.1:6379. Verify it runs:
redis-cli ping
# Expected output: PONGConfiguring MediaWiki to use Redis
Add the following block to LocalSettings.php. It defines a Redis‑backed BagOStuff object cache and makes it the default for most cache types.
$wgObjectCaches['redis'] = [
'class' => 'RedisBagOStuff',
'servers' => [ '127.0.0.1:6379' ],
// optional tweaks:
// 'connectTimeout' => 1,
// 'persistent' => true,
// 'password' => 'secret',
// 'automaticFailOver' => true,
];
// Use Redis for the primary caches
$wgMainCacheType = 'redis'; // object cache for generic data
$wgParserCacheType = 'redis'; // rendered HTML cache
$wgSessionCacheType = 'redis'; // PHP session storage (optional)
$wgMessageCacheType = 'redis'; // i18n messages (optional)
After saving, MediaWiki will obtain a cache instance via ObjectCache::getInstance('redis').
Redis‑backed Job Queue
Redis can replace the default database job queue, improving throughput for high‑traffic wikis.
$wgJobTypeConf['default'] = [
'class' => 'JobQueueRedis',
'redisServer' => '127.0.0.1:6379',
'redisConfig' => [],
'daemonized' => true,
];
When daemonized is true, the jobrunner service should be installed and started so that delayed jobs are processed.
Memory and Eviction Settings
Redis defaults to unlimited memory, which can exhaust the host. Set a reasonable limit and an eviction policy that matches a cache’s non‑persistent nature.
# /etc/redis/redis.conf
maxmemory 512mb
maxmemory-policy allkeys-lru # evict least‑recently‑used keys
Restart Redis after editing:
sudo systemctl restart redis-serverBest Practices
- Separate concerns. Use distinct Redis databases or ports for object cache, session store, and job queue to avoid accidental key collisions.
- Monitor health. Enable
redis-cli INFOmetrics, log to/var/log/redis/redis.log, and set alerts for memory usage and evictions. - Test cache invalidation. After configuration, purge a page (
?action=purge) and verify the HTML is regenerated. Use the MediaWiki debug toolbar to confirm cache hits. - Backup critical data. Although the cache is expendable, persistent session data or job queues may need a snapshot. Periodic RDB or AOF backups are recommended.
- Avoid APCu. If APCu is enabled, disable
$wgMainCacheType = CACHE_ACCELto prevent duplicate caching layers. - Fine‑tune expiration. Extensions like Semantic MediaWiki expose their own cache lifetimes; set them to a few minutes when data changes frequently.
Common Pitfalls
- Leaving
$wgMainCacheType = CACHE_ACCELactive causes MediaWiki to bypass Redis. - Using the default
allkeys-lrupolicy with a very lowmaxmemorycan cause frequent evictions, leading to cache misses and higher DB load. - Forgetting to set the password in both
$wgObjectCachesand$wgJobTypeConfwhen Redis is secured.
Conclusion
Redis adds a high‑performance, flexible caching layer to MediaWiki with minimal configuration. By installing the server, wiring the object cache, enabling the Redis job queue, and applying sensible memory limits, a wiki can serve pages faster, reduce database load, and handle background jobs more efficiently. Regular monitoring and disciplined key‑space separation ensure the setup stays reliable as traffic grows.