Apache vs Lighttpd: Surviving the C10k Problem in 2011

The RAM limit is not a suggestion; it's a wall.

If you have ever stared at top while your load average climbs past 10.0 and your swap usage ticks upward, you know the feeling. It's the "Apache Spike." One moment your site is responsive; the next, a Reddit thread links to you, and your httpd processes consume every megabyte of available memory until the OOM killer steps in.

It is 2011. We are seeing a fundamental shift in how the web is consumed. It is no longer just static HTML; it is AJAX polling, long-held connections, and heavy dynamic content. The traditional LAMP stack is under siege by the C10k problem (handling 10,000 concurrent connections). While Apache remains the market leader with over 60% share, Lighttpd (pronounced "lighty") has emerged as the weapon of choice for high-traffic sites like YouTube and Wikipedia.

At CoolVDS, we see this battle play out daily across our Oslo data center. Clients migrate from shared hosting to our VPS platform expecting miracles, but if your software architecture is flawed, even our enterprise hardware can't save you from a configured bottleneck. Let's dissect the differences.

The Incumbent: Apache 2.2

Apache is the tank of the web. It is armored, versatile, and heavy. Its primary architecture (on Linux) usually relies on the Prefork MPM (Multi-Processing Module). This means every incoming connection spawns a dedicated process or uses an idle one. This is excellent for stability—if one PHP script segfaults, it doesn't take down the whole server—but it is terrible for memory efficiency.

Consider a standard configuration in /etc/httpd/conf/httpd.conf:

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

If each Apache process with mod_php consumes 25MB of RAM, and you allow 150 clients, you need nearly 4GB of dedicated RAM just for the web server. In a world where a typical robust VPS has 512MB or 1GB of RAM, Apache becomes a resource hog immediately.

Pro Tip: If you are stuck with Apache, disable .htaccess checks. Setting AllowOverride All forces Apache to check every directory in the path for a config file, generating massive disk I/O. Set it to None and put your rules in the main config.

The Challenger: Lighttpd 1.4

Lighttpd takes a completely different approach. It is event-driven and asynchronous. Instead of spawning a heavy process for every user, it uses a single process with an event loop (using epoll on Linux) to handle thousands of connections simultaneously. It only wakes up when there is data to process.

The memory footprint is negligible. You can handle thousands of keep-alive connections with a few megabytes of RAM. This makes Lighttpd ideal for serving static content (images, CSS, JS) or acting as a load balancer.

However, it handles PHP differently. Since it doesn't embed PHP, it talks to PHP via FastCGI. This separates the web server from the application logic, which is actually a cleaner architecture, though slightly more complex to configure initially.

Configuration Comparison

Real World Scenario: The "Slashdot Effect"

We recently assisted a Norwegian media outlet hosting on a CoolVDS plan. They were running a standard CentOS 5 stack with Apache. When a major news story broke, their traffic spiked from 50 concurrent users to 800.

The result: Apache hit its MaxClients limit. New visitors just saw a loading spinner until the request timed out. The server wasn't down, but it was useless. The load average was low, but RAM was exhausted by idle Keep-Alive connections waiting for data.

The Fix: We swapped Apache for Lighttpd. Because Lighttpd handles Keep-Alive connections without holding a dedicated process hostage, the memory usage dropped from 90% to 15%. The site stayed up, handling the 800 concurrents without breaking a sweat. The latency to the NIX (Norwegian Internet Exchange) remained under 2ms because the server wasn't swapping to disk.

Infrastructure: The Foundation of Speed

Software optimization is critical, but it cannot overcome slow hardware. In 2011, disk I/O is arguably the biggest bottleneck for database-driven sites. Whether you choose Apache or Lighttpd, if your MySQL database is waiting on a slow 7.2k RPM SATA drive, your Time-To-First-Byte (TTFB) will suffer.

This is why CoolVDS utilizes high-performance RAID10 SAS arrays and enterprise-grade SSD caching on our host nodes. Virtualization overhead (especially with older OpenVZ kernels) can introduce latency, which is why we meticulously tune our KVM host parameters to ensure your CPU cycles aren't stolen by "noisy neighbors."

Legal and Latency Considerations

For our Norwegian clients, hosting abroad is becoming a liability. Under the Personopplysningsloven (Personal Data Act) and the watchful eye of Datatilsynet, ensuring your user data stays within Norwegian jurisdiction is safer than relying on Safe Harbor agreements with US providers. Furthermore, the speed of light is immutable. Hosting in Oslo ensures your local users get the snappy response times they expect.

Verdict: Which One to Choose?

• Choose Apache if: You rely heavily on .htaccess files (common in WordPress or Drupal shared environments), or you need specific modules not available elsewhere. It is the safe, compatible choice.
• Choose Lighttpd if: You need to squeeze every ounce of performance out of a VPS, you are serving high-volume static files, or you are comfortable configuring FastCGI.

Ultimately, the best web server is the one you can configure securely. But do not let slow I/O kill your SEO efforts or user experience. Whether you deploy the "heavy lifter" or the "speed demon," ensure your foundation is solid.

Ready to test your configuration? Spin up a CoolVDS instance in Oslo. Our high-performance storage guarantees that your web server—be it Apache or Lighttpd—never waits on the disk.