Is your hard drive the reason your users are logging out?

If you are running a high-traffic site on a standard LEMP or LAMP stack, you have likely stared at top and wondered why your Load Average is spiking above 5.0 while your CPU is idle. You check iostat, and the culprit is staring you in the face: %iowait.

The bottleneck isn't your code. It's the thousands of tiny sess_* files accumulating in /var/lib/php/session. Every page load triggers a file read and a write. On a busy e-commerce site or a forum getting the "Slashdot effect," the disk seek time for locking these session files destroys concurrency.

For years, the pragmatic answer was Memcached. But Memcached is volatile. If the daemon crashes or you need to reboot the node to patch a kernel, every single user is logged out instantly. That is unacceptable for enterprise applications.

Enter Redis.

The New Contender: Redis (Remote Dictionary Server)

Redis is a relatively new project (released earlier this year) that is rapidly gaining traction among performance obsessives. Unlike Memcached, Redis writes to disk asynchronously. You get the speed of RAM with the persistence of disk.

In a recent deployment for a Norwegian media portal, we saw page generation times drop from 250ms to 45ms simply by moving session handling off the SAN and into a local Redis instance.

Configuration: The "Safety" Setup

To use Redis effectively as a session handler in 2009, you generally need a custom PHP session handler class, as the native PECL extensions are still in early alpha. However, the backend configuration is where the magic happens.

Inside your redis.conf, you don't want the default snapshotting if you are paranoid about data loss. You want to tune the save directives to balance disk I/O against data safety:

# Save the DB on disk:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
save 900 1
save 300 10
save 60 10000

Pro Tip: If you are using CoolVDS, our Xen-based virtualization ensures that your RAM is dedicated, not ballooned. Redis requires physical RAM guarantees. If your host oversells RAM (common with OpenVZ budget providers), the Linux OOM Killer will murder your Redis process first when memory gets tight.

Redis vs. Memcached vs. File System

Here is the breakdown of why we are switching our managed clients to this setup:

The Latency Factor: Why Location Matters

When you offload sessions to a key-value store, network latency becomes a factor, especially if the database is on a separate node. Every millisecond counts.

Hosting your application in the US while your customers are in Oslo or Kyiv introduces 100ms+ of unnecessary round-trip time (RTT). For a session lookup that should take 0.5ms, adding 100ms network lag is counter-productive.

This is why we peer directly at NIX (Norwegian Internet Exchange). If your VPS is in our Oslo datacenter, your latency to local users is practically non-existent. Furthermore, keeping data within Norway satisfies the "Datatilsynet" requirements regarding the Personal Data Act, avoiding the legal gray areas of the US Patriot Act.

Implementation Strategy

You don't need to rewrite your application. If you are using a framework like Zend Framework or Symfony, you can simply swap the Session Adapter.

If you are writing raw PHP 5.2 code, you can use session_set_save_handler to map session open, read, write, and destroy functions to Redis commands. It requires a bit of code, but the performance gains on a high-concurrency VPS are undeniable.

Conclusion

Disk I/O is the most expensive resource on any server. Don't waste it on temporary session data. By implementing Redis, you free up your disk heads (or expensive SAS 15k RPM spindles) to serve your actual database and static assets.

Ready to optimize? Deploy a CoolVDS Xen instance today. We offer true dedicated resources and low-latency connectivity perfect for high-performance data stores.