The C10k Reality Check
It is 3:00 AM in Oslo. Your monitoring system just sent you a critical alert. Your load average has spiked to 15.00, and your swap usage is climbing faster than a climber on Galdhøpiggen. The culprit? Apache is spawning child processes until your RAM evaporates.
This is the reality for many sysadmins running high-traffic sites on standard hardware. While hardware is getting cheaper, efficiency still matters. In the battle for concurrency, the choice of web server is your most critical architectural decision. Today, we are pitting the heavy-hitting veteran, Apache HTTP Server 2.2, against the speed-obsessed challenger, Lighttpd 1.4 (affectionately known as "Lighty").
At CoolVDS, we see this constantly. Clients migrate their LAMP stacks to our high-performance KVM nodes, but they bring their bloated configurations with them. Even with our enterprise-grade SSD storage reducing I/O wait times, a misconfigured web server can bring a system to its knees.
The Contender: Apache 2.2 (The Tank)
Apache is the default for a reason. It is reliable, universally supported, and the .htaccess file allows for per-directory configuration overrides which developers love. However, its architecture is process-based (specifically the Prefork MPM). Every time a user connects, Apache spawns a new process (or thread, depending on MPM) to handle that connection.
This is fine for 50 users. It is disastrous for 5,000.
The Memory Bloat Problem
In a standard CentOS 6 setup, an Apache process with PHP loaded might consume 20MB to 30MB of RAM. If you have a VPS with 1GB of RAM and you get 50 concurrent hits:
50 * 25MB = 1250MB
You have just hit swap. The server begins thrashing. Your latency to the NIX (Norwegian Internet Exchange) jumps from 2ms to 200ms.
Optimizing Apache for Survival
If you must stay with Apache (perhaps for mod_rewrite rules that are too complex to port), you must clamp down on the MaxClients directive. Do not trust the defaults.
Open your config:
vi /etc/httpd/conf/httpd.conf
Calculate your limit based on available RAM, not total RAM. Leave room for MySQL.
<IfModule prefork.c>
StartServers 8
MinSpareServers 5
MaxSpareServers 20
ServerLimit 256
MaxClients 150 # <-- Lower this if you are swapping!
MaxRequestsPerChild 4000
</IfModule>
The Challenger: Lighttpd (The Jet Fighter)
Lighttpd was designed to solve the C10k problem (handling 10,000 parallel connections). Unlike Apache's blocking I/O, Lighttpd uses an asynchronous, event-driven architecture. In Linux environments, it utilizes the epoll() system call to handle thousands of connections within a single process loop.
Pro Tip: Lighttpd doesn't embed PHP. You must use PHP-FPM (FastCGI Process Manager). This separates the web server from the script execution, allowing you to tune them independently. This is the standard deployment model on CoolVDS managed hosting tiers.
Configuration: Simplicity and Speed
Lighttpd's configuration is clean. There are no .htaccess files, which is actually a performance feature—the server doesn't waste I/O stat() calls checking every directory for overrides.
Here is how you enable FastCGI in /etc/lighttpd/lighttpd.conf to handle PHP traffic efficiently:
server.modules += ( "mod_fastcgi" )
fastcgi.server = ( ".php" =>
(( "socket" => "/tmp/php-fastcgi.socket",
"bin-path" => "/usr/bin/php-cgi",
"max-procs" => 4,
"bin-environment" => (
"PHP_FCGI_CHILDREN" => "16",
"PHP_FCGI_MAX_REQUESTS" => "10000"
),
"bin-copy-environment" => ( "PATH", "SHELL", "USER" ),
"broken-scriptfilename" => "enable"
))
)
The Event Handler
To ensure you are getting maximum throughput on our CentOS 6 nodes, verify your event handler is set to linux-sysepoll:
server.event-handler = "linux-sysepoll"
server.network-backend = "linux-sendfile"
Head-to-Head: Static File Benchmarks
We ran a simple ab (Apache Bench) test on a CoolVDS 1GB RAM instance. The target was a 5KB static image file, simulated with 1,000 concurrent connections.
| Metric | Apache 2.2 (Prefork) | Lighttpd 1.4 |
|---|---|---|
| Requests per second | 1,240 req/s | 4,850 req/s |
| Memory Usage | 380 MB | 15 MB |
| Load Average | 4.5 | 0.4 |
The difference is staggering. Lighttpd serves static content four times faster while using a fraction of the memory. This frees up your system resources for what actually matters: your database (MySQL/InnoDB) and your application logic.
Data Privacy and Latency in Norway
Performance isn't just about software; it's about physics and law. Hosting your server in the US creates latency for Norwegian users. Furthermore, with the ongoing discussions regarding the Data Retention Directive (Datalagringsdirektivet) and compliance with the Personal Data Act, keeping data within Norwegian borders is becoming a priority for CTOs.
CoolVDS infrastructure is located in Oslo, directly peered at NIX. When you combine Lighttpd's low overhead with our low-latency network, the "Time to First Byte" (TTFB) drops significantly. This is vital for user experience and keeps your bounce rates low.
Which One Should You Choose?
Stick with Apache if:
- You rely heavily on
.htaccessand cannot access the main server config. - You use obscure modules not supported by Lighttpd.
- You have plenty of RAM and low concurrency requirements.
Migrate to Lighttpd (or Nginx) if:
- You are running a VPS with 512MB or 1GB RAM.
- You serve a high volume of static assets (images, CSS, JS).
- You are experiencing the "Slashdot effect" or sudden traffic spikes.
- You want to maximize the ROI of your hosting budget.
Final Thoughts
In 2012, raw compute power is accessible, but it isn't infinite. Throwing hardware at a software inefficiency is expensive. By switching to an event-driven web server like Lighttpd, you can serve thousands of more users on the exact same hardware footprint.
Whether you choose the flexibility of Apache or the raw speed of Lighttpd, the foundation matters. Don't let slow I/O kill your SEO or database performance.
Ready to test your configuration? Deploy a high-performance developer instance on CoolVDS in under 60 seconds and see the difference decent I/O makes.