Apache vs Lighttpd: The Battle for Throughput on Linux VPS

It is 3:00 AM on a Tuesday. Your monitoring system is screaming. Your swap usage is hitting 90%. The load average on your quad-core box just crossed 15.00. Why? Because a marketing campaign just went live, and your web server is spawning processes like a runaway freight train. If you are still running a default yum install httpd configuration in 2012, you are not managing a server; you are managing a ticking time bomb.

For years, the LAMP stack (Linux, Apache, MySQL, PHP) has been the gold standard. But as traffic scales and the C10k problem (handling 10,000 concurrent connections) becomes a reality for more than just the giants, the inefficiencies of Apache's process-based model are becoming impossible to ignore. Enter Lighttpd (pronounced "lighty"), the lightweight, event-driven challenger designed to sip RAM while Apache guzzles it.

In this analysis, we are going to tear down the architecture of both, look at real-world configuration tuning, and decide which one deserves to run on your CoolVDS instance.

The Old Guard: Apache HTTP Server

Apache is the tank of the internet. It is battle-tested, modular, and compatible with almost everything. However, its greatest strength is its greatest weakness: the process model. By default, Apache on CentOS or Debian likely uses the Prefork MPM (Multi-Processing Module). This means every single incoming connection spawns a dedicated process (or uses an idle one).

If you are embedding PHP directly via mod_php, every one of those Apache processes grows to the size of your PHP footprint. If a process takes 25MB of RAM and you get 500 concurrent hits, you need 12.5GB of RAM just for the web server. On a standard VPS, you are dead in the water.

The Hidden Cost of Flexibility: .htaccess

Apache checks for an .htaccess file in every directory it traverses. This generates significant file system I/O overhead. You can mitigate this by disabling overrides, but most developers rely on it.

If you are committed to Apache, you must tune the KeepAlive and MaxClients settings to match your available memory, not your aspirations.

# /etc/httpd/conf/httpd.conf

# Stop Apache from eating all your RAM

StartServers       8
MinSpareServers    5
MaxSpareServers   20
ServerLimit      256
MaxClients       256
MaxRequestsPerChild  4000


# reduce overhead
HostNameLookups Off
AllowOverride None

The Challenger: Lighttpd

Lighttpd was born to address the memory bloat of Apache. Unlike the blocking, process-per-connection model of Apache Prefork, Lighttpd uses an asynchronous, event-driven architecture. It runs as a single process and uses the kernel's epoll (on Linux) or kqueue (on BSD) system calls to handle thousands of connections without context-switching overhead.

This architecture allows Lighttpd to serve static content (images, CSS, JS) at blinding speeds with negligible load. For dynamic content (PHP), it uses FastCGI, decoupling the web server from the PHP interpreter.

Configuration Simplicity

Lighttpd's configuration is cleaner and supports conditionals without the I/O penalty of per-directory config files.

# /etc/lighttpd/lighttpd.conf

server.modules = (
  "mod_access",
  "mod_alias",
  "mod_compress",
  "mod_fastcgi",
  "mod_rewrite"
)

server.document-root = "/var/www/lighttpd/"
server.event-handler = "linux-sysepoll"
server.network-backend = "linux-sendfile"

# PHP FastCGI Configuration
fastcgi.server = ( ".php" =>
  (( 
    "bin-path" => "/usr/bin/php-cgi",
    "socket" => "/tmp/php.socket",
    "max-procs" => 2,
    "idle-timeout" => 20,
    "bin-environment" => (
      "PHP_FCGI_CHILDREN" => "4",
      "PHP_FCGI_MAX_REQUESTS" => "10000"
    ),
    "bin-copy-environment" => (
      "PATH", "SHELL", "USER"
    ),
    "broken-scriptfilename" => "enable"
  ))
)

War Story: The "Melting" Magento Store

Last month, I audited a Magento deployment for a client in Oslo. They were running Apache 2.2 on a 4GB VPS. Every time they sent a newsletter, the server crashed. top showed Apache consuming 3.8GB of RAM, pushing the system into swap hell.

We did two things:

1. Switched static asset delivery to Lighttpd on a separate subdomain.
2. Moved the main application to use PHP-FPM (FastCGI Process Manager) instead of mod_php.

The result? Memory usage dropped to 800MB. Load average went from 12.0 to 0.4. The site stayed up.

Pro Tip: If you are serving high-traffic static files, avoid the file system entirely for small files by using a memory cache like Varnish in front, or ensure your OS file cache is hot. But nothing replaces raw disk speed when cache misses occur.

Local Context: Latency and The Law

For those of us hosting in the Nordics, speed isn't just about software. It's about physics. Hosting your application in a US datacenter adds ~100ms of latency to your Norwegian users. By hosting in Oslo, you are hitting the NIX (Norwegian Internet Exchange) directly, dropping latency to under 10ms.

Furthermore, we must adhere to the Personal Data Act (Personopplysningsloven). Keeping customer data within Norwegian borders simplifies compliance with the Data Inspectorate (Datatilsynet). Using a local provider like CoolVDS ensures you aren't accidentally routing sensitive customer data through a jurisdiction with weaker privacy laws.

The Hardware Reality Check

You can optimize your software configuration until you are blue in the face, but you cannot code your way out of slow I/O. Both Apache (with its .htaccess checks) and Lighttpd (logging and static file reads) rely heavily on disk performance.

In 2012, standard spinning rust (7.2k RPM SATA drives) is the primary bottleneck for web servers. High IO wait (%wa in top) kills response times. This is why at CoolVDS, we have standardized on enterprise-grade SSD storage and KVM virtualization. We don't oversell our cores, and we certainly don't let your neighbor's I/O starve your database.

Benchmarking on CoolVDS

We ran a simple ab (Apache Bench) test on a CoolVDS instance serving a 10KB static file using Lighttpd:

user@coolvds:~$ ab -n 10000 -c 100 http://localhost/test.html

Concurrency Level:      100
Time taken for tests:   0.842 seconds
Complete requests:      10000
Failed requests:        0
Requests per second:    11876.45 [#/sec] (mean)
Time per request:       8.420 [ms] (mean)

Try getting 11,000 requests per second on a shared hosting plan with mechanical drives.

Conclusion: Which One to Choose?

Choose Apache if:

• You need drop-in compatibility with legacy CMS plugins.
• You rely heavily on complex .htaccess rewrite rules that you don't want to translate.
• RAM is cheap and abundant for your project.

Choose Lighttpd if:

• You are serving high-volume static content (images, downloads).
• You are on a VPS with limited RAM (512MB or 1GB).
• You are comfortable configuring FastCGI for PHP.
• Performance is your primary metric.

Ultimately, a high-performance web server needs a high-performance foundation. Don't let IO latency kill your SEO efforts.

Deploy a pure SSD KVM instance on CoolVDS today and stop waiting on your hard drive.