Apache vs Lighttpd: Survival of the Fittest

If you are still running a default Apache 2.2 configuration on a high-traffic node, you are likely burning money. As a systems architect managing infrastructure across the Nordic region, I see the same tragedy every week: a perfectly good server brought to its knees not by CPU load, but by memory exhaustion.

The scenario is classic. Your site gets linked on a popular Norwegian news portal or Digg. Traffic spikes. Apache spawns hundreds of child processes. Your RAM vanishes. The kernel invokes the OOM (Out of Memory) killer, or worse, you hit the swap file. Once you hit swap on a mechanical drive—even a fast 15k RPM SAS drive—your latency to the Norwegian Internet Exchange (NIX) goes from 2ms to 2000ms. Your site is down.

Today, we are dissecting the two major contenders for serving the web in 2010: the ubiquitous Apache HTTPD and the lightweight challenger, Lighttpd (Lighty).

The Heavyweight: Apache 2.2

Apache is the IBM of web servers. It is reliable, modular, and compatible with everything. If you need to run PHP via mod_php, Perl, or Python, Apache makes it easy. The power of .htaccess files allows developers to override configuration on a per-directory basis without pestering the sysadmin.

However, this flexibility comes with a massive architectural cost: the Process-Based Model (specifically the Prefork MPM). For every client connection, Apache spawns a separate process (or thread, depending on the MPM). Each process carries the overhead of the entire configuration and loaded modules.

The Configuration Trap

In your httpd.conf, you might see this:

<IfModule mpm_prefork_module>
    StartServers          5
    MinSpareServers       5
    MaxSpareServers      10
    MaxClients          150
    MaxRequestsPerChild   0
</IfModule>

The MaxClients directive is the ceiling. If set to 150, the 151st user gets queued. If you raise it to 500 but your server only has 2GB of RAM, and each Apache process consumes 15MB, you will crash the server. It is a simple, brutal math equation.

The Challenger: Lighttpd 1.4

Lighttpd was designed to solve the C10k problem—handling 10,000 concurrent connections. Unlike Apache, Lighttpd uses an Asynchronous Event-Driven Model. It runs as a single process and uses the kernel's epoll() system call (on Linux) to handle thousands of connections without the context-switching overhead of threads or processes.

Pro Tip: Lighttpd is not magic. It excels at static content (images, CSS, JS). If you use it for PHP, you must use FastCGI, which offloads the processing to a separate PHP-CGI process pool. This separation is actually a stability feature, preventing a bad script from taking down the web server.

Optimizing Lighttpd for Linux

To get maximum performance on a CoolVDS Linux instance, ensure you are using the correct event handler in lighttpd.conf:

server.max-fds = 2048
server.event-handler = "linux-sysepoll"
server.network-backend = "linux-sendfile"

This configuration allows the server to push files directly from the filesystem cache to the network card, bypassing user-space memory entirely. The result? CPU load stays flat even during traffic spikes.

Head-to-Head Comparison

War Story: The "Datatilsynet" Audit

We recently assisted a Norwegian e-commerce client expecting an audit from Datatilsynet regarding data logging. Their existing Apache setup was logging so heavily during peak hours that the I/O wait was causing transaction timeouts. The logs were on the same physical spindle as the database.

We moved their static assets (product images) to Lighttpd. By offloading the static requests, we reduced the Apache process count by 80%. This freed up RAM for the MySQL innodb_buffer_pool, drastically improving database performance without upgrading the hardware. The logs for images were piped to a separate syslog facility, reducing disk contention.

The Verdict: Which One for Your VDS?

If you are hosting a complex CMS with varied plugins requiring .htaccess trickery, Apache remains the standard. It just works. However, you must calculate your RAM requirements carefully against the MaxClients setting.

If you are serving video, high-volume images, or a dedicated API, Lighttpd is superior. It respects your hardware resources.

The CoolVDS Advantage: At CoolVDS, we provide pure KVM virtualization. Unlike OpenVZ containers where "guaranteed" RAM is often a lie told by oversold hosts, our memory allocation is strict and dedicated. Whether you choose the raw power of Apache or the efficiency of Lighttpd, our SSD-cached storage arrays ensure that your I/O never becomes the bottleneck.

Don't let a default config file decide your uptime. Spin up a Debian Lenny instance on CoolVDS today and benchmark the difference yourself.