Apache vs Lighttpd: The Battle for Concurrency in 2012

It is 3:00 AM in Oslo. Your monitoring system is screaming. Your server load just hit 15.0, and your SSH session is lagging so badly you can't even type top. The culprit? Usually, it's the web server process forking itself into oblivion.

For years, the LAMP stack (Linux, Apache, MySQL, PHP) has been the bread and butter of hosting. But as traffic scales and the "C10k problem" (handling 10,000 concurrent connections) becomes a reality for more than just Silicon Valley giants, the traditional Apache Prefork model is showing its age. Enter Lighttpd ("Lighty"), the event-driven architecture designed to sip RAM while serving static assets at wire speed.

In this analysis, we are going to strip away the marketing fluff. We will look at how these two daemons handle memory management, how to tune them on a CentOS 6 environment, and why hardware choices—specifically the SSD storage we use at CoolVDS—can save you when your configuration isn't perfect.

The Architecture Gap: Threads vs. Events

The fundamental difference lies in how they handle connections. This isn't just academic; it dictates how much RAM you need to buy.

Apache (The Process Heavyweight)

Standard Apache 2.2 usually runs with the Prefork MPM (Multi-Processing Module). This is safe and reliable, especially for non-thread-safe PHP libraries. However, it creates a separate system process for every single incoming request. If you have 200 users downloading images, you have 200 Apache processes consuming RAM.

Here is a typical nightmare scenario configuration often found in /etc/httpd/conf/httpd.conf on unoptimized servers:

<IfModule prefork.c>
StartServers       8
MinSpareServers    5
MaxSpareServers   20
ServerLimit      256
MaxClients       256
MaxRequestsPerChild  4000
</IfModule>

If each Apache process consumes 25MB of RAM (common with mod_php loaded), and you hit MaxClients 256, you need 6.4 GB of RAM just for the web server. If your VPS has 4GB, you are swapping to disk. Once you swap, your site is effectively down.

Lighttpd (The Event Loop)

Lighttpd uses an asynchronous event loop (specifically epoll on Linux). It runs as a single process (or very few) and handles thousands of connections by managing state transitions rather than blocking processes. It doesn't care if a client is on a slow EDGE connection in the mountains of Finnmark; it doesn't hold a process hostage while waiting for the data.

A basic /etc/lighttpd/lighttpd.conf setup for high performance looks vastly different:

server.modules = (
  "mod_access",
  "mod_alias",
  "mod_compress",
  "mod_redirect",
  "mod_rewrite",
)

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

static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )

With this setup, serving 1,000 static images might consume only a few megabytes of memory.

Real World Scenario: The Magento "Black Friday" Spike

Last month, we migrated a client running a heavy Magento store targeting the Nordic market. They were hosted on a traditional spinning-disk VPS with a competitor. Every time they sent a newsletter, the server crashed.

The Diagnosis: Apache was hitting the MaxClients limit. The processes were fighting for CPU time, and the disk I/O was saturated by Apache writing logs and the OS trying to swap memory.

The Fix: We didn't just switch software; we switched infrastructure philosophy. We moved them to a CoolVDS KVM instance backed by Solid State Drives (SSD). The high IOPS of SSDs meant that even if the server touched swap slightly, it didn't lock up the entire OS.

Then, we deployed Lighttpd as a static asset proxy in front of Apache (though you could replace Apache entirely if you use PHP-FPM).

Pro Tip: If you are stuck with Apache for `.htaccess` compatibility, use Nginx or Lighttpd as a reverse proxy. Let the lightweight server handle images, CSS, and JS. Let Apache handle only the complex PHP logic. This reduces the Apache process count significantly.

Configuration: PHP-FPM is Mandatory

In 2012, running PHP as an Apache module (mod_php) is still default, but it is inefficient. For Lighttpd, you must use FastCGI. This separates the web server from the PHP interpreter.

Here is how you bridge Lighttpd to PHP on CentOS 6:

# Install lighttpd-fastcgi
yum install lighttpd-fastcgi php-cli

# Edit /etc/lighttpd/modules.conf to enable fastcgi
server.modules += ( "mod_fastcgi" )

# Configure the socket in lighttpd.conf
fastcgi.server = ( ".php" =>
  (( 
    "socket" => "/tmp/php-fastcgi.socket",
    "bin-path" => "/usr/bin/php-cgi",
    "max-procs" => 2,
    "idle-timeout" => 20,
    "bin-environment" => (
      "PHP_FCGI_CHILDREN" => "4",
      "PHP_FCGI_MAX_REQUESTS" => "10000"
    ),
    "min-procs" => 1,
  ))
)

Restart the service to apply changes:

/etc/init.d/lighttpd restart

This ensures that PHP crashes don't take down the web server, and web server restarts don't kill active PHP tasks.

The Norwegian Context: Latency and Compliance

When hosting for a Norwegian audience, physical distance matters. A packet traveling from a budget host in Texas to Oslo takes roughly 120-150ms. From a CoolVDS datacenter in Europe, it takes 20-30ms. In a TCP handshake (SYN, SYN-ACK, ACK), that latency triples before the first byte is even sent.

Furthermore, with the Datatilsynet (Norwegian Data Inspectorate) enforcing stricter interpretations of the Personal Data Act (Personopplysningsloven), keeping data within the EEA is becoming a critical requirement for businesses handling customer data. Hosting on US-based clouds introduces legal gray areas regarding the Patriot Act that many Nordic CTOs prefer to avoid.

The Verdict: Which One Should You Choose?

There is no silver bullet, but here is the breakdown based on our benchmarks:

Why Infrastructure Underpins Software

You can tune lighttpd.conf all day, but if your host puts 50 customers on a single SATA drive, your I/O wait times will destroy your performance. This is the "noisy neighbor" effect common in OpenVZ containers.

At CoolVDS, we use KVM virtualization. This means your RAM is reserved, not oversold. And with our pure SSD storage arrays, even heavy database writes won't block your web server from delivering pages. In 2012, speed is the primary differentiator for SEO and user retention. Don't let legacy hardware be your bottleneck.

Ready to stop swapping? Spin up a CoolVDS SSD instance today and see the difference raw I/O power makes for your stack.