Apache vs Lighttpd: The Battle for High-Concurrency Supremacy

It is 3:00 AM in Oslo. Your monitoring system just sent you an SMS: load averages are spiking, and httpd processes are consuming 95% of your available RAM. You aren't suffering from a DDoS attack; you simply got linked on a popular tech news aggregator. This is the C10k problem in action—handling ten thousand concurrent connections without your server melting down.

For decades, the answer to "how do I serve a website?" was simply "Install Apache." But in 2011, with the rise of AJAX-heavy applications and massive static media consumption, the monolithic approach of Apache is being challenged. Enter Lighttpd (pronounced "lighty"), a web server designed specifically for speed-critical environments.

As a System Architect at CoolVDS, I've spent the last week migrating high-traffic clusters from standard LAMP stacks to optimized Lighttpd environments. The results? Startling reductions in memory footprint. But is Lighttpd ready to replace the veteran Apache entirely? Let's look at the architecture, the configuration, and the reality of hosting this in Norway.

The Heavyweight: Apache HTTP Server

Apache is the IBM of web servers: nobody gets fired for choosing it. It powers over 60% of the internet for a reason. Its modular architecture allows you to do almost anything directly within the web server process.

The Architecture: Processes and Threads

Apache typically runs in one of two modes (MPMs): Prefork or Worker.

• Prefork: Each request gets a dedicated process. It’s thread-safe and stable (essential for mod_php), but memory-hungry. If you have 512MB RAM, you can only spawn so many processes before hitting swap.
• Worker: Uses threads. Lighter, but requires thread-safe libraries.

Here is a standard optimization block for an Apache 2.2 Prefork setup on a 1GB VPS. Note the MaxClients directive—set this too high, and your server will thrash.

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

The Killer Feature: .htaccess

The biggest argument for Apache is .htaccess. It allows per-directory configuration overrides without restarting the server. For shared hosting or dev environments where you need to rewrite URLs on the fly, this is indispensable.

# Standard WordPress Rewrite Rule in .htaccess
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

The Challenger: Lighttpd

Lighttpd was born to solve the memory exhaustion problem. Unlike Apache's process-per-request model, Lighttpd uses an asynchronous event loop (utilizing epoll on Linux). It handles thousands of connections in a single process with a constant memory footprint.

Pro Tip: If you are serving static assets (images, CSS, JS) for a high-traffic Norwegian news site, putting Lighttpd in front of your heavy backend application can reduce load by 80%.

Configuration: A Different Beast

Lighttpd doesn't use .htaccess. All configuration must be loaded at startup. This improves performance (no file system checks on every request) but decreases flexibility for end-users.

Here is how you configure a Virtual Host in lighttpd.conf. It looks more like code than configuration:

$HTTP["host"] == "www.coolvds-demo.no" {
    server.document-root = "/var/www/html/demo"
    server.errorlog      = "/var/log/lighttpd/demo-error.log"
    accesslog.filename   = "/var/log/lighttpd/demo-access.log"
    
    # Prevent hotlinking
    $HTTP["referer"] !~ "^($|http://www\.coolvds-demo\.no)" {
        url.access-deny = ( ".jpg", ".jpeg", ".png" )
    }
}

Handling PHP: FastCGI

Lighttpd does not embed PHP. It talks to PHP processes via FastCGI. This decouples the web server from the application language, which is arguably cleaner but requires more setup.

fastcgi.server = ( ".php" =>
  (( "socket" => "/tmp/php-fastcgi.socket",
     "bin-path" => "/usr/bin/php-cgi",
     "max-procs" => 4,
     "bin-environment" => (
       "PHP_FCGI_CHILDREN" => "16",
       "PHP_FCGI_MAX_REQUESTS" => "10000"
     ),
     "bin-copy-environment" => ( "PATH", "SHELL", "USER" ),
     "broken-scriptfilename" => "enable"
  ))
)

Performance Benchmarks: The Reality Check

We ran ab (Apache Bench) against both servers hosted on a CoolVDS instance running CentOS 5. The test requested a 5KB static file with 1,000 concurrent users.

The difference is staggering for static content. Apache chokes on context switching, while Lighttpd barely wakes up. However, for dynamic PHP content, the gap narrows significantly because the bottleneck shifts to the PHP interpreter itself.

The Infrastructure Factor: Why Your Host Matters

You can tune your lighttpd.conf until it is a work of art, but software cannot overcome physics. In Norway, latency is the silent killer. If your server is hosted in Germany or the US, your packets are traveling hundreds of milliseconds before they even hit your optimized web server.

Furthermore, disk I/O often becomes the bottleneck before CPU does. At CoolVDS, we have moved away from standard SATA drives for our high-performance tiers. We utilize enterprise-grade SSD storage arrays. When you have a database attempting to write session data for 5,000 users, the mechanical seek time of a spinning hard drive is an eternity.

When deploying in Norway, you must also consider Datatilsynet (The Data Inspectorate) and the Personal Data Act (Personopplysningsloven). Hosting data within Norwegian borders on a provider like CoolVDS ensures you are not subject to foreign data jurisdiction ambiguities—a critical factor for any serious business in 2011.

Which should you choose?

1. Choose Apache if: You rely heavily on .htaccess, you are using a CMS like Drupal or WordPress with complex rewrite rules, or you need modules that don't exist elsewhere. It is the safe, compatible choice.
2. Choose Lighttpd if: You are serving high-volume static media, you have limited RAM (e.g., a 256MB VPS), or you are comfortable managing FastCGI processes manually.

Final Configuration

If you decide to go the Lighttpd route on your CoolVDS instance, ensure you enable the compressor module to save bandwidth. Bandwidth is cheap, but latency is expensive.

server.modules += ( "mod_compress" )
compress.cache-dir = "/var/cache/lighttpd/compress/"
compress.filetype  = ("text/plain", "text/html", "text/javascript", "text/css", "text/xml")

Optimization is a journey, not a destination. Whether you choose the stability of Apache or the raw speed of Lighttpd, the foundation remains the same: robust, low-latency infrastructure. Don't let slow I/O kill your SEO rankings.

Ready to test the difference? Deploy a developer instance on CoolVDS in 55 seconds and benchmark it yourself.