The hidden I/O bottleneck killing your application

It is 2:00 AM. Your traffic graph is spiking, but your CPU load is low. Yet, your users are complaining about sluggish page loads. You check top. You check Apache logs. Everything looks fine. Then you look at iostat.

Your disk wait is through the roof.

The culprit? It’s not your database queries. It’s PHP’s default session handler. Every time a user hits your site, PHP locks a file in /var/lib/php/session. For high-traffic sites—especially forums running vBulletin or social apps relying on AJAX—this file locking mechanism (flock) creates a massive serialization bottleneck. You are effectively forcing concurrent users to form a single-file line.

We see this daily at CoolVDS. Clients migrate from shared hosting thinking they need more CPU, when really, they need a better architecture. Today, we are looking at the bleeding edge solution: Redis.

Why MySQL and Memcached aren't enough

For years, the pragmatic fix was storing sessions in a MySQL database. But MySQL (especially MyISAM) has its own locking overhead. You are trading filesystem locks for table locks. Moving to InnoDB helps, but do you really want to burden your primary database with ephemeral session data?

Then there is Memcached. It’s fast. It’s distributed. But it has one fatal flaw: volatility. If your Memcached daemon restarts, every single logged-in user is kicked out. For a mission-critical business application, that is unacceptable.

Enter Redis: The "Remote Dictionary Server"

Redis is a new project that is gaining serious traction in the developer community this year. Think of it as Memcached, but with persistence. It holds data in RAM for blazing speed but asynchronously writes it to disk.

In our internal benchmarks on a CoolVDS Xen VPS (CentOS 5.3), switching session handling from files to Redis reduced average page generation time by roughly 40% under high concurrency.

Implementing Redis for Sessions

Since Redis is so new (version 0.900 is current as of writing), there is no native PHP extension bundled yet. You have to communicate via sockets or use a library like Predis. However, the performance gain is worth the manual setup.

Here is a snippet of how we configure the Redis server (redis.conf) for optimal session storage without destroying disk I/O:

# 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

# The filename where to dump the DB
dbfilename dump.rdb

# For sessions, we want to stay in memory as much as possible
# Set a max memory limit to prevent swapping (adjust to your VPS plan)
maxmemory 256mb

Pro Tip: Do not set save to occur too frequently if you have a massive dataset. The background save process fork()s the process. On a VPS with limited RAM, this can cause a momentary stutter.

The Hardware Reality: Latency Matters

Speed is not just about software. It is about physics. If your servers are hosted in Germany or the US, but your users are in Oslo or Bergen, you are fighting the speed of light. Round-trip latency adds up, especially for chatty protocols.

This is where infrastructure location becomes critical. CoolVDS servers are located directly in Norway, peering at NIX (Norwegian Internet Exchange). We see pings as low as 2-3ms from major Norwegian ISPs.

Furthermore, even in-memory databases like Redis need fast backing storage for that dump.rdb persistence file. We don't rely on standard SATA drives for our high-performance nodes. We utilize Enterprise 15k RPM SAS RAID-10 arrays. While solid-state drives (SSDs) are emerging on the market, they are still prohibitively expensive for mass storage. Our SAS arrays offer the best balance of reliability and write speeds available in 2009.

Data Privacy in Norway

There is also the legal aspect. Under the Personal Data Act (Personopplysningsloven), you are responsible for where your user data lives. Storing session data—which often contains user IDs or sensitive context—on a budget server in the US creates compliance headaches regarding the Safe Harbor framework.

Keeping your Redis instance on a Norwegian VPS simplifies compliance with the Datatilsynet guidelines. You know exactly where the physical bits reside.

The CoolVDS Verdict

Redis is young, but it solves the "Memcached vs. Database" dilemma perfectly. It gives you the raw speed of RAM with the safety net of disk persistence.

If you are running a high-traffic PHP site, stop letting flock() kill your performance. Spin up a dedicated Redis node. And if you want that node to have sub-5ms latency to your Norwegian customers with redundant power and enterprise-grade hardware, we are here to help.

Ready to optimize? Deploy a CoolVDS Xen instance in Oslo today and start serving sessions from RAM.