Stop Killing Your Disk I/O: High-Performance Session Caching with Redis on Ubuntu 12.04

If you are still writing PHP sessions to the filesystem in 2012, you are intentionally slowing down your application. I’ve seen it time and time again: a perfectly optimized Magento store or Drupal site hosted in Oslo hits a traffic spike, and the load average skyrockets. It’s not the CPU. It’s not the memory. It’s the disk I/O wait.

Every single page load triggers a read and write operation to /var/lib/php5. When you have 500 concurrent users, that is 500 small, random I/O operations per second. On a traditional spinning hard drive (HDD), this is a death sentence. Even on standard SSDs, the locking overhead of the filesystem adds unnecessary latency.

The solution is not "buy more hardware." The solution is to move ephemeral data where it belongs: into memory. Today, we break down exactly how to replace the default file-based session handler with Redis 2.4 on an Ubuntu 12.04 LTS (Precise Pangolin) stack.

Why Redis Over Memcached?

For years, Memcached was the default choice for in-memory storage. While fast, Memcached is strictly a volatile cache. If your server restarts or the process crashes, poof—every user is logged out instantly. In an e-commerce environment, that means abandoned carts and lost revenue.

Redis (Remote Dictionary Server) solves this. It gives us the speed of memory but adds persistence. We can configure it to dump data to disk asynchronously, meaning if the server reboots, your users stay logged in. For a robust setup in the Nordic market, where reliability is paramount, this distinction is critical.

Step 1: Installing Redis 2.4

We assume you are running a standard LAMP or LEMP stack on Ubuntu 12.04. The repository version is stable and sufficient for our needs.

Once installed, verify it is running. We are looking for the PONG response.

Step 2: Configuring Redis for Sessions

Out of the box, Redis allows connections from anywhere if not firewalled. Given the strict privacy landscape here in Norway and the oversight of Datatilsynet, leaving a database open is negligence. We need to bind it to localhost.

Edit your configuration file:

Ensure the following line is uncommented:

Persistence Configuration

To ensure sessions survive a restart, check the snapshotting rules. The default usually suffices, but for high-traffic sites, you might want to tweak it:

# Save the DB on disk:
# 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
# after 60 sec if at least 10000 keys changed
save 60 10000

Restart the service to apply changes:

Step 3: Linking PHP to Redis

We need the PHP extension to communicate with the Redis daemon. We will use the PECL extension which provides a robust API.

Once compiled, you must enable the extension in your PHP configuration. Create a new ini file:

Step 4: The Switch

Now for the critical part. We tell PHP to stop using the filesystem and start talking to Redis. Edit your php.ini (usually found in /etc/php5/fpm/php.ini for Nginx or /etc/php5/apache2/php.ini for Apache).

Find and modify these two lines:

; session.save_handler = files
session.save_handler = redis

; session.save_path = "/var/lib/php5"
session.save_path = "tcp://127.0.0.1:6379"

Restart your web server to flush the active configuration:

Performance Benchmark

To prove the value, I ran a simple benchmark using `ab` (Apache Bench) on a Magento login page. The test environment was a CoolVDS instance with 2 vCores and 2GB RAM.

Pro Tip: If you are running multiple applications on one server, use the weight parameter or different database indices in the save_path to prevent session collisions.
Example: session.save_path = "tcp://127.0.0.1:6379?database=2"

The Hardware Reality

Software optimization can only take you so far. Even Redis writes to disk eventually (for persistence). If your underlying storage is a shared mechanical drive, you will still see latency during the background save process (BGSAVE). This is where the "noisy neighbor" effect on cheap hosting kills performance.

At CoolVDS, we don't believe in spinning rust. Our infrastructure utilizes enterprise-grade SSD storage and strictly isolated KVM virtualization. When Redis dumps its memory to disk on our platform, the write happens instantly, with zero impact on your active user sessions. Furthermore, our low latency connectivity to the NIX (Norwegian Internet Exchange) ensures that your data travels as fast as your code executes.

Don't let your infrastructure be the bottleneck. Redis is powerful, but it needs a solid foundation.

Ready to eliminate I/O wait? Deploy a high-performance KVM SSD VPS with CoolVDS in under 60 seconds.