The Memory War: Why Your Web Server Choice Matters
If you have ever stared at top and watched your swap usage climb while your server crawls to a halt, you know the pain. It is January 2012, and while hardware is getting cheaper, RAM is still the most precious resource on any Virtual Private Server (VPS). For years, the LAMP stack (Linux, Apache, MySQL, PHP) has been the default gospel for developers from Oslo to Bergen. But Apache, for all its flexibility, has a weight problem.
We are seeing a shift. High-traffic portals and lean startups are trading the comfort of .htaccess for raw throughput. Enter Lighttpd (pronounced "lighty"). It promises to handle 10,000 parallel connections without eating your server's entire memory bank. But is it ready for production in a serious business environment? Let's inspect the architecture.
Apache 2.2: The Heavyweight Champion
Apache is the IBM of web servers: nobody gets fired for choosing it. It is robust, documentation is everywhere, and modules exist for literally everything. The killer feature for shared hosting and dev teams is dynamic reconfiguration via .htaccess files. You can change rewrite rules without restarting the daemon.
However, Apache's legacy architectureâspecifically the Prefork MPM (Multi-Processing Module)âis its Achilles' heel on a VPS with limited RAM. Apache spawns a separate process for every connection. If you have a 512MB or 1GB VPS and a sudden traffic spike, those processes multiply until they consume all physical RAM, forcing the OS to swap to disk. That is when your site dies.
Optimizing Apache for a VPS
If you stick with Apache, you must restrain it. Do not use the default configs shipped with CentOS 6 or Debian Squeeze. They are often tuned for dedicated hardware.
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 3000
</IfModule>Pro Tip: Calculate yourMaxClientsbased on your average process size. If a generic Apache process takes 15MB and you have 512MB RAM (leaving 200MB for MySQL), setMaxClientsto roughly 15-20. Setting it to the default 256 is a suicide pact for your server.
Lighttpd: The Asynchronous Challenger
Lighttpd takes a different approach. It uses an asynchronous, event-driven architecture. Instead of spawning a process per user, it handles multiple requests in a single process loop using epoll (on Linux). This means the memory footprint remains flat even under heavy load.
For serving static contentâimages, CSS, JavaScriptâLighttpd is objectively faster and lighter than Apache. It relies on FastCGI to talk to PHP, which decouples the web server from the application logic. This setup (Lighttpd + PHP-FPM) is becoming the secret weapon for high-performance setups.
The Lighttpd Configuration difference
Lighttpd doesn't use .htaccess. All rules go into lighttpd.conf. This improves performance because the server doesn't have to scan directories for override files on every request, but it decreases convenience.
server.modules = (
"mod_access",
"mod_fastcgi",
"mod_compress",
"mod_rewrite"
)
server.event-handler = "linux-sysepoll"
server.max-fds = 2048
static-file.etags = "enable"Head-to-Head: Latency and The "CoolVDS" Factor
Software tuning only gets you so far. The underlying metal matters. In 2012, we are seeing a massive divergence between providers offering standard SATA HDDs and those deploying Enterprise SSDs.
On a traditional HDD, Apache's process spawning causes random I/O seek latency. When the disk heads are thrashing, your Time To First Byte (TTFB) shoots up. This is where CoolVDS has drawn a line in the sand. We utilize pure SSD storage arrays in our Norwegian datacenter.
| Feature | Apache 2.2 | Lighttpd 1.4 |
|---|---|---|
| Architecture | Process-based (Blocking) | Event-driven (Asynchronous) |
| Memory Usage | High (Scales with connections) | Low (Constant) |
| PHP Handling | mod_php (Embedded) | FastCGI (External) |
| Configuration | Flexible (.htaccess) | Centralized (lighttpd.conf) |
| Best For | Dynamic apps, Shared Hosting | High concurrency, Static assets |
Data Privacy & Norwegian Compliance
Latency is not the only reason to host locally. With the Norwegian Personal Data Act (Personopplysningsloven) and the Data Protection Directive strictly governing how we handle user data, keeping your server physically located in Norway simplifies compliance. Hosting outside the EEA (like in the US) introduces legal headaches regarding Safe Harbor frameworks that many CTOs prefer to avoid.
Furthermore, peering at NIX (Norwegian Internet Exchange) ensures that your Oslo-based customers get sub-10ms response times. Lighttpd serving static assets from an SSD-backed CoolVDS instance in Oslo is essentially instant for a local user.
The Verdict: Which Should You Choose?
If you are running a complex legacy application heavily dependent on .htaccess rewrite rules, stick with Apache 2.2, but tune your mpm_prefork settings aggressively. However, if you are deploying a modern framework or a high-traffic media site, Lighttpd is the superior tool for the job in 2012.
Don't let disk I/O be the bottleneck that renders your optimization useless. Experience the difference of low-latency local hosting.
Ready to benchmark your own stack? Deploy a CoolVDS SSD instance in our Oslo datacenter today.