Stop Killing Your Disk I/O: Migrating PHP Sessions to Redis
I spent last weekend debugging a high-traffic Magento install that was crawling during peak hours. The CPU load was low, memory was free, yet the site felt like it was running on a dial-up connection. A quick look at iostat revealed the ugly truth: %iowait was spiking through the roof.
The culprit? Default PHP session handling. Every time a user hits your site, PHP locks a file on the disk. On a high-traffic site, your hard drives are thrashing just trying to manage thousands of tiny session files. It is a bottleneck that no amount of CPU power can fix.
If you are serious about performance in 2011, you need to stop writing sessions to the filesystem. You need to put them in RAM. You need Redis.
Why Redis Beats Memcached for Sessions
While Memcached has been the standard for years, Redis (specifically the new 2.2 release) is proving to be superior for session storage. Unlike Memcached, Redis offers persistence. If your VPS reboots, Memcached loses everyone's shopping cart. Redis can write to disk asynchronously without blocking the application, saving your data—and your revenue.
The Architecture
We are going to configure a standard LAMP stack (Linux, Apache, MySQL, PHP 5.3) to offload session storage to a local Redis instance. This eliminates disk locking contention entirely.
Implementation Guide
Assuming you are running Debian 6 (Squeeze) or CentOS 5/6, here is the battle-tested path to sub-millisecond session reads.
1. Install Redis and the PHP Extension
Don't rely on old package repositories. Compile the extension from PECL to ensure stability with PHP 5.3.
pecl install redis
Add the extension to your php.ini file:
extension=redis.so
2. Configure PHP to Use Redis
Open your php.ini or your pool configuration if you are running PHP-FPM (which you should be). We need to change the save handler.
Old Config:
session.save_handler = files
session.save_path = "/var/lib/php/session"
New Config:
session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379"
3. Verify the Speed
Restart Apache or PHP-FPM. You should see an immediate drop in Disk I/O usage. Use redis-cli monitor to watch the session keys being hit in real-time. It is satisfyingly fast.
The Hardware Factor: Why Visualization Matters
Here is the reality of the hosting market today. Many providers oversell their nodes using OpenVZ. This means you are sharing a kernel—and disk queues—with every other noisy neighbor on the box. If they thrash the disk, your Redis persistence slows down too.
This is why at CoolVDS, we exclusively use KVM virtualization. It gives you a dedicated kernel and strict resource isolation. When we allocate RAM for your Redis instance, it is your RAM. Combined with our enterprise-grade SSD caching and 15k SAS arrays, the latency is virtually non-existent.
Pro Tip: If you are hosting customer data in Norway, remember that Personopplysningsloven (The Personal Data Act) requires you to secure this data. Redis defaults to no password. Always setrequirepassinredis.confand update yoursession.save_pathto include the auth token:tcp://127.0.0.1:6379?auth=yourcomplexpassword.
Network Latency and NIX
For Norwegian businesses, the physical location of your server is paramount. Hosting in Germany or the US adds 30-100ms of latency to every request. CoolVDS infrastructure is peered directly at NIX (Norwegian Internet Exchange) in Oslo. This keeps your round-trip time (RTT) low, ensuring that your Redis calls—even if networked across our private LAN—are instant.
Final Thoughts
Filesystem sessions are a relic of the past. In an era where users expect instant page loads, you cannot afford to have your web server waiting on a spinning hard drive platters. Move to Redis, secure it properly, and host it on infrastructure that respects your need for dedicated IOPS.
Ready to see the difference? Spin up a Debian 6 instance on CoolVDS today and test the throughput yourself. We offer pure KVM isolation that actually handles the load.