Apache vs Lighttpd: The Battle for Concurrency and RAM

Let’s be honest: if you are throwing more RAM at a server to fix a load average spike, you aren't fixing the problem. You're just delaying the inevitable crash. It’s 2012, and the C10k problem (handling 10,000 concurrent connections) isn't just a theoretical paper by Dan Kegel anymore. It is the reality for any growing e-commerce site or media portal in Norway.

For decades, the answer to "How do I host a website?" was simply "Apache." It is the IBM of web servers—no one gets fired for choosing it. But with the explosion of AJAX-heavy applications and the need for real-time responsiveness, the Apache process-based model is starting to show its age. Enter Lighttpd (pronounced "lighty"), the lightweight contender that promises to serve static content faster than you can `cat` a file.

I’ve spent the last week migrating a high-traffic Oslo-based news aggregator from a bloated Apache setup to a hybrid architecture. The results were drastic enough that I needed to write this down. If you are running a VPS in Norway and paying for RAM you don't need, read on.

The Heavyweight: Apache HTTP Server (2.2 & 2.4)

Apache is the beast we all know. It powers over 60% of the internet. Its strength lies in its modularity and the ubiquity of .htaccess files. If you are a hosting provider or a dev shop running distinct CMS installations (WordPress, Drupal, Joomla) for multiple clients on one box, Apache is indispensable because it allows per-directory configuration overrides.

The Problem: The Prefork MPM

By default, most CentOS 6 and Debian Squeeze installations ship Apache with the Prefork MPM (Multi-Processing Module). This is thread-safe and plays nice with mod_php, but it is a memory glutton. Every connection spawns a separate process. If your Apache child process takes 25MB of RAM and you get 100 concurrent users, that’s 2.5GB of RAM gone instantly. On a standard 4GB VPS, you are now swapping to disk. And once you swap, you die.

However, Apache 2.4 (released just a couple of months ago) is trying to change the game with the Event MPM. It’s not quite the default everywhere yet, but it moves Apache closer to an async model.

Typical Apache Optimization (httpd.conf):

<IfModule mpm_prefork_module>
    StartServers          5
    MinSpareServers       5
    MaxSpareServers      10
    # Do not set this too high if you value your RAM
    MaxClients          150
    MaxRequestsPerChild 3000
</IfModule>

# Turn off HostnameLookups to save DNS latency
HostnameLookups Off

# Use KeepAlive efficiently
KeepAlive On
KeepAliveTimeout 3

The Challenger: Lighttpd

Lighttpd was born to address the memory leak and concurrency issues of the early 2000s. Unlike Apache's blocking I/O, Lighttpd uses an asynchronous event loop (leveraging epoll on Linux or kqueue on BSD). This means a single process can handle thousands of connections.

In a recent stress test we ran at CoolVDS, serving 1KB static files:

• Apache 2.2 (Prefork): Choked at 850 concurrent users; load average spiked to 15.
• Lighttpd 1.4: Handled 4,000+ concurrent users; CPU load remained under 2.0.

The trade-off? No .htaccess support. All configurations must go in the central lighttpd.conf and the server must be reloaded. For a shared hosting environment, this is a nightmare. For a dedicated application server, it’s a blessing in disguise—it forces centralized, version-controlled configuration.

Basic Lighttpd Configuration (lighttpd.conf):

server.modules = (
    "mod_access",
    "mod_fastcgi",
    "mod_compress",
    "mod_rewrite"
)

server.document-root = "/var/www/html/"
server.max-fds = 2048
server.event-handler = "linux-sysepoll"

# Compression is key for low latency over mobile networks
compress.cache-dir = "/var/cache/lighttpd/compress/"
compress.filetype  = ("text/javascript", "text/css", "text/html", "text/plain")

War Story: The "Holmenkollen" Spike

During the ski festival earlier this year, a client's Magento store (hosted on a legacy provider, not CoolVDS) went down. They were getting hit with traffic spikes of roughly 300 requests per second. The database was fine, but the web server (Apache) had eaten all the RAM, forcing the kernel to invoke the OOM (Out of Memory) killer, which promptly killed MySQL.

We migrated their static assets (images, CSS, JS) to a separate CoolVDS instance running Lighttpd. We kept Apache strictly for the PHP processing.

The Architecture:

Pro Tip: If you are serving traffic to a Norwegian audience, physical proximity matters. The latency from a datacenter in Frankfurt to Oslo is decent (~25ms), but hosting directly in Oslo (connecting via NIX - the Norwegian Internet Exchange) drops that to <5ms. That "snappiness" is noticeable to users. CoolVDS infrastructure is optimized for this exact low-latency routing.

PHP Handling: mod_php vs FastCGI

This is where the battle gets technical. Apache typically uses mod_php, which embeds the PHP interpreter inside the Apache process. It’s fast but heavy. Lighttpd must use FastCGI (usually communicating with php-cgi or the newer php-fpm).

Configuring FastCGI in Lighttpd looks like this:

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"
        ),
        "broken-scriptfilename" => "enable"
    ))
)

This setup segregates the web server from the PHP execution. If PHP crashes, Lighttpd stays up. If Lighttpd is under DDoS attack, it doesn't necessarily starve PHP of resources.

The CoolVDS Factor: Why Underlying Hardware Matters

Software optimization only goes so far. In 2012, many VPS providers are still stuffing 50 users onto a single SATA hard drive. When you use an asynchronous server like Lighttpd, you shift the bottleneck from CPU/RAM to Disk I/O. If your server can handle 10,000 requests, but your disk can't read the files fast enough, your iowait will skyrocket.

This is why we standardized on Enterprise SSD storage for our high-performance tiers at CoolVDS. Traditional spinning rust (SAS 15k) just cannot keep up with the random read patterns of a high-traffic web server. When you combine Lighttpd’s event loop with the near-zero seek time of SSDs, you get a server that feels instantaneous.

Security & Compliance (Datatilsynet)

A quick note on legalities: Under the Norwegian Personal Data Act (Personopplysningsloven), you are responsible for securing user data. Lighttpd has had a history of buffer overflow vulnerabilities in earlier versions. Ensure you are running the latest stable branch (1.4.30+) and hiding server tokens.

server.tag = "CoolVDS-Web" # Don't reveal version numbers!

Verdict

So, which one should you choose for your next deployment?

1. Choose Apache if: You need compatibility with generic CMS plugins, you rely heavily on .htaccess, or your team is not comfortable managing FastCGI processes.
2. Choose Lighttpd if: You are serving high-volume static content (images, downloads), you have a RAM-constrained VPS (512MB or less), or you are building a custom high-performance API.

Ultimately, the best configuration often involves both, or perhaps looking at the rising star, Nginx (though that’s a topic for another post). But whatever software you choose, run it on hardware that doesn't steal your IOPS.

Don't let legacy hardware kill your code's performance. Deploy a CentOS 6 instance with High-Speed SSDs on CoolVDS today and see what 2ms latency to NIX feels like.