The Memory Hog vs. The Flyweight
If you have ever stared at top while your server load spikes above 10.0, watching free memory vanish into the abyss of Apache processes, you know the panic. It is 2010, and hardware is still expensive. RAM is not infinite. Yet, the default configuration of Apache 2.2 seems determined to consume every megabyte you have.
For years, the LAMP stack (Linux, Apache, MySQL, PHP) has been the gospel of the web. But as traffic scales and the "Slashdot effect" becomes a daily reality for successful Norwegian startups, Apache's process-based architecture is showing its age. Enter Lighttpd (pronounced "lighty").
Lighttpd claims to solve the C10k problem—handling 10,000 concurrent connections—without melting your CPU. But is it production-ready? Or is it just a toy for static content? Let's dissect the architecture.
The Apache Architecture: Stability at a Cost
Apache is the tank of the internet. It is battle-tested, modular, and supports practically everything via .htaccess. However, its default Prefork MPM (Multi-Processing Module) is a resource killer. Each incoming connection spawns a dedicated process. If you have a 50MB PHP process and 100 concurrent visitors, do the math. You need 5GB of RAM just to keep the lights on.
Here is the typical culprit in httpd.conf that kills performance on a standard VPS:
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0
</IfModule>That MaxClients 150 setting is a lie if you don't have the RAM to back it up. When Apache hits that limit, your site hangs. If you raise it without adding physical memory, your server starts swapping to disk. Once swap thrashing begins on standard 7.2k RPM drives, your downtime begins.
The Lighttpd Difference: Asynchronous Events
Lighttpd takes a radically different approach. It uses a single process with an event-based architecture (leveraging epoll on Linux kernels). Instead of blocking a whole process for a slow client, it handles connections asynchronously. It essentially juggles thousands of connections with a tiny memory footprint.
We recently migrated a high-traffic Joomla news portal in Oslo from Apache to Lighttpd. The results were startling. Memory usage dropped from 3.8GB to 450MB. Load times for static assets (images, CSS) decreased by 40%.
The magic lies in how it handles PHP. Unlike Apache's mod_php, which embeds the PHP interpreter into every web server process, Lighttpd uses FastCGI. The web server handles the network traffic, and a separate pool of PHP processes handles the logic.
Sysadmin Tip: If you switch to Lighttpd, ensure you tune your kernel's TCP stack in/etc/sysctl.conf. Increasingnet.ipv4.tcp_max_syn_backlogis essential for handling the connection density Lighttpd allows.
When to Stick with Apache
Lighttpd is fast, but it is not a drop-in replacement for everything. If your application relies heavily on complex .htaccess rewrite rules, migrating to Lighttpd's config syntax can be a nightmare. Apache's mod_rewrite is still the most flexible URL manipulation tool in existence.
Furthermore, compatibility matters. Most commercial CMS plugins are written assuming Apache is the engine. If you are running a standard corporate site with low traffic, the time spent re-configuring Lighttpd might cost more than just buying an extra stick of RAM.
Comparison: Resource Usage
| Feature | Apache 2.2 (Prefork) | Lighttpd 1.4 |
|---|---|---|
| Architecture | Process-based (Blocking) | Event-based (Asynchronous) |
| Memory per Connection | High (Embeds PHP) | Very Low (Kilobytes) |
| Static Content | Good, but resource heavy | Lightning fast |
| Configuration | .htaccess (Dynamic) | lighttpd.conf (Global) |
| PHP Implementation | mod_php (Standard) | FastCGI (Spawn-FCGI) |
The Infrastructure Factor: Why Hardware Matters
Software optimization can only go so far. If your underlying storage subsystem is slow, your database will bottle-neck long before the web server does. In Norway, where latency to the NIX (Norwegian Internet Exchange) is low, your local disk I/O often becomes the hidden killer.
This is where the "CoolVDS" approach differs from the budget providers overselling OpenVZ containers. We utilize Xen paravirtualization to ensure strict resource isolation. More importantly, we are among the first to deploy enterprise-grade Solid State Drives (SSD) and 15k RPM SAS RAID arrays for our storage backends.
Running Lighttpd on a CoolVDS instance with SSD storage eliminates the two biggest bottlenecks in 2010 web hosting: RAM exhaustion and disk latency. While others are waiting for mechanical read/write heads to seek, your database is already delivering content.
Compliance and Reliability
Operating out of Norway means adhering to strict privacy standards enforced by the Datatilsynet. Reliability is not just about uptime; it is about data integrity. Whether you choose Apache for its robustness or Lighttpd for its speed, the underlying host must respect the Personal Data Act.
CoolVDS infrastructure is housed in secure facilities in Oslo, ensuring your data stays within Norwegian legal jurisdiction—a critical factor for local businesses concerned about off-shore data handling.
The Verdict
If you are serving heavy static content, video, or running a high-traffic API, Lighttpd is the superior technical choice in 2010. It sips power and scales effortlessly.
If you need maximum compatibility for a legacy PHP application or complex rewrite rules, Apache remains the safe bet. However, consider putting a reverse proxy (like Squid or a basic Lighttpd instance) in front of it to offload images.
Whatever server you choose, don't let slow hardware undermine your configuration. Deploy a test instance on CoolVDS today and see how fast-disk I/O and dedicated Xen resources change your benchmarks.