Apache vs Lighttpd: Surviving the C10k Problem on Norwegian Infrastructure

It is 3:00 AM. Your monitoring system is screaming. The load average on your primary web node just hit 50.0. You aren't suffering from a DDoS attack; you just got linked by a major news outlet. This is the Slashdot effect. If you are running a standard LAMP stack out of the box, your server is likely already dead. Why? Because Apache is trying to spawn a new process for every single incoming connection, and your RAM just evaporated.

In the world of high-performance hosting, the debate between process-based and event-based web servers is the difference between staying online and timing out. For years, the Apache HTTP Server has been the undisputed king of the internet. It is reliable, modular, and compatible with everything. But recently, a contender has been stripping away market share in the high-load sector: Lighttpd (pronounced "lighty").

As a Systems Architect managing infrastructure across Scandinavia, I have seen too many developers throw hardware at a software problem. Before you upgrade your VPS plan, you need to understand the architecture handling your HTTP requests.

The Heavyweight: Apache HTTP Server

Apache is the tank of the web. It is built to survive anything and run anything. Its architecture—specifically the Pre-fork MPM (Multi-Processing Module)—is designed for stability. When a request comes in, Apache designates a dedicated thread or process to handle it. If that script takes 2 seconds to execute, that process does nothing else for 2 seconds.

The Configuration Reality

The flexibility of Apache comes from .htaccess files. They allow developers to modify server configuration on a per-directory basis without restarting the daemon. However, this convenience comes with a massive I/O penalty. Apache has to stat every directory in the path looking for these files.

If you are stuck with Apache for legacy reasons (like complex mod_rewrite rules), you must tune the mpm_prefork_module in your httpd.conf or apache2.conf. Most defaults are far too optimistic for a standard VPS.

<IfModule mpm_prefork_module>
    StartServers          5
    MinSpareServers       5
    MaxSpareServers      10
    # Do not set this higher than your RAM allows!
    # (Total RAM - OS overhead) / Average Apache Process Size
    MaxClients           150
    MaxRequestsPerChild   3000
</IfModule>

Pro Tip: Check your average process size using top or ps aux. If your Apache processes are consuming 50MB each and you have a 2GB VPS, setting MaxClients to 150 will force your server into swap hell. Once you hit swap on a mechanical drive, your site is down.

The Challenger: Lighttpd

Lighttpd was born to solve the C10k problem (handling 10,000 concurrent connections). Unlike Apache's blocking architecture, Lighttpd is event-driven and asynchronous. It uses a single process with an event loop to handle thousands of connections. It doesn't block waiting for a file read; it moves on to the next request and circles back when the data is ready.

For serving static content (images, CSS, JS), Lighttpd obliterates Apache. It uses the sendfile() system call to ship files directly from the disk cache to the network card, barely touching the CPU.

Configuring Lighttpd for Speed

Lighttpd configuration is strictly central (no .htaccess), which is a security feature and a performance boost. Here is how we tune lighttpd.conf for a high-traffic node in Oslo:

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"

# Compression is vital for latency reduction across Europe
compress.cache-dir = "/var/cache/lighttpd/compress/"
compress.filetype  = ("text/plain", "text/html", "text/javascript", "text/css")

Comparison: When to Use Which?

There is a trade-off. Apache plays nice with PHP via mod_php, making it very easy to set up. Lighttpd requires PHP to run as a separate FastCGI process (using php-fpm or spawn-fcgi). While FastCGI is technically superior for separation of concerns, it adds complexity to the initial setup.

The Hardware Bottleneck: It's Not Just Software

You can tune your web server all day, but you cannot code your way out of bad physics. In 2012, the biggest bottleneck for database-driven applications is Disk I/O. If your MySQL database is waiting on a spinning hard drive platter to rotate, your web server—whether Apache or Lighttpd—sits idle.

This is where CoolVDS differs from the budget providers flooding the market. We don't overprovision our storage. We use enterprise-grade SSD RAID arrays. When Lighttpd issues a read request on a CoolVDS instance, the latency is negligible compared to standard SATA hosting.

Local Data & Compliance

For our Norwegian clients, latency isn't the only concern. The Personopplysningsloven (Personal Data Act) and the Data Protection Directive (95/46/EC) place strict requirements on how we handle user data. Datatilsynet (The Norwegian Data Protection Authority) is very clear about the responsibilities of data controllers.

Hosting outside of the EEA adds legal headaches regarding Safe Harbor frameworks. By keeping your infrastructure on CoolVDS servers located directly in European data centers, you minimize latency to the Oslo Internet Exchange (NIX) and simplify your compliance posture. Speed is useless if your data governance is illegal.

The Verdict

If you are running a legacy Magento store or a heavy Drupal site where you need deep module compatibility, stick with Apache, but put Varnish in front of it. However, if you are building a custom API or serving high-volume media, Lighttpd is the professional choice.

Don't let IOwait kill your application's responsiveness. Deploy a test instance on a CoolVDS SSD VPS today and see the difference raw throughput makes to your load averages.