Console Login
Home / Blog / Server Optimization / Stop Killing Your Database: High-Performance Session Caching with Redis
Server Optimization ‱ ‱ 1 views

Stop Killing Your Database: High-Performance Session Caching with Redis

@

Stop Killing Your Database: High-Performance Session Caching with Redis

I looked at a `top` output yesterday on a client's dedicated server, and I wanted to scream. The load average was hitting 15.0 on a quad-core box. The culprit? I/O wait.

They were running a high-traffic e-commerce site on Magento, and every single page load was writing session data to the hard disk in /var/lib/php/session. Standard SAS drives, even 15k RPM ones in RAID-10, physically cannot move the actuator arms fast enough to handle 500 concurrent writes per second. The disk queue spikes, the CPU waits, and your site hangs.

Some of you moved sessions to MySQL. Great, now you've replaced disk seeking with table locking. The MyISAM storage engine is crying, and even InnoDB struggles when you have thousands of session updates thrashing your buffer pool.

There is a better way. It's called Redis.

What is Redis? (And why it beats Memcached)

Redis (REmote DIctionary Server) is a relatively new project—released just earlier this year—that is acting like Memcached on steroids. Like Memcached, it stores data in RAM, which means read/write operations take microseconds, not milliseconds.

However, unlike Memcached, Redis has persistence. In a volatile VPS environment, if Memcached restarts, your users get logged out. Their shopping carts vanish. Redis can asynchronously dump data to disk (`rdb` snapshots) without blocking the main process.

The Architecture of Speed

Here is the reality of latency in 2009:

Storage Type Approximate Latency Throughput Limit
7.2k RPM SATA ~12 ms ~80 IOPS
15k RPM SAS (RAID-10) ~4 ms ~350 IOPS
Redis (RAM) < 0.1 ms 100,000+ OPS

Setting up Redis on CentOS 5

Since Redis isn't in the standard yum repositories yet, we compile from source. Don't worry, it compiles in under a minute. It has zero dependencies.

$ wget http://redis.googlecode.com/files/redis-1.0.tar.gz
$ tar xzf redis-1.0.tar.gz
$ cd redis-1.0
$ make
$ ./redis-server redis.conf

Once it's running, you need to configure your PHP application to talk to it. You can use the new phpredis extension or a pure PHP library. For reliability, I prefer configuring the `redis.conf` to ensure we don't lose data if the server hiccups.

Look for this section in `redis.conf`:

# 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

This "snapshotting" gives you the speed of RAM with the safety of disk.

Pro SysAdmin Tip: Do not run Redis on a standard OpenVZ container found at budget hosting providers. OpenVZ shares kernel memory. If a neighbor abuses the RAM, the OOM (Out of Memory) killer might snipe your Redis process. Always use Xen virtualization—like we do at CoolVDS—where your RAM is hard-reserved and protected.

Data Sovereignty and Latency

Performance isn't just about disk speed; it's about network distance. If your customers are in Oslo, Bergen, or Trondheim, hosting your session server in Texas is madness. The speed of light is a hard limit. A round-trip to the US takes 100ms+. That's 100ms added to every page load.

Furthermore, we have the Personal Data Act (Personopplysningsloven) here in Norway and the EU Directive 95/46/EC. Storing user session data (which often contains personal identifiers) on US servers opens you up to privacy concerns, especially with the Patriot Act allowing US agencies to inspect data hosted physically in their jurisdiction.

Hosting locally solves both:

  • Latency: <5ms ping to NIX (Norwegian Internet Exchange).
  • Compliance: Data stays within Norwegian jurisdiction, protected by Datatilsynet guidelines.

The CoolVDS Implementation

At CoolVDS, we don't oversell. We know that technologies like Redis require stable, dedicated RAM. That is why our infrastructure is built on Xen hypervisors with high-performance RAID-10 SAS storage for the persistence layer.

When you deploy a VPS with us, you aren't fighting 500 other users for disk I/O. This stability is critical when you are relying on Redis for session state. If the underlying disk is too slow to write the `rdb` snapshot, Redis can block, causing the very downtime you tried to avoid.

Next Steps

Stop forcing your hard drives to do a RAM job. Install Redis, change your session handler, and watch your server load drop from 15.0 to 0.5 instantly.

Need a sandbox to compile Redis and test the benchmarks yourself? Deploy a Xen VPS on CoolVDS today. We offer raw root access and low-latency connectivity to the Nordic region.

/// TAGS

/// RELATED POSTS

Stop Watching 'wa' in Top: Why Spinning Disks Are the Bottleneck in 2011

Is your server load spiking despite low CPU usage? The culprit is likely I/O wait. We break down why...

Read More →

Stop Waiting on I/O: Supercharging LAMP Stacks with Redis 2.2

Disk latency is the silent killer of web applications. We benchmark Redis vs Memcached, explore the ...

Read More →

WordPress 3.0 Optimization: Architecting for Speed in a Post-LAMP World

WordPress 3.0 "Thelonious" has just dropped. It merges MU and brings custom post types, but it deman...

Read More →

Stop MySQL from Eating Your RAM: Tuning the LAMP Stack for High Load

Is your MySQL 5.1 server choking under load? A battle-hardened guide to my.cnf optimization, InnoDB ...

Read More →

Why Shared Hosting is Suffocating Your PHP Apps (And How to Scale in 2009)

Stop battling 'noisy neighbors' and Apache overhead. Learn how to optimize PHP 5.3, tune MySQL buffe...

Read More →

Cloud Storage in 2010: Why Your SAN is the Bottleneck (And How to Fix It)

As we approach 2010, the "Cloud" buzzword is everywhere, but disk I/O remains the silent killer of p...

Read More →
← Back to All Posts