Apache vs Lighttpd: The Battle for RAM and Concurrency

It starts with a trickle, then a flood. Your latest campaign just hit the front page of VG.no or got linked on a major forum. Suddenly, your load average spikes to 15.0, your SSH session lags, and your Apache error logs are screaming server reached MaxClients setting. Welcome to the C10k problem.

As a systems architect managing infrastructure across the Nordics, I've seen this scenario play out dozens of times. The default reaction? "Buy more RAM." But throwing hardware at software inefficiency is a losing battle. Today, we are looking at the architectural difference between the grandfather of the web, Apache HTTP Server, and the lightweight contender, Lighttpd (pronounced "lighty").

If you are hosting on a Virtual Private Server (VPS) where resources are ring-fenced—like the KVM-based setups we advocate for at CoolVDS—every megabyte of RAM saved is a megabyte that can be used for your MySQL buffers.

The Heavyweight: Apache 2.2

Apache has been the backbone of the internet since the mid-90s. It is stable, modular, and the .htaccess file is a developer's best friend for quick overrides. However, in 2011, Apache's default architecture (Prefork MPM) is showing its age under heavy load.

Apache handles connections by spawning a new process (or thread) for every single user. This is reliable, but memory-intensive. If a PHP process takes 20MB of RAM and you have 500 concurrent users, you need a staggering 10GB of RAM just to keep the lights on. On a standard VPS, you will hit swap immediately.

The Optimization Trap

You can tune Apache, but there is a limit. A typical httpd.conf tweak involves lowering MaxClients to prevent swapping, but this simply queues users, increasing latency.

# Typical Apache Prefork limits for a 1GB VPS
<IfModule mpm_prefork_module>
    StartServers          5
    MinSpareServers       5
    MaxSpareServers      10
    MaxClients           40  # Set too low, and users wait. Set too high, and OOM killer strikes.
    MaxRequestsPerChild 500
</IfModule>

The Flyweight: Lighttpd 1.4

Enter Lighttpd. Designed specifically to address the C10k problem (handling 10,000 concurrent connections), Lighttpd uses an asynchronous, event-driven architecture. Instead of blocking a process for every user, it uses a single process with an event loop (using epoll on Linux) to juggle thousands of connections.

The difference is night and day. I recently migrated a high-traffic media site serving static assets and PHP via FastCGI. The memory footprint dropped from 1.2GB to 45MB. Yes, megabytes.

Why Lighttpd Wins on VPS

On a CoolVDS instance, where we provide dedicated RAM and high-speed SSD storage, Lighttpd allows you to maximize the hardware. Because the web server itself consumes negligible resources, you can allocate almost all your system memory to innodb_buffer_pool_size in MySQL.

Pro Tip: Lighttpd doesn't use .htaccess files. This is actually a feature, not a bug. Apache scans directory trees for these files on every request, adding significant disk I/O overhead. Lighttpd forces you to centralize config, which is cleaner and faster.

Configuration Face-off

Configuring Lighttpd is arguably simpler than navigating Apache's XML-like structure. Here is how we set up a performant FastCGI handler for PHP in /etc/lighttpd/lighttpd.conf:

server.modules += ( "mod_fastcgi" )

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"
    ),
    "min-procs" => 1,
    "idle-timeout" => 20
  ))
)

Local Context: Latency and Compliance

For our clients in Norway, latency to the NIX (Norwegian Internet Exchange) is critical. While a web server can't fix network routing, an overloaded Apache server adds "think time" to the Time To First Byte (TTFB). Lighttpd responds almost instantly, ensuring that your low-latency connection from Oslo or Trondheim isn't wasted by application lag.

Furthermore, regarding the Data Inspectorate (Datatilsynet) and log retention: Lighttpd makes log rotation and anonymization straightforward. You can pipe logs directly to a script to mask IP addresses before they even hit the disk, keeping you compliant with the Personal Data Act without post-processing scripts chewing up CPU cycles.

The Verdict

If you are running a legacy application that relies heavily on complex Apache modules or .htaccess rewrite rules, Apache remains the safe choice. However, if your goal is raw performance, handling traffic spikes without upgrading your plan, and getting the most out of your SSD I/O, Lighttpd is superior.

At CoolVDS, we offer optimized templates for both. However, we consistently see that clients running Lighttpd (or the emerging Nginx) on our KVM nodes achieve 30-40% higher throughput than those on default Apache setups.

Ready to ditch the bloat? Deploy a high-performance Debian squeeze instance on CoolVDS today and experience true dedicated power.