Is your disk usage spiking while CPU sits idle? It's probably your sessions.

If you are running a high-traffic Magento store or a busy vBulletin forum, you have likely seen the symptoms. Your load average climbs, the site feels sluggish, yet top shows your CPU is barely breaking a sweat. If you look at iostat, however, your disk wait time (%iowait) is through the roof.

The culprit is often the default behavior of PHP: file-based sessions.

By default, PHP writes a small file to /var/lib/php/session for every active user. On a site with 500 concurrent users, this is manageable. On a site with 5,000, the filesystem locking overhead becomes a bottleneck that no amount of CPU power can solve. The solution isn't a bigger server; it's moving session storage to RAM.

Why Memcached isn't always the answer

For years, the standard advice has been "use Memcached." And yes, Memcached is fast. But for session data, it has a fatal flaw: it is purely volatile. If your Memcached daemon crashes or the server reboots, every single user is logged out instantly. That is a bad user experience, and for an e-commerce site, it means abandoned carts.

Enter Redis. With the release of Redis 2.2, we have a solution that offers the speed of in-memory storage with the durability of disk persistence (AOF or RDB snapshots). It is the perfect middle ground for session data.

The Architecture: PHP 5.3 + Redis 2.2

Here is the setup we use for high-performance clients hosted on CoolVDS. We assume you are running a standard RHEL/CentOS 5 or Ubuntu 10.04 LTS environment.

1. Installing the Redis Daemon

Don't rely on the default repositories; they are often outdated. Compile from source to get the stability of the 2.2 branch.

2. The PHP Extension

We need the phpredis extension (written in C) to communicate efficiently. Don't use the pure PHP clients for high-load session handling; the overhead is too high.

Once installed, add the extension to your php.ini configuration:

3. Configuring PHP to use Redis

This is where the magic happens. Instead of writing files to the disk, we tell PHP to speak directly to the Redis TCP socket. Open your php.ini (usually in /etc/php5/apache2/php.ini or /etc/php.ini) and modify the session handlers:

[Session]
; old setting: session.save_handler = files
; old setting: session.save_path = "/var/lib/php/session"

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

Restart Apache (service httpd restart or /etc/init.d/apache2 restart), and your I/O wait will drop immediately.

Pro Tip: If you are running multiple application servers behind a load balancer, point the session.save_path to a centralized CoolVDS instance running Redis. This allows users to hit Web Server A and then Web Server B without losing their login state. Just ensure your firewall (iptables) allows port 6379 on the internal network interface.

The Latency Factor: Why Location Matters

When you move sessions to a remote server, network latency becomes your new bottleneck. Every page load requires a round-trip to the session server.

This is why hosting location is critical. If your users are in Norway, but your VPS is in a generic data center in Germany or the US, you are adding 30-100ms to every single request just for session handshakes.

At CoolVDS, our infrastructure peers directly at NIX (Norwegian Internet Exchange) in Oslo. The latency between our instances is virtually non-existent, and the connection to Norwegian broadband providers is direct. For a database-driven application, that 20ms difference per query aggregates into seconds of saved load time.

Data Sovereignty and The "Datatilsynet"

With the increasing focus on the Personal Data Act (Personopplysningsloven), storing user session data—which often contains identifiable information—requires care. Storing this data on US-controlled clouds can introduce legal gray areas regarding data export.

Using a Norwegian VPS provider like CoolVDS ensures that your session data (and your customer data) physically resides on servers within Norwegian borders, simplifying compliance with local privacy directives.

Benchmarking the Difference

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

The numbers don't lie. By removing the disk from the session equation, we more than doubled the throughput.

Summary

Disk I/O is the most expensive resource on a virtual server. Don't waste it on temporary session files. Redis 2.2 is stable, persistent, and incredibly fast.

If you are ready to stop debugging timeouts and start serving traffic, spin up a high-performance instance. At CoolVDS, we prioritize raw throughput and low-latency access, giving your Redis stack the headroom it needs to perform.