The C10K Problem and Your Server's Survival
If you are running a standard LAMP stack in 2011, you are likely relying on Apache. It is the bedrock of the internet, powering over 60% of active websites. But as traffic spikes—especially with the rise of AJAX-heavy applications—Apache's process-based architecture is hitting a wall. We call this the C10K problem: the inability of a server to efficiently handle ten thousand concurrent connections.
At CoolVDS, we see this constantly. A client upgrades their VPS plan because their memory usage is at 98%, assuming they need more RAM. Often, they don't. They just need to switch from a process-based web server to an event-based one. Today, we are pitting the industry standard, Apache 2.2, against the lightweight contender, Lighttpd (Lighty), to see which daemon deserves the port 80 slot on your Norwegian infrastructure.
Architecture: Prefork vs. Event-Driven
The fundamental difference lies in how they handle connections. Apache, typically configured with the MPM Prefork module for PHP compatibility, spawns a separate process for every single connection. Each process carries the overhead of the entire application stack.
# Typical Apache Process List
root 3456 0.0 0.4 23452 8900 ? Ss 10:00 0:00 /usr/sbin/httpd
apache 3457 0.1 0.9 25600 12000 ? S 10:00 0:02 /usr/sbin/httpd
apache 3458 0.1 0.9 25600 12000 ? S 10:00 0:02 /usr/sbin/httpd
... and so on for every user.Lighttpd takes a different approach. It uses a single process with an event loop (using epoll on Linux). It handles thousands of connections asynchronously without spawning new processes for each request. This means the memory footprint remains stable, even under load.
SysAdmin Note: If you are serving primarily static content (images, CSS, JS), Lighttpd can serve the same traffic as Apache using a fraction of the RAM. On a CoolVDS 512MB VPS slice, this efficiency is the difference between a responsive site and swapping to disk.
The PHP Factor: mod_php vs. FastCGI
This is where the debate gets heated. Apache's mod_php is incredibly convenient. It embeds the PHP interpreter inside the Apache process. It is stable, but it makes every Apache child process heavy.
Lighttpd does not support mod_php. Instead, it utilizes FastCGI. In 2011, this setup is slightly more complex to configure but offers superior separation of concerns. You run a separate pool of PHP processes (using spawn-fcgi or php-fpm, which is gaining traction). Lighttpd proxies dynamic requests to this pool.
If your PHP script crashes in Apache, it might take the child process down. In Lighttpd with FastCGI, the web server stays up while the FastCGI process restarts. This decoupling is vital for stability.
Configuration and .htaccess
Apache's killer feature has always been .htaccess. It allows developers to modify server configuration on a per-directory basis without restarting the daemon. It is essential for shared hosting environments. However, looking for these files in every directory tree kills I/O performance.
Lighttpd does not support .htaccess files. All logic must go into the central lighttpd.conf. While this annoys developers who rely on drop-in WordPress plugins, from a systems architect perspective, it is a blessing. It forces centralized configuration and eliminates the I/O penalty of recursive file lookups.
Example: URL Rewriting
Apache (.htaccess):
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php [QSA,L]Lighttpd (lighttpd.conf):
url.rewrite-if-not-file = (
"^/(.*)$" => "/index.php/$1"
)The syntax differs, but the result is a faster, leaner server.
The Hardware Context: SSDs and Latency
Hardware matters. Most providers in 2011 are still spinning 15k RPM SAS drives. While fast, they cannot match the random read speeds of the emerging Solid State Drives (SSDs). Lighttpd's asynchronous I/O shines even brighter when backed by the low latency of SSD storage.
At CoolVDS, we have begun deploying SSD-cached nodes in our Oslo datacenter. When you combine Lighttpd's efficient file descriptor handling with our SSD storage and the low latency of the Norwegian Internet Exchange (NIX), the Time To First Byte (TTFB) drops drastically. This is crucial not just for user experience, but for ensuring your server complies with the responsiveness expected under the Service Level Agreements common in Norwegian enterprise.
Verdict: Which Should You Choose?
There is no silver bullet, but here is the breakdown for the pragmatic administrator:
- Stick with Apache 2.2 if: You rely heavily on
.htaccessfiles, you are running legacy code that requires specific Apache modules, or you have plenty of RAM to spare and prioritize ease of setup over raw concurrency. - Switch to Lighttpd if: You are running a high-traffic static asset server, you have a memory-constrained VPS (256MB or 512MB), or you are comfortable configuring FastCGI for PHP.
Ultimately, software optimization can only take you so far. If your underlying infrastructure is oversubscribed, no amount of tuning lighttpd.conf will save you. You need a foundation built on true hardware isolation.
Ready to test the difference? Spin up a CoolVDS instance with Enterprise SSDs today and benchmark your stack. We provide the raw power; you provide the code.