Apache vs. Lighttpd: The Battle for High-Concurrency Performance

It starts with a simple marketing email. Then a link on Digg or Slashdot. Suddenly, your traffic graph goes vertical. Ten minutes later, your server isn't responding. You SSH in—if you're lucky—and check top. Your load average is 50.0, and Swap is thrashing your disk IO to death. The culprit? Hundreds of Apache child processes, each consuming 20MB of RAM, fighting for resources that simply aren't there.

Welcome to the C10k problem.

In the Norwegian hosting market, where bandwidth is abundant thanks to NIX (Norwegian Internet Exchange) but hardware resources effectively cap your scalability, the choice of web server software is the single most critical architectural decision you will make this year. For decades, the answer was simply "install Apache." In 2010, that answer is no longer automatic. We are seeing a massive shift toward event-driven architectures.

Today, we pit the heavyweight champion, Apache 2.2, against the agile contender, Lighttpd 1.4 (affectionately known as "Lighty").

The Heavyweight: Apache HTTP Server

Apache is the IBM of web servers. It powers over 50% of the internet. It is robust, documented, and compatible with virtually everything. If you are running a standard LAMP stack (Linux, Apache, MySQL, PHP), it just works.

The Architecture Bottleneck

Apache's default configuration usually relies on the Prefork MPM (Multi-Processing Module). This is thread-safe and plays nicely with mod_php. However, it handles concurrency by spawning a separate process for every single connection.

Do the math. If one Apache process consumes 15MB of RAM (a conservative estimate with a few modules loaded), and you have 500 concurrent visitors:

Unless you are paying for an expensive dedicated server, your VPS likely caps out at 2GB or 4GB. Once physical RAM is exhausted, the kernel starts swapping to the hard disk. Since standard 7.2k or even 15k RPM SAS drives are thousands of times slower than RAM, your site effectively dies.

Pro Tip: If you must stay with Apache, strip it down. Disable unused modules in httpd.conf. Do you really need mod_status or mod_autoindex? Remove them to save 1-2MB per process. It adds up.

The Challenger: Lighttpd

Lighttpd was designed specifically to address the memory bloat of the process-based model. It uses an asynchronous, event-based architecture (utilizing epoll on Linux kernels 2.6+).

Instead of spawning a process for every user, Lighttpd runs as a single process (or a few workers) and handles thousands of connections using non-blocking I/O. It manages the same 500 concurrent connections using a fraction of the memory—often just a few hundred megabytes.

Comparison: Static Content Delivery

The "CoolVDS" Factor: Why Hardware Still Matters

Software optimization can only save you so much. Even Lighttpd cannot fix a congested network or a slow disk array. This is where infrastructure choice becomes paramount.

At CoolVDS, we see clients migrating from budget shared hosting to our Xen-based VPS platform specifically to gain control over these variables. Unlike OpenVZ containers where "burst RAM" is often a marketing lie, Xen HVM provides dedicated memory allocation. When you tune your server.max-worker settings, you need to know that RAM is actually yours.

Furthermore, latency is king. For a Norwegian business targeting Oslo or Bergen, hosting in Germany or the US adds 30-100ms of latency per packet. CoolVDS servers are peered directly at NIX, ensuring your TCP handshake completes before an overseas server has even received the SYN packet.

Configuration: Making the Switch

Moving from Apache to Lighttpd requires a shift in thinking, particularly regarding PHP. You cannot use mod_php. You must use PHP-FastCGI. This actually improves stability; if a PHP script crashes, it doesn't take the web server down with it.

Example: Lighttpd FastCGI Config

Here is a snippet to get PHP 5.3 running efficiently on Lighttpd:

fastcgi.server = ( ".php" =>
  (( 
    "socket" => "/tmp/php-fastcgi.socket",
    "bin-path" => "/usr/bin/php-cgi",
    "max-procs" => 4,
    "idle-timeout" => 20,
    "bin-environment" => (
      "PHP_FCGI_CHILDREN" => "4",
      "PHP_FCGI_MAX_REQUESTS" => "10000"
    )
  ))
)

Legal & Compliance: Datatilsynet is Watching

Beyond performance, we must address the regulatory elephant in the room: Personopplysningsloven (The Personal Data Act). As a Norwegian entity, you are responsible for how user data is handled.

When you use Apache with default logging, you are often logging IP addresses, referrers, and user agents to /var/log/httpd/access_log. If you are hosting on a US-based cloud, you are transferring personal data across borders. Hosting locally on CoolVDS ensures data sovereignty. We recommend configuring your web server to rotate and anonymize logs automatically to stay on the right side of the Data Inspectorate.

Verdict: Which Should You Choose?

Stick with Apache if:

• You rely heavily on .htaccess files for complex rewrite rules (converting these to Lighttpd syntax can be tedious).
• You are running a legacy application that demands mod_php specific behaviors.
• RAM is not your bottleneck, but raw CPU processing power is.

Switch to Lighttpd if:

• You serve a high volume of static assets (images, CSS, JS).
• You are running a VPS with less than 1GB of RAM.
• You expect traffic spikes that would cause Apache to fork-bomb your server.

Performance isn't just about code; it's about the synergy between your web server and the metal it runs on. Whether you choose the flexibility of Apache or the raw speed of Lighttpd, running it on high-performance RAID-10 storage and a dedicated Xen hypervisor is the only way to guarantee uptime during the storm.

Ready to test your configuration? Deploy a developer instance on CoolVDS today and experience the difference of local peering.