Is Your Hard Drive the Reason Your App Feels Sluggish?
It is 2011. We have multi-core processors and gigabit uplinks, yet 90% of the PHP applications I audit are still making a fundamental mistake: they write user sessions to the disk.
If you are running a standard LAMP stack (Linux, Apache, MySQL, PHP), check your php.ini. You will likely see this default behavior:
session.save_handler = files
Every time a user clicks a link, the server halts, seeks a file in /var/lib/php5/sessions, locks it, reads it, and writes it back. On a site with 50 concurrent users, it's negligible. On a site with 5,000 concurrent usersâlike the Magento store I optimized last weekâthis creates massive I/O wait (iowait) spikes. Your CPU sits idle while the hard drive screams.
The solution isn't a faster disk (though SSDs are helping). The solution is to stop using the disk entirely. Enter Redis.
Redis vs. Memcached: Why Redis Wins in 2011
For years, Memcached was the go-to for in-memory storage. But with the release of Redis 2.2, the argument is settled for session management. Unlike Memcached, Redis offers persistence. If your web server restarts, Memcached loses all active user sessionsâshopping carts empty, users get logged out. It is a disaster.
Redis allows us to configure snapshotting (RDB) or Append Only Files (AOF), meaning we get the speed of RAM with the reliability of a disk.
The Setup: getting Redis 2.2 Running
Letâs get your hands dirty. Assuming you are on a Debian Squeeze or Ubuntu 10.04 LTS system, you might need to compile from source to get the latest features, as apt repositories can be outdated.
$ wget http://redis.googlecode.com/files/redis-2.2.2.tar.gz
$ tar xzf redis-2.2.2.tar.gz
$ cd redis-2.2.2
$ make
Once the daemon is running, you need the PHP extension. Don't use the generic implementations; use phpredis (written in C) for maximum throughput.
$ pecl install redis
Now, modify your php.ini to point session handling to the Redis instance:
[Session]
session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379?weight=1&timeout=2.5"
Restart Apache. Done. Your session reads are now happening in nanoseconds via RAM, not milliseconds via rotating platters.
The "Norwegian" Context: Latency and Law
Performance isn't just about software; it's about physics. Light travels at a finite speed. If your target audience is in Oslo, Bergen, or Trondheim, hosting your database in a budget data center in Texas or even Frankfurt introduces unavoidable network latency.
When you move sessions to Redis, the application becomes incredibly snappy because the "wait" time for data retrieval drops to near zero. However, this exposes network latency even more.
Pro Tip: Network stability is the silent killer of Redis. Since Redis relies on TCP, a jittery connection between your web head and your data store causes timeouts. This is why at CoolVDS, we emphasize low-latency internal networks for our VPS nodes.
Compliance with Datatilsynet
We also need to address the elephant in the room: Personopplysningsloven (The Personal Data Act). When you store session dataâwhich often contains user identifiersâyou are processing personal data.
Keeping this data on servers physically located in Norway simplifies your compliance with the EU Data Protection Directive (95/46/EC). You know exactly where the physical RAM chips reside. If you use a nebulous "cloud" provider based in the US, you enter a legal gray area regarding Safe Harbor data transfers.
Hardware Matters: Not All RAM is Created Equal
Virtualization technology has come a long way, but "noisy neighbors" remain a problem. In a shared hosting environment, or on cheap VPS oversellers, another user's intense database query can flush your Redis data out of the CPU L2 cache.
This is where architecture choices define success. We built CoolVDS on top of KVM (Kernel-based Virtual Machine). Unlike OpenVZ (which shares a kernel), KVM provides strict resource isolation. When you allocate 2GB of RAM for your Redis instance on CoolVDS, that memory is yours. It doesn't get swapped out because a neighbor decided to run a backup script.
Conclusion
Moving sessions to Redis is one of the highest ROI changes you can make to a PHP application in 2011. It reduces load on your primary MySQL database and eliminates disk I/O bottlenecks.
But software config is only half the battle. You need a platform that respects the hardware requirements of high-performance data stores. Don't let a slow network or oversold RAM negate your optimization efforts.
Ready to speed up? Deploy a Debian Squeeze instance on CoolVDS today and see how fast your sessions can really fly.