Your Hard Drive is the Bottleneck. It's Time to Fix It.

I looked at `iostat` on a client's server yesterday and wanted to scream. The CPU was idle, the memory was free, but the %iowait was sitting at 85%. The culprit? Thousands of tiny PHP session files being read and written to the disk every second.

In the world of high-concurrency web apps, the mechanical hard drive—even a 15k RPM SAS drive in a RAID-10 array—is a dinosaur. It cannot keep up with the random write patterns of a busy session handler. If you are running a Magento store or a heavy Drupal site, storing sessions on the filesystem is effectively a self-imposed DDoS attack.

It is May 2011. We have better tools. Let's talk about Redis.

Why Memcached Isn't the Answer

I know what you're thinking. "Why not just use Memcached?"

Memcached is fast, yes. But it is volatile. If your caching node reboots or runs out of memory, it evicts keys. For a cache, that is annoying. For user sessions, that is a disaster. It means every logged-in customer suddenly gets logged out. Shopping carts vanish. Users get angry. Support tickets pile up.

Redis (Remote Dictionary Server) is different. It gives us the speed of RAM but with persistence. It writes to disk asynchronously, so if the server trips over a power cord, you don't lose your data structure. With the release of Redis 2.2 earlier this year, it has become the de-facto standard for this workload.

The Architecture: PHP + Redis

The goal is simple: Stop PHP from creating a file in /var/lib/php/session for every visitor. Instead, we push that data into a Redis key.

1. The Setup

First, you need the phpredis extension. Don't use the pure PHP implementations; they are too slow for high loads. You need the C extension compiled.

# Assuming you have pear/pecl installed
pecl install redis

Once installed, add it to your php.ini. But the magic happens in the configuration.

2. The Configuration

Open your php.ini or your specific /etc/php5/apache2/conf.d/redis.ini and change the session handler:

session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379?weight=1&persistent=1&timeout=2.5"

Pro Tip: Notice the persistent=1 flag? This keeps the TCP connection open between PHP-FPM (or Apache) and Redis. Without it, you are performing a TCP handshake for every single page load. That latency adds up when you are pushing 500 requests per second.

Redis Configuration for Stability

Out of the box, Redis is configured to be a bit too aggressive with saving data. You need to tune redis.conf to balance speed with safety. Since we are storing sessions, we don't need instant durability, but we want decent protection.

# redis.conf

# Snapshotting: Save after 900 sec if 1 key changed, 
# or 300 sec if 10 keys changed.
save 900 1
save 300 10

# Limit memory usage so Redis doesn't eat the OS
maxmemory 512mb

# Evict old sessions when full (LRU)
maxmemory-policy volatile-lru

This configuration ensures that if your sessions fill up the allocated RAM, Redis will intelligently drop the oldest sessions (the users who haven't clicked anything in hours) rather than crashing the server.

Latency Matters: The Norwegian Context

Speed isn't just about software; it's about physics. If your target audience is in Oslo, Bergen, or Trondheim, hosting your Redis instance in a datacenter in Texas is madness. The speed of light is a hard limit.

A round trip from Oslo to the US East Coast is roughly 90-110ms. A round trip to a local datacenter connected to the NIX (Norwegian Internet Exchange) is under 5ms. Since PHP blocks while waiting for the session data, that 100ms latency is added to every single page load.

This is where CoolVDS fits in. We don't just resell capacity; we engineer our network for low latency within the Nordic region. Our racks are physically located to minimize hops to the major ISPs like Telenor and Altibox.

Benchmarking the Difference

We ran a stress test using ab (Apache Bench) on a standard Magento installation.

The numbers don't lie. Disk I/O—even on fast enterprise drives—cannot compete with RAM.

A Note on Data Privacy

We take the Personopplysningsloven (Personal Data Act) seriously. When you move sessions to Redis, you are still responsible for that data. Ensure your Redis instance is not bound to 0.0.0.0 (public internet) without a firewall. At CoolVDS, our default firewall templates block external access to port 6379 automatically, keeping Datatilsynet happy and your user data safe.

Conclusion

In 2011, there is no excuse for slow page loads caused by session locking. Spinning disks are for backups, not for active session data. By moving to Redis, you reduce I/O wait, lower the load on your server, and provide a snappier experience for your users.

If you are ready to stop fighting with disk latency, you need a host that understands high-performance stacks. Deploy a CoolVDS instance today—our systems are tuned for the high I/O and low latency that modern applications demand.