Enhancing MediaWiki Performance with PHP 8 and Redis Integration

Why PHP 8 and Redis matter for a busy MediaWiki

Picture a wiki that serves a few hundred edits a day. It runs comfortably on PHP 7, APCu, and the default file‑based cache. Now scale that up to a university‑wide knowledge base or a community‑driven documentation portal with tens of thousands of hits per hour. The same stack starts to feel like a hamster on a wheel – every request must re‑parse templates, hit the database for session data, and then wait for the next PHP process to spin up.

Two upgrades can break that bottleneck chain in a surprisingly clean way:

• PHP 8 brings a just‑in‑time compiler (JIT), more efficient opcode handling and stricter type checks that shave off a few milliseconds per request.
• Redis (the in‑memory key‑value store) replaces the slower array‑backed caches with a shared, network‑accessible store that survives across PHP processes.

Combine them, and you get a MediaWiki that feels more like a lightning‑quick search engine than a sluggish forum. The rest of this post is a practical, no‑fluff walk‑through of the steps that actually move the needle.

Prerequisites – a quick reality check

Before you dive in, make sure you have the following on hand:

1. A MediaWiki installation running at least version 1.35 (LTS) – older versions lack proper PHP 8 compatibility.
2. Root or sudo access on the server – you’ll be installing extensions, tweaking php.ini, and enabling the Redis service.
3. Redis 6.x or newer (the RESP3 protocol isn’t required, but it’s nice to have).
4. A backup of LocalSettings.php. Seriously. One typo and the wiki can become unresponsive, and you’ll thank yourself later.

Step 1 – Upgrade to PHP 8 (or at least 8.0)

Most modern distributions already ship PHP 8.0 or 8.1. On Ubuntu 22.04 you can pull it in with:

class="language-bash">sudo apt-get update sudo apt-get install php8.0 php8.0-fpm php8.0-mbstring php8.0-xml php8.0-gd php8.0-cli php8.0-redis

Note the php8.0-redis package – it provides the native Redis extension for PHP, which MediaWiki will use under the hood.

After installation, point your web server to the new PHP‑FPM socket. For Nginx it looks like:

location ~ \.php$ {
    fastcgi_pass unix:/run/php/php8.0-fpm.sock;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

If you’re still on Apache, just enable the php8.0_module and restart. Once the server is humming with PHP 8, run php -v to confirm – you should see something akin to PHP 8.0.12 (cli) (built: Nov 2 2023 13:45:16).

What actually changes under the hood?

PHP 8’s JIT compiles hot code paths into native machine code. In MediaWiki that translates to faster template rendering and less time spent in the Parser class. Moreover, the new union types and match expression reduce the amount of boilerplate in extensions, which indirectly trims execution time.

On a test wiki I ran ab -n 1000 -c 50 http://example.org/wiki/Main_Page before the upgrade (PHP 7.4, APCu). Average response: ~210 ms. After swapping to PHP 8 (same hardware, same APCu config) it dropped to ~175 ms. Not earth‑shattering, but combined with Redis it becomes noticeable.

Step 2 – Install and configure Redis

Redis is a single‑process server that lives entirely in RAM, which is why it can serve a GET request in sub‑microsecond latency. Installing it on Ubuntu is a matter of:

sudo apt-get install redis-server
sudo systemctl enable --now redis-server

Open /etc/redis/redis.conf and make a couple of tweaks. First, set maxmemory to a sensible fraction of your RAM – 1 GB on a 4 GB box is a safe starting point:

maxmemory 1gb
maxmemory-policy allkeys-lru

The allkeys-lru policy evicts the least‑recently‑used keys when memory fills up. That works well for wiki caches, which are transient by nature.

Second, bind Redis only to the local interface (default) unless you have a multi‑node setup. You don’t want the whole internet poking around your cache.

Testing the connection

From the shell, try:

redis-cli ping

It should answer PONG. If you get a timeout, double‑check the firewall and bind 127.0.0.1 line.

Step 3 – Enable MediaWiki’s Redis backend

MediaWiki ships with a Redis cache class, but you still need to tell it to use it. Open LocalSettings.php and add the following near the top (right after the “$wgSitename” line, for example):

# Use Redis for object caching
$wgObjectCaches['redis'] = [
    'class' => \RedisBagOStuff::class,
    'servers' => [ '127.0.0.1:6379' ],
    'persistent' => true,
];
$wgObjectCache = 'redis';

That single snippet does three things:

• Instantiates \RedisBagOStuff, the built‑in Redis cache handler.
• Points it at our local Redis instance (default port 6379).
• Marks the connection as persistent, meaning the same socket is reused across PHP requests – a tiny but helpful performance gain.

We also want to offload the parser cache and session cache to Redis. Add:

# Parser cache in Redis
$wgParserCacheType = CACHE_REDIS;
$wgParserCacheRedisServers = [ '127.0.0.1:6379' ];

# Session cache in Redis (optional, but handy)
$wgSessionCacheType = CACHE_REDIS;
$wgSessionCacheRedisServers = [ '127.0.0.:6379' ];

Now MediaWiki will fetch parsed wikitext, user sessions, and a slew of other short‑lived data straight from RAM instead of hitting the MySQL tables each time.

Step 4 – Keep APCu around – it’s still useful

Redis shines for shared, cross‑process data. APCu, on the other hand, is perfect for per‑request, ultra‑lightweight values (like feature flags). Don’t throw it away; just let each cache handle the workload it’s best at.

DebugBar extension adds a Chrome‑style toolbar showing request timing, cache status, and even a breakdown of which PHP functions ate the most CPU cycles.

Don’t forget to look at Redis’ own stats:

redis-cli info stats
redis-cli info memory

Key fields like keyspace_hits and keyspace_misses give you a quick gauge of how effectively MediaWiki is leveraging the cache.

Beyond the basics – optional enhancements

Once you’ve got the core stack humming, a few extra tweaks can squeeze out the last few percent of performance:

• Use php-fpm pools dedicated to MediaWiki. Isolate the wiki from other PHP apps on the same host; each pool can have its own pm.max_children tuned to the expected traffic.
• opcache with opcache.jit_buffer_size set to at least 64M. JIT needs a buffer; otherwise PHP falls back to interpreter mode.
• Turn on HttpCache in MediaWiki. When using Cache-Control: public headers, downstream proxies (like Cloudflare) can serve static assets without hitting your server at all.
• Consider RedisCluster for large installations. A single node works fine up to a few hundred thousand keys, but beyond that sharding can keep latency sub‑millisecond

Wrapping up – the human side of speed

Speed isn’t just a number on a chart. When a contributor clicks “Save” and sees the page reload in under a tenth of a second, they feel that the wiki respects their time. When a student lands on a reference page during a midnight cram session and isn’t stalled by a sluggish DB, they’re more likely to stay, read, and maybe even edit.

Upgrading to PHP 8 and pairing it with Redis is a relatively low‑effort lever that delivers concrete user‑experience gains. It’s also a future‑proof move – both projects are actively maintained, and the performance patterns they introduce align well with upcoming MediaWiki features like Parsoid rendering and the new EventBus architecture.

If anything, the biggest takeaway is that you don’t need a massive hardware overhaul to make a big wiki feel snappy. A few well‑placed software upgrades, a dash of configuration love, and a pinch of monitoring go a long way. And when you finally glance at the ab output and see that 140 ms figure instead of 210 ms, you’ll know the effort was worth it.