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

It is 3:00 AM. Your Nagios alert screams that load average is spiking past 20.0. Your memory usage is capped out, and swapping has brought your disk I/O to a grinding halt. If you are running a high-traffic site on a standard LAMP stack, the culprit is likely the very software that built the web: Apache HTTP Server.

In the world of high-performance hosting, the C10k problem (handling 10,000 concurrent connections) is the litmus test for systems architects. While Apache is the Swiss Army knife of web servers, its process-based model is struggling to keep up with the explosive growth of dynamic content and AJAX-heavy applications we see in 2011.

Enter Lighttpd (pronounced "lighty"). It promises to handle parallel requests with a fraction of the memory footprint. But is it stable enough for your production environment in Oslo? Let's look at the architecture, the benchmarks, and the hardware reality.

The Architecture Gap: Threads vs. Events

The fundamental difference lies in how these servers handle connections. If you are administrating a CoolVDS instance, you want every megabyte of RAM to serve users, not maintain idle processes.

Apache 2.2: The Process Heavyweight

Apache typically runs with the prefork MPM (Multi-Processing Module) to maintain compatibility with non-thread-safe PHP libraries. This means every single incoming connection spawns a dedicated process.

Under load, your process list explodes. Each Apache child process consumes anywhere from 15MB to 50MB of RAM depending on your loaded modules. Do the math: 500 concurrent users can easily chew through 8GB of RAM. Once physical memory is exhausted, you hit the swap, and your site effectively dies.

Pro Tip: If you are stuck with Apache, you must tune MaxClients in your httpd.conf to prevent swapping. Set it based on your average process size, not an arbitrary number.

# /etc/httpd/conf/httpd.conf

StartServers       8
MinSpareServers    5
MaxSpareServers   20
ServerLimit      256
MaxClients       256
MaxRequestsPerChild  4000

Lighttpd: The Event-Driven Challenger

Lighttpd uses an asynchronous, single-threaded architecture. It leverages epoll() (on Linux 2.6 kernels) to handle thousands of connections within a single process loop. It doesn't block waiting for a read or write operation.

The result? Memory usage remains flat even as traffic spikes. This makes Lighttpd exceptionally potent for serving static content (images, CSS, JS) and offloading dynamic requests to FastCGI backends.

Configuration: Simplicity vs. Compatibility

Apache's killer feature is the .htaccess file. It allows developers to modify server configuration on a per-directory basis without restarting the daemon. This is great for shared hosting but terrible for performance, as the server must check for this file in every directory accessed.

Lighttpd does not support .htaccess. All configuration is centralized in lighttpd.conf. This forces a cleaner, more disciplined approach to server administration.

Here is a snippet showing how efficiently Lighttpd handles PHP via FastCGI compared to Apache's mod_php:

# /etc/lighttpd/lighttpd.conf
server.modules += ( "mod_fastcgi" )

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

By decoupling the web server from the PHP interpreter, you can restart Lighttpd without killing active PHP workers, and you can scale the PHP backend across multiple nodes if needed.

The Hardware Reality: Why SSDs Are Non-Negotiable

Software optimization can only take you so far. In 2011, the biggest bottleneck for database-driven applications (Magento, Drupal, WordPress) is disk I/O. Traditional 7.2k RPM SATA drives—and even 15k SAS drives—struggle when hundreds of concurrent visitors trigger random read/write operations.

At CoolVDS, we have moved aggressively to implement Solid State Drives (SSDs) across our high-performance tiers. The difference is not subtle. While a standard hard drive might push 150 IOPS (Input/Output Operations Per Second), our SSD configurations can handle thousands.

If you switch to Lighttpd but run on a congested mechanical drive, you are solving the memory problem but ignoring the I/O wait problem. You need both efficiency in software and speed in hardware.

Data Sovereignty and Latency in Norway

For our Norwegian clients, physical location is a technical and legal necessity. Latency from Oslo to a server in Texas is around 120-150ms. Latency to a CoolVDS server in our Oslo data center is often under 5ms. That 'snappiness' is something caching cannot fake.

Furthermore, adhering to the Personal Data Act (Personopplysningsloven) means you need to know exactly where your data lives. Hosting with CoolVDS ensures your customer data remains within Norwegian jurisdiction, complying with Datatilsynet requirements without the headache of safe harbor frameworks.

Verdict: Which Should You Choose?

There is no silver bullet, but there is a right tool for the job.

• Choose Apache if: You rely heavily on complex .htaccess rewrite rules, you are using legacy modules that Lighttpd doesn't support, or you need 'set it and forget it' compatibility for a small site.
• Choose Lighttpd if: You are serving high-volume static assets, you are comfortable configuring FastCGI for PHP, and you need to squeeze every ounce of performance out of your VPS RAM.

Regardless of your daemon choice, the foundation matters. Virtualization overhead can steal the CPU cycles you optimized for. We use KVM (Kernel-based Virtual Machine) to ensure true hardware isolation, unlike older container technologies that suffer from "noisy neighbor" syndrome.

Ready to test the difference? Deploy a CentOS 6 instance on CoolVDS today. With our SSD storage and gigabit uplink to NIX, you might find that Apache runs faster than you ever thought possible—or that Lighttpd flies like a rocket.