Apache vs Lighttpd: The Battle for High-Load Performance

It is 2010, and the internet is no longer just a collection of static HTML pages. We are dealing with Ajax polling, video streaming, and the massive concurrency demands of the "C10k problem." If you are still running a stock Apache configuration on a memory-starved VPS, you are essentially driving a tractor on the Autobahn. It works, but it isn't pretty, and you are holding up traffic.

I have spent the last week migrating a high-traffic news portal in Oslo from a crashing Apache setup to a split architecture. The results were sobering. But the choice isn't binary. Apache 2.2 is a beast for compatibility, while Lighttpd (Lighty) is the speed demon we all want to drive. Let's look at the hard data, the configuration realities, and why your choice of underlying hardware—specifically the virtualization layer provided by hosts like CoolVDS—matters just as much as the software daemon.

The Old Guard: Apache 2.2

Apache is the 'A' in LAMP. It is the bedrock of the internet. Its killer feature is not speed; it is flexibility. The ability to use .htaccess files allows developers to modify server behavior on a per-directory basis without restarting the daemon. For shared hosting environments or complex CMS deployments like Drupal 6 or WordPress 2.9, this is non-negotiable.

However, Apache's standard Multi-Processing Module (MPM), prefork, is a memory hog. It spawns a separate process for every connection. If you have 512MB of RAM and each Apache process consumes 25MB (thanks to mod_php), you hit a hard ceiling quickly. Once you swap to disk, your site dies.

Optimizing the Beast

If you must stay with Apache for compatibility, you have to tune the httpd.conf. Don't trust the defaults on CentOS 5 or Debian Lenny.

# /etc/httpd/conf/httpd.conf

# Typical "Safety" Configuration for 512MB - 1GB VPS

StartServers       4
MinSpareServers    5
MaxSpareServers   10
ServerLimit       50
MaxClients        50
MaxRequestsPerChild  1000

Pro Tip: Calculate your MaxClients by dividing your available RAM (minus OS overhead) by the average process size found via top. If you set this too high, the OOM (Out of Memory) killer will murder your web server during traffic spikes.

The Challenger: Lighttpd 1.4

Lighttpd was born to solve the concurrency problem. Unlike Apache's process-per-connection model, Lighttpd uses an asynchronous event loop (leveraging epoll on Linux 2.6 kernels). This means a single process can handle thousands of connections with a tiny memory footprint.

It is the perfect choice for serving static assets (images, CSS, JS) or for acting as a load balancer. When we moved the static content of that Oslo news portal to Lighttpd, CPU load dropped by 40%.

The Configuration Shift

Lighttpd doesn't use .htaccess. Logic goes into lighttpd.conf. This improves I/O performance because the server doesn't have to stat every directory for a config file, but it annoys developers used to drop-in overrides.

Here is how you set up FastCGI for PHP 5.2, decoupling the execution from the web server process:

# /etc/lighttpd/lighttpd.conf

server.modules += ( "mod_fastcgi" )

fastcgi.server = ( ".php" =>
  (( 
    "host" => "127.0.0.1",
    "port" => 9000,
    "broken-scriptfilename" => "enable"
  ))
)

You then run PHP as a separate service using php-cgi and a spawner like spawn-fcgi. This separation adds stability; if PHP crashes, the web server stays up.

Architecture Comparison: The Trade-offs

Warning: Lighttpd has had issues with memory leaks in earlier 1.4.x versions. Ensure you are running the latest stable release from the repository. If you need absolute "set and forget" stability for dynamic content, Apache is still the safer bet, provided you have the RAM.

The Hardware Foundation: Why CoolVDS Matters

Software optimization can only take you so far. In 2010, the bottleneck is often disk I/O. Apache logs, MySQL writes, and swap usage can bring a standard SATA drive to its knees. This is where your choice of VPS provider becomes a technical decision, not just a billing one.

CoolVDS utilizes Enterprise SAS RAID-10 arrays and strict resource isolation via Xen virtualization. Why does this matter for Apache? Because in a shared environment (like basic shared hosting or oversold OpenVZ containers), "noisy neighbors" can steal your I/O operations. If another user on the node is running a backup script, your Apache processes lock up waiting for disk access.

With CoolVDS, you get dedicated resources. When you tune `innodb_buffer_pool_size` in MySQL, you know that RAM is actually yours, not burstable memory that might disappear.

Local Latency and Compliance

For those of us operating in Norway, latency to the NIX (Norwegian Internet Exchange) is critical. Hosting your servers in Germany or the US adds 30-100ms of latency. That sounds small, but with the TCP handshake overhead of HTTP, it compounds. CoolVDS offers local presence, ensuring your packets don't take a world tour before reaching a user in Trondheim.

Furthermore, we must respect the Personopplysningsloven (Personal Data Act) and the guidelines from Datatilsynet. Keeping customer data within the EEA (or specifically Norway) simplifies your legal landscape compared to relying on the US Safe Harbor framework.

The Verdict

If you are running a complex rewrite-heavy CMS and have the budget for RAM: Stick with Apache, but move your database to a separate CoolVDS instance to free up memory.

If you need to serve high-volume static content, video, or a custom API: Switch to Lighttpd. The efficiency gains are massive.

But remember, a fast web server on slow I/O is useless. Don't let disk latency kill your SEO efforts.

Deploy a Xen-based VPS on CoolVDS today and get the raw I/O throughput your application deserves.