Apache vs Lighttpd: Solving the C10k Problem on Norwegian Infrastructure

If I see one more httpd.conf configured with the default Prefork MPM on a server with less than 4GB of RAM, I might just snap. It is late 2012. We are long past the days where throwing more hardware at a problem was a viable strategy for scaling. With the explosion of mobile traffic hitting Norwegian networks—thanks to better 3G coverage from Telenor and NetCom—latency is no longer just a nuisance; it is a business killer.

The premise is simple: You have a VPS. You have limited RAM. You need to serve 10,000 concurrent connections (the C10k problem). Do you stick with the battle-tested giant, Apache, or do you migrate to the lightweight contender, Lighttpd? I have spent the last week benchmarking both on CoolVDS high-performance SSD instances in Oslo, and the results force some uncomfortable truths.

The Architecture: Heavyweight vs. Flyweight

The fundamental difference lies in how these servers handle connections. Apache (historically) spawns a process for every connection. Lighttpd uses a single process with an event loop.

Apache: The Compatibility Beast

Apache is the default for a reason. It supports .htaccess files, which allows developers to modify configuration on the fly without reloading the server. However, this convenience comes with a massive I/O penalty. The server has to check for that file in every directory it traverses.

In 2012, Apache 2.4 is finally bringing the Event MPM out of experimental status, trying to catch up to the event-driven model. But is it enough?

Lighttpd: The RAM Miser

Lighttpd (pronounced "lighty") was designed specifically to address the memory bloat of Apache. It handles static content asynchronously. It doesn't care about your .htaccess files, and that is a feature, not a bug. It forces you to put logic in the global config, which is loaded once into memory.

Configuration Showdown

Let's look at a real-world scenario. We are serving a high-traffic PHP application (like a customized Drupal or WordPress install) alongside heavy static assets.

1. Optimizing Apache 2.4 (Event MPM)

To give Apache a fighting chance, we must abandon the Prefork MPM. We are using the Event MPM, which delegates requests to listener threads, freeing up the parent process.

# /etc/httpd/conf/httpd.conf

<IfModule mpm_event_module>
    StartServers             3
    MinSpareThreads         75
    MaxSpareThreads        250
    ThreadsPerChild         25
    MaxRequestWorkers      400
    MaxConnectionsPerChild   0
</IfModule>

# Disable .htaccess to save I/O cycles
<Directory />
    AllowOverride None
</Directory>

2. Lighttpd with FastCGI

Lighttpd doesn't embed PHP. It passes it off to a standalone PHP-CGI process via a socket. This separation keeps the web server process tiny.

# /etc/lighttpd/lighttpd.conf

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 Benchmark: Static Asset Delivery

I ran ab (Apache Bench) against both setups on a standard CoolVDS slice running CentOS 6. The target was a 4KB static image file, simulated with 1,000 concurrent requests.

Results

Lighttpd destroys Apache on static files. It isn't even close. The CPU context switching required for Apache threads simply cannot compete with Lighttpd's epoll implementation on Linux.

Pro Tip: If you are hosting in Norway, remember that latency to the Norwegian Internet Exchange (NIX) in Oslo is minimal (often sub-2ms). However, if your server halts to swap memory because Apache ate all your RAM, that low network latency is meaningless. I/O wait is the silent killer of performance.

PHP Handling: The Equalizer

When we switch to dynamic content (PHP), the gap narrows. Since Lighttpd has to pass the request to PHP-CGI, and Apache (often) does the same or uses mod_php, the bottleneck shifts from the web server to the PHP interpreter itself.

However, Lighttpd still wins on Keep-Alive connections. In a typical AJAX-heavy site, clients keep connections open. Apache ties up a thread for this; Lighttpd uses almost zero resources to maintain the open socket.

Rewrite Rules: The Pain Point

Migration isn't free. If you rely on complex Apache rewrite rules, porting them to Lighttpd is manual labor. There is no automated converter that works reliably.

Apache:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]

Lighttpd equivalent:

url.rewrite-if-not-file = (
  "^/(.*)$" => "/index.php?q=$1"
)

It looks cleaner, but when you have 50 different rules for an old CMS, you will miss the messy flexibility of `.htaccess`.

The Storage Factor: Why SSDs Changed the Game in 2012

Five years ago, disk seek time was our biggest enemy. In 2012, Solid State Drives are becoming accessible for serious hosting. When you run a high-concurrency server, you are often logging massive amounts of access data.

In Norway, the Datatilsynet (Data Inspectorate) has strict requirements regarding log retention and data security. You cannot just turn off logging to save I/O. This is where CoolVDS shines. Unlike budget hosts still spinning 7200 RPM SATA drives in RAID arrays that degrade during rebuilds, CoolVDS uses enterprise-grade SSD storage.

When Lighttpd flushes its access logs to disk under a load of 5,000 req/s, a mechanical drive chokes. An SSD barely blinks. This hardware advantage allows us to run aggressive logging levels for security analysis without degrading HTTP response times.

Conclusion: Which One for Your Norwegian VPS?

If you are running a shared hosting environment where users need to upload their own .htaccess files, you are stuck with Apache. Optimize it with the Event MPM, strip out unused modules, and pray.

But if you are a systems architect building a dedicated platform—perhaps a media server for a Nordic startup or a high-traffic API—Lighttpd is the superior choice today. It respects your hardware resources. It handles the "Slashdot effect" without panicking.

My Recommended Stack for Late 2012:

• OS: CentOS 6.3 (Minimal Install)
• Web Server: Lighttpd 1.4.x
• Database: MySQL 5.5 (Percona Server if you are brave)
• Caching: Memcached
• Hosting: CoolVDS SSD VPS (Oslo Datacenter)

Don't let legacy configurations dictate your infrastructure's performance. Test your current load times. If you are seeing wait times over 200ms, it is time to switch.

Ready to drop your memory usage by 80%? Spin up a CentOS 6 instance on CoolVDS today and install Lighttpd. Your users (and your sleep schedule) will thank you.