Apache vs Lighttpd: Survival Guide for High-Traffic VPS

I watched a perfectly good server melt yesterday. It wasn't a hardware failure. The RAID controller was fine. The culprit? A default Apache configuration on a slashdotted blog.

If you are running a Virtual Dedicated Server (VDS) in 2009, you are fighting a war against two things: Latency and RAM. CPU cycles are getting cheaper, but RAM is still the premium resource that separates a snappy site from a swap-file nightmare.

For decades, the Apache HTTP Server has been the undisputed king of the internet. But a challenger, Lighttpd (pronounced "lighty"), is stealing the crown for high-performance setups. Which one should you deploy on your CoolVDS slice? Let's look at the architecture.

The Heavyweight: Apache 2.2

Apache is the default for a reason. It is robust, compatible with everything, and .htaccess files make life easy for developers. However, its strength is its weakness. Most distributions (CentOS 5, Debian Lenny) ship Apache with the Prefork MPM by default.

Prefork is thread-safe, which is great for mod_php, but it processes requests by spawning a separate process for each connection. If you have 500 simultaneous visitors, you need 500 processes. If each process consumes 20MB of RAM, you need 10GB of memory just to keep the lights on. On a standard VPS, that means hitting the swap and killing your load average.

Optimization Strategy for Apache

If you must stay with Apache (perhaps for complex RewriteRules), you have to trim the fat. Disable unused modules and, crucially, tune your KeepAlive settings. High KeepAlive timeouts on Apache are RAM killers because a process sits idle waiting for a client to close the socket.

# /etc/httpd/conf/httpd.conf

# Lower this to free up slots faster
KeepAliveTimeout 3

# Don't let the server spawn until it dies
MaxClients 150
StartServers 5
MinSpareServers 5
MaxSpareServers 10

The Challenger: Lighttpd 1.4

Lighttpd was designed to solve the C10k problem (handling 10,000 parallel connections). Unlike Apache's process-per-connection model, Lighttpd uses an asynchronous, event-driven architecture (specifically epoll on Linux 2.6 kernels).

This means one process handles all connections. It consumes a tiny, fixed amount of RAM regardless of whether you have 10 visitors or 1000. For serving static content (images, CSS, JS), Lighttpd obliterates Apache in benchmarks. It sends files using the sendfile() system call, keeping the data entirely in the kernel without copying it to user space.

Pro Tip: Lighttpd doesn't use mod_php. You must run PHP via FastCGI (php-cgi). This actually makes your setup more stable, as a PHP crash won't take down the web server process.

Sample Lighttpd Config

Configuration in /etc/lighttpd/lighttpd.conf is cleaner and more logical than XML-style config bloat:

server.modules = (
  "mod_access",
  "mod_fastcgi",
  "mod_accesslog"
)

# The magic behind the performance
server.event-handler = "linux-sysepoll"
server.network-backend = "linux-sendfile"

fastcgi.server = ( ".php" =>
  (( "socket" => "/tmp/php-fastcgi.socket",
     "bin-path" => "/usr/bin/php-cgi",
     "max-procs" => 2,
     "idle-timeout" => 20
  ))
)

The Verdict: Which One for Your VDS?

The Hybrid Approach

You don't have to choose. A popular architecture we see on high-end CoolVDS deployments involves putting Lighttpd in front as a reverse proxy to serve images/CSS, while forwarding PHP requests to a backend Apache instance running on localhost. This keeps the memory footprint low while retaining Apache's compatibility.

Infrastructure Matters

Software optimization can only save you so much. If your underlying disk I/O is slow, your database will lock up regardless of your web server choice. This is where the "V" in VDS matters.

At CoolVDS, we don't oversell. We use the Xen hypervisor to ensure strict isolation. When you buy 512MB RAM, you get 512MB of physical RAM, not virtual promises. Our storage backend runs on 15,000 RPM SAS drives in RAID-10. This provides the low latency required for database-heavy applications, essential for ensuring fast response times across Norway.

Furthermore, hosting within our Oslo data center ensures compliance with the Personopplysningsloven (Personal Data Act) and keeps the Datatilsynet happy, while giving your Norwegian users single-digit millisecond latency via NIX (Norwegian Internet Exchange).

Next Steps

If your top command is showing high load and low free memory, it's time to switch. Don't let swap thrashing kill your uptime.

Spin up a Xen-based instance on CoolVDS today and test your own benchmarks.