Enhancing MediaWiki Performance with Advanced Caching Strategies
Boosting MediaWiki Speed: A No‑Nonsense Caching Playbook
Ever feel like your wiki snails along when traffic spikes? You’re not alone – most MediaWiki installs crawl under the weight of un‑cached DB hits. Below is a grab‑bag of tricks that actually move the needle without turning your server into a Frankenstein.
1. Object cache – the quiet workhorse
Set wgMainCacheType to CACHE_MEMCACHED (or CACHE_REDIS if you fancy). This tells MediaWiki to stash parsed pages, user options, and API results in a fast, network‑shared store.
$wgMainCacheType = CACHE_MEMCACHED; // or CACHE_REDIS $wgMemCachedServers = [ '127.0.0.1:11211' ]; // change to your host:port // Redis example $wgRedisServers = [ '127.0.0.1:6379' ];
Tip: keep the TTL low for user‑specific bits (5‑10 min) but let generic data linger for an hour or more. The sweet spot varies – experiment.
2. Page view cache for anonymous eyes
Anonymous visitors benefit from the “fast‑cache” table. Turn it on, and MediaWiki will serve a static HTML copy instead of re‑running the parser each time.
$wgCachePages = true; // enable page view cache $wgCacheEpoch = '20240922'; // bust cache after a big upgrade $wgMessageCacheType = CACHE_ACCEL;
Don’t forget: the parserCacheExpireTime defaults to 86400 seconds – that’s one day. If you push frequent edits, drop it to a few hours.
3. HTTP caching layer – CDN or reverse proxy?
Whether you’re behind Varnish, Nginx’s proxy_cache, or a CDN like Cloudflare, add the proper Cache‑Control headers. MediaWiki already emits private for logged‑in users, but for guests you can be aggressive:
location ~ ^/wiki/ { proxy_pass http://backend; proxy_cache mycache; proxy_cache_valid 200 30m; proxy_set_header X-Forwarded-Proto $scheme; }
Pro tip: whack Expires on static assets (images, CSS, JS) to a year – browsers love that.
4. Fine‑tune the built‑in stash
- ObjectCacheSession – set
$wgMainCacheType = CACHE_ACCELif you have APCu or OPcache on the same box. Quick and dirty. - Memcached compression – enable
$wgMemCachedCompress = trueto shave a few megabytes off the wire. - Parser cache size –
$wgParserCacheType = CACHE_DBworks for small wikis; switch toCACHE_ACCELon big farms.
5. Real‑world snippet – a one‑liner you can paste
Got a fresh VM? Toss this into LocalSettings.php and you’ll see a noticeable lag drop (I’ve seen 30‑40% improvement on a 500‑page install).
# Basic high‑performance cache stack $wgMainCacheType = CACHE_MEMCACHED; $wgMemCachedServers = [ '10.0.1.12:11211' ]; $wgCachePages = true; $wgUseCombinedLoginLink = true; // small UI tweak $wgParserCacheType = CACHE_ACCEL; $wgMessageCacheType = CACHE_ACCEL;
6. Common pitfalls – what to watch out for
— Forgetting to restart Memcached after a config change. Yeah, it happens.
— Over‑caching dynamic content. If a page shows “You are logged in as …”, it belongs in the session cache, not the page view cache.
— Using both APCu and Redis for the same keys – can lead to stale data. Pick one backend per data class.
7. Wrap‑up (or not?)
Bottom line: A layered cache (object → page view → HTTP) turns a sluggish wiki into a snappy knowledge hub. You don’t need a PhD in systems engineering – just flip a few switches, test, and iterate. Got a quirky setup? Drop a comment, I’ll try to help.