Stop Thrashing Your Disk: Why We Switched PHP Sessions to Redis (And You Should Too)

The I/O Wait Nightmare

It starts silently. Your traffic grows. Your Apache logs look fine. Your CPU usage is decent. But the site feels sluggish. The load average climbs, not because of calculation, but because of I/O Wait.

If you are running a PHP application—whether it's Magento, Drupal, or a custom stack—you are likely relying on the default session behavior: writing files to /var/lib/php/sessions. Every single page load requires a disk read and a write.

On a standard 7200 RPM SATA drive, you hit a physical limit on IOPS (Input/Output Operations Per Second) very quickly. Even with 15k RPM SAS drives, you are bottlenecking your entire architecture on a mechanical arm moving across a platter. It is 2009; we can do better.

Why Memcached Isn't Enough

For years, the standard advice from the "Performance Gurus" was simple: put sessions in Memcached. It works. It removes the disk I/O.

But Memcached has a fatal flaw: Volatility. It is purely in-memory. If you restart the service, or if the server reboots for a kernel update, every single user gets logged out instantly. In an e-commerce environment, that means abandoned carts and lost revenue.

Enter Redis: The Persistence We Needed

There is a new project gaining traction called Redis. It released version 1.0 earlier this year. Think of it like Memcached, but with a brain.

Redis holds data in RAM for blazing fast reads (microseconds, not milliseconds), but it can asynchronously sync that data to disk. If your server restarts, Redis reloads the dataset from the disk image. You get the speed of RAM with the reliability of a database.

Benchmarking the Difference

We ran a stress test using `ab` (Apache Bench) against a standard login-protected page hosted on a CoolVDS node in Oslo.

Implementing Redis for PHP Sessions

Since Redis is still bleeding edge, PHP doesn't have a native driver built-in like it does for MySQL. You have to do some legwork. You will need to install the Redis server and use a PHP client library. We recommend Predis or compiling the phpredis C extension if you are comfortable with `gcc`.

Here is a basic example of how to override PHP's default session handler. You don't need to rewrite your application; just map the session save handler.

// In your bootstrap file (e.g., common.php)
require 'Predis/Autoloader.php';
Predis\Autoloader::register();

$redis = new Predis\Client([
    'scheme' => 'tcp',
    'host'   => '127.0.0.1',
    'port'   => 6379,
]);

function open($savePath, $sessionName) { return true; }
function close() { return true; }
function read($id) {
    global $redis;
    return $redis->get("session:$id");
}
function write($id, $data) {
    global $redis;
    // Expire session after 1 hour (3600 sec)
    $redis->setex("session:$id", 3600, $data);
    return true;
}
function destroy($id) {
    global $redis;
    $redis->del("session:$id");
    return true;
}
function gc($maxlifetime) { return true; }

session_set_save_handler("open", "close", "read", "write", "destroy", "gc");
session_start();

The Architecture of Trust

Pro Tip: Don't run Redis on the same physical disk partition as your operating system logs. Redis is fast, but it needs breathing room. On CoolVDS, we allow you to mount separate virtual block devices to isolate I/O patterns.

Why Hosting Matters

Redis is entirely RAM-dependent. This highlights a dirty secret in the hosting industry: Memory Overselling. Many budget VPS providers (especially those using OpenVZ) promise you 4GB of RAM, but it's "burstable." When your neighbor on the server gets busy, your RAM disappears, and the OOM (Out of Memory) killer shoots your Redis process.

At CoolVDS, we use Xen virtualization. When you buy 2GB of RAM, that memory is physically reserved for your kernel. It cannot be stolen by another customer. For in-memory data structures like Redis, this stability is non-negotiable.

Data Privacy in Norway

Speed isn't the only concern. With the Personopplysningsloven (Personal Data Act), you are responsible for where your user data lives. Storing session data—which often contains user IDs and cart info—on servers outside the EEA is a legal gray area you should avoid.

Our datacenters are located directly in Oslo with direct fiber peering to NIX (Norwegian Internet Exchange). This ensures your data stays within Norwegian jurisdiction and, purely from a physics standpoint, keeps latency to a minimum for your Nordic users.

Ready to optimize? SSH into your server and install Redis today. If your current host can't handle the compilation or doesn't offer guaranteed RAM, spin up a CoolVDS instance. We offer pure, unthrottled resources that respect your need for speed.