Redis vs. Memcached: Why Persistent Session Storage Matters for High-Load PHP Apps

The I/O Wait Nightmare: A Sysadmin's Reality

It’s 2:00 AM. Your Nagios pager is screaming. The load average on your primary web node just hit 15.0, but CPU usage is barely 20%. You run top and see the culprit immediately: %wa (I/O wait) is through the roof.

If you are running a high-traffic PHP application—whether it's Magento, Drupal, or a custom framework—you are likely hitting the classic file-based session wall. By default, PHP saves session data to /var/lib/php/session. On a standard 7200 RPM SATA drive, or even a 15k SAS drive, the sheer volume of small random writes caused by thousands of concurrent users will bring your disk subsystem to its knees. Even worse, PHP's default file handler locks the session file, creating a serialized queue that kills concurrency.

We saw this last week with a client migrating from a shared host in Germany to our CoolVDS infrastructure in Oslo. Their shop went down during a flash sale. The hardware wasn't the issue; the architecture was.

Enter Redis: The Persistent Alternative to Memcached

Until recently, the standard fix was Memcached. It’s fast, it’s in RAM, and it solves the locking issue. But Memcached has a fatal flaw for critical session data: it is volatile. If your cache node reboots, every logged-in user is kicked out. Shopping carts vanish. Admin sessions terminate.

This is why Redis (Remote Dictionary Server) is becoming the superior choice for 2010. Unlike Memcached, Redis offers persistence. It writes data to disk asynchronously (snapshots) or via an Append Only File (AOF), meaning you get the speed of RAM with the reliability of a database.

Pro Tip: Don't treat Redis like a garbage can. While it can handle persistence, you need to tune vm.overcommit_memory in your Linux kernel to prevent the background save process from failing under low-memory conditions. Add vm.overcommit_memory = 1 to /etc/sysctl.conf.

Implementing Redis Sessions in PHP 5.2/5.3

To get this running, you need the php-redis extension. Since most shared hosting providers won't let you compile custom PECL extensions, you need a proper VPS with root access, like the KVM instances we provision at CoolVDS.

First, grab the latest stable source and compile:

Next, modify your php.ini (usually found in /etc/php5/apache2/php.ini on Debian systems) to tell PHP to use Redis instead of files. We also want to define a save path that points to our local Redis instance:

Restart Apache. Your session writes are now happening in sub-millisecond RAM speeds rather than blocking on disk I/O.

The "Datatilsynet" Factor: Latency and Law

Performance isn't just about code; it's about physics. If your target audience is in Norway, hosting your Redis session store in a US datacenter (like EC2 us-east) adds ~140ms of latency to every single page load. That makes your snappy PHP application feel sluggish.

By keeping your infrastructure local in Oslo, you reduce RTT (Round Trip Time) to under 10ms for local users. Furthermore, with the growing scrutiny from Datatilsynet regarding the handling of personal data (Personopplysningsloven), keeping user session data physically within Norwegian borders is a smart compliance move. You don't want sensitive user tokens traversing international fiber unnecessarily.

Hardware Matters: Why Virtualization Type Counts

Not all VPSs are created equal. Many providers oversell resources using OpenVZ containers. In that environment, a "noisy neighbor" utilizing all the disk I/O affects your database performance directly. Redis relies heavily on being able to fork background processes for saving data.

At CoolVDS, we utilize KVM virtualization. This provides true hardware isolation. When you allocate RAM to Redis, it's your RAM. We also utilize high-performance Enterprise SSD storage arrays (a significant upgrade over standard SAS), ensuring that when Redis does sync to disk, it happens instantly. Don't let legacy hardware or outdated file storage hold back your application.

Ready to optimize?

If you are still writing sessions to /tmp, you are living on borrowed time. Spin up a root-access KVM instance on CoolVDS today, install Redis, and watch your server load drop.