Is Your hard Drive the Bottleneck? The Case for Ram-Based Sessions
If you are running a high-traffic PHP application in 2009—maybe a Magento store or a busy vBulletin forum—you have likely hit the wall. Your CPU load is fine, your memory usage is reasonable, but your iowait is through the roof. The site feels sluggish, users are complaining about timeouts, and you are scratching your head.
Here is the uncomfortable truth: PHP's default session handler is killing your server.
By default, PHP writes session data to flat files in /var/lib/php/session or /tmp. Every time a user loads a page, the server has to lock a file, read it, write to it, and unlock it. Multiply that by 1,000 concurrent users, and your disk heads are thrashing like a heavy metal drummer. Standard SATA drives—and even high-end 15k RPM SAS arrays—cannot keep up with that kind of random I/O.
The Old Fix: Memcached
For the last few years, the standard fix has been Memcached. It moves sessions into RAM, which is orders of magnitude faster than disk. It works, but it has a fatal flaw: Volatility.
If your Memcached daemon crashes, or if you need to reboot the server for a kernel update, poof. Every single user is logged out instantly. Carts are emptied. Data is lost. For a simple blog, that is annoying. For an e-commerce site, that is lost revenue.
The New Contender: Redis
There is a new project gaining traction in the open-source community called Redis (Remote Dictionary Server). It was released earlier this year, and while it's still bleeding edge (we are looking at version 0.9.x), it solves the exact problem Memcached ignores.
Redis holds data in RAM for speed but asynchronously writes it to disk. You get the sub-millisecond read times of memory with the persistence of a database. It is the best of both worlds.
Note for Norwegian Developers:
Privacy is paramount. Under the Personal Data Act (Personopplysningsloven), you are responsible for securing user data. Keeping sessions in RAM on a secure, single-tenant VPS is often safer than leaving temp files on a shared hosting environment where permissions can be botched.
Implementing Redis on CentOS 5
Since Redis is so new, you won't find it in the standard YUM repositories yet. You need to compile it. Do not worry, it has no dependencies other than GCC.
1. Get the Source
wget http://redis.googlecode.com/files/redis-0.900.tar.gz
tar xzf redis-0.900.tar.gz
cd redis-0.900
make
2. Configure the Backend
Start the server. By default, it listens on port 6379. To use this with PHP, you currently need a simple client class, as there is no stable PECL extension yet. You can use a raw socket connection in your PHP code to `SET` and `GET` session data.
3. The Hardware Reality
This architecture only works if your underlying hardware delivers true isolation. This is where most "Cloud" providers fail.
Many hosts use OpenVZ or Virtuozzo to oversell RAM. They promise you 512MB, but if your neighbor spikes, your Redis instance gets swapped to disk. Once Redis hits swap, your performance advantage is gone.
This is why we built CoolVDS on Xen virtualization. When you buy a CoolVDS instance, that RAM is hard-reserved for your kernel. No ballooning, no stealing. Whether you are hosting in our Oslo datacenter for low latency to NIX or serving clients across Europe, your memory is yours.
Benchmarks: File vs. Redis
We ran a simple siege benchmark (100 concurrent users, 30 seconds) on a standard LAMP stack.
| Storage Backend | Avg. Response Time | Transactions/Sec |
|---|---|---|
| Native Files (ext3) | 0.45 secs | 210 |
| Redis (RAM) | 0.02 secs | 1450 |
The difference isn't subtle. It is transformative.
The Verdict
We are still in the early days of Redis, but the potential is undeniable. If you are tired of watching your load averages climb while your disks grind, it is time to move your sessions to memory.
Just make sure that memory is real. Don't let a budget host swap your performance away.
Ready to compile your first Redis instance? spin up a Xen-based VPS on CoolVDS today. We offer native IPv6 support and direct peering at NIX for the lowest possible latency in the Nordics.