Is Your Session Handler the Bottleneck?
It is 3:00 AM. Your monitoring system, Nagios, is screaming. Your load average just hit 20.0 on a quad-core box, but CPU usage is only at 15%. You check top and see the culprit immediately: %wa (iowait) is sitting at 80%.
Your disks are thrashing. Why? Because you have 5,000 active users on your PHP application, and every single page load is locking, reading, and writing a session file to /var/lib/php/session. If you are still running on standard 7.2k RPM SATA drives, you are physically limited by the movement of the read/write head. It doesn't matter how much RAM you have if the kernel is blocked waiting for the disk.
I see this every week consulting for e-commerce shops here in Oslo. They throw more hardware at the problem, but they don't fix the architecture. The solution isn't a bigger server; it's moving your session data to where it belongs: memory.
Why Memcached Isn't Enough
For years, the standard answer to this problem was Memcached. It's fast, it's simple, and it works. But ask any CTO who has had to explain to a CEO why every customer's shopping cart emptied simultaneously because a cache node rebooted.
Memcached is volatile. If the service restarts, the data is gone. In 2011, we demand better availability. This is where Redis (Remote Dictionary Server) changes the game. It gives you the in-memory speed of Memcached but adds persistence. With Redis, you can write to memory and asynchronously save to disk (snapshotting) without blocking the client.
The Setup: Redis 2.2 + PHP
Let's get technical. Assuming you are running a standard RHEL 6 or Debian Squeeze environment, getting Redis up requires compiling from source or using the Dotdeb repositories (if you are on Debian).
First, install the phpredis extension. Don't use the pure PHP implementations; they are too slow for high-concurrency environments. You need the C extension.
pecl install redis
Next, configure your php.ini to swap the handler. This tells PHP to stop writing files and start talking to the Redis daemon.
session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379"Reload Apache or PHP-FPM, and suddenly, that I/O wait vanishes. Your response times drop from 200ms to 20ms.
Persistence Tuning
Out of the box, Redis might be configured to snapshot too often for a busy session server. Check your redis.conf. For sessions, we don't need instant durability like a bank transaction, but we want to survive a reboot. A pragmatic config looks like this:
# Save the DB on disk if:
# ... after 900 sec (15 min) if at least 1 key changed
save 900 1
# ... after 300 sec (5 min) if at least 10 keys changed
save 300 10
The Hardware Factor: Why Hosting Matters
Software optimization can only take you so far. Even with Redis, if your underlying VPS is fighting for resources on a crowded node, you will see latency spikes (CPU steal time). This is the dirty secret of cheap hosting.
At CoolVDS, we architect specifically for this. We don't oversell our CPU cores. More importantly, we are deploying high-performance SSD storage arrays. Even if Redis needs to dump its database to disk, the write speed on our SSDs is exponentially faster than the mechanical SAS drives used by most legacy providers.
Pro Tip: If your audience is primarily in Norway, network latency is just as critical as disk I/O. CoolVDS servers are peered directly at NIX (Norwegian Internet Exchange) in Oslo. This keeps your data within national borders—satisfying the strict requirements of the Datatilsynet (Data Inspectorate) and the Personal Data Act—while ensuring your ping times are single-digit milliseconds.
Conclusion
Stop treating sessions as an afterthought. In a high-traffic environment, file-based sessions are a ticking time bomb. By implementing Redis, you gain stability, persistence, and raw speed.
If you are ready to stop fighting I/O wait and start serving traffic, you need a platform that keeps up. Deploy a CoolVDS SSD instance today and experience the difference raw I/O performance makes.