Apache vs. Lighttpd: Winning the C10k Battle on Your VPS
If you are reading this, you have likely just stared at top and watched your wait-IO skyrocket while your free memory vanished. It is the classic nightmare of the system administrator: the Slashdot effect, or simply a successful marketing campaign in Oslo, bringing your server to its knees.
For years, the LAMP stack (Linux, Apache, MySQL, PHP) has been the default. But in 2009, as web applications become more AJAX-heavy and persistent connections become necessary, Apache 2.2 is showing its age. The process-based architecture is heavy. Enter Lighttpd (pronounced "lighty"), the event-driven challenger designed to solve the C10k problem (handling 10,000 concurrent connections).
I have spent the last week migrating a high-traffic Norwegian news aggregator from a bloated Apache setup to a lean Lighttpd configuration. Here is the raw data on why architecture matters, and why your choice of VPS underlying that software is critical.
The Apache Architecture: The Heavy Lifter
Apache is the Swiss Army knife. It supports .htaccess files, which allows developers to modify configuration on a per-directory basis without restarting the server. This is great for shared hosting, but it is a performance killer for a dedicated VPS.
When you run Apache with the default mpm_prefork module, it spawns a separate process for every connection. Each process loads the entire PHP interpreter and all modules.
The math is brutal: If your Apache process takes 25MB of RAM and you have 512MB of RAM on your VPS, you can handle roughly 20 concurrent dynamic requests before you start swapping to disk. Once you hit swap, your site is effectively down.
Typical Apache Config (The Bottleneck)
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0
</IfModule>
Setting MaxClients to 150 on a small VPS is suicide. You are telling the server to commit more RAM than it has.
The Lighttpd Alternative: Event-Driven Speed
Lighttpd works differently. It uses an asynchronous event loop (leveraging the Linux epoll system call). It handles thousands of connections in a single process. It does not embed PHP; instead, it passes dynamic requests to PHP-FCGI processes via FastCGI.
This means static content (images, CSS, JavaScript) is served instantly with negligible memory footprint. We are talking about handling 10,000 idle connections with just a few megabytes of RAM.
Pro Tip: If you cannot ditch Apache completely because of complex mod_rewrite rules, use Lighttpd as a reverse proxy. Serve images and static content via Lighttpd on port 80, and proxy PHP requests to Apache running on port 8080. This offloads 70% of the work from the heavy Apache processes.
Comparison: Resource Usage
| Metric | Apache 2.2 (Prefork) | Lighttpd 1.4.19 |
|---|---|---|
| Architecture | Process-based (Blocking) | Event-based (Asynchronous) |
| Memory per 1k connections | High (Hundreds of MBs) | Low (Single digit MBs) |
| Static File Performance | Good | Excellent (sendfile support) |
| Configuration Complexity | Moderate (.htaccess makes it easy) | High (Strict syntax) |
The Infrastructure Factor: Why CoolVDS?
Software optimization can only take you so far. If your host is overselling the CPU or putting you on slow SATA drives, your iowait will kill you regardless of whether you use Apache or Lighttpd.
At CoolVDS, we do not play games with "burstable" RAM that disappears when you need it. We use enterprise-grade 15k RPM SAS RAID-10 arrays. While not as fast as the emerging SSD technology, our SAS arrays provide the consistent IOPS required for database-heavy workloads. Furthermore, our KVM virtualization ensures that your RAM is truly yours—no noisy neighbors stealing your memory pages.
Latency and Local Compliance
For our Norwegian clients, latency to the NIX (Norwegian Internet Exchange) is paramount. Serving a request in 2ms via Lighttpd is useless if the network round-trip adds 100ms. CoolVDS infrastructure is peered directly for low-latency access across the Nordics.
Additionally, keeping your logs local is increasingly important for compliance with the Personopplysningsloven (Personal Data Act). Configuring Lighttpd to anonymize logs is straightforward if you need to adhere to strict privacy standards:
accesslog.format = "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\""
# Ensure rotation scripts are active in /etc/logrotate.d/lighttpd
Verdict: Which One to Choose?
If you are running a standard corporate site with low traffic and depend on varied .htaccess rules, stick with Apache. It is stable, well-documented, and safe.
However, if you are building the next VG.no or a high-volume image board, Lighttpd on a CoolVDS instance is the only logical choice. You get raw speed, massive concurrency handling, and lower hardware costs.
Ready to test the difference? Don't let IO bottlenecks kill your SEO. Deploy a pure CentOS 5 instance on CoolVDS today and compile your own stack in under 5 minutes.