Apache vs Lighttpd: Stop Your Server From Choking on Traffic

It is 3:00 AM. Your monitoring system is screaming. Your load average just hit 20.0 on a quad-core box. You SSH in, run top, and see the horror: a wall of httpd processes, each consuming 40MB of RAM, fighting over the scraps of memory left on your server. The swap is thrashing so hard your disk I/O is effectively zero.

If you are running a high-traffic site in Norway on a standard LAMP stack, this nightmare is likely your reality. The debate between Apache HTTP Server and Lighttpd (Lighty) isn't just about preference anymore; it is about survival. It is about the C10k problem (handling 10,000 concurrent connections).

At CoolVDS, we see this daily. Clients migrate from shared hosting or inferior VPS providers where resources are oversold, hoping a dedicated slice will fix their woes. But hardware is only half the battle. If your software architecture is flawed, even our enterprise-grade SSDs won't save you.

The Heavyweight: Apache 2.2

Apache has been the internet's backbone since the 90s. It is robust, documented everywhere, and compatible with everything. The killer feature? .htaccess. The ability for developers to override configuration on a per-directory basis without restarting the server is huge for shared environments.

However, Apache's default processing model, MPM Prefork, is a memory hog. It spawns a separate process for every single connection. If you have 500 concurrent users, you need 500 processes. If each PHP process takes 30MB, you need 15GB of RAM just for the web server.

Typical Apache Bottleneck Configuration

Check your /etc/httpd/conf/httpd.conf (CentOS) or /etc/apache2/apache2.conf (Debian):

<IfModule mpm_prefork_module>
    StartServers          5
    MinSpareServers       5
    MaxSpareServers      10
    MaxClients          150
    MaxRequestsPerChild   0
</IfModule>

The MaxClients directive is the hard ceiling. Once you hit 150 users, the 151st user hangs until a slot opens. Raising this number without adding RAM causes swapping, which is the death of performance.

The Challenger: Lighttpd (Lighty)

Lighttpd was born to solve exactly this problem. Unlike Apache's process-per-connection model, Lighttpd uses an asynchronous, event-driven architecture (utilizing epoll on Linux). It handles thousands of concurrent connections in a single process.

The difference in memory footprint is staggering. While Apache might eat 500MB to serve a few hundred static files, Lighttpd will barely touch 10MB for the same workload.

Lighttpd Configuration Simplicity

Lighttpd configuration is often cleaner and supports conditional logic natively without complex rewrite rules. Here is a basic setup in /etc/lighttpd/lighttpd.conf to handle high loads:

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

server.document-root        = "/var/www/html"
server.errorlog             = "/var/log/lighttpd/error.log"
index-file.names            = ( "index.php", "index.html" )

# The magic of event handling
server.event-handler = "linux-sysepoll"
server.network-backend = "linux-sendfile"
server.max-fds = 2048
server.stat-cache-engine = "simple"
server.max-connections = 1024

The War Story: Static Content Offloading

We recently assisted a media client in Oslo. They were serving heavy image galleries via Apache. The latency to the NIX (Norwegian Internet Exchange) was low, but the server processing time (TTFB) was high. Apache was busy serving `image.jpg` and blocking PHP threads that needed to process orders.

We didn't delete Apache. We put Lighttpd in front of it (or alongside it) to serve static assets.

Pro Tip: Filesystem I/O is expensive. Ensure your VPS provider isn't overselling disk operations. At CoolVDS, we use RAID-10 arrays to ensure that when Lighttpd asks for a file, the disk delivers it instantly. Slow I/O makes event-driven servers block, negating their advantage.

Benchmarking the Difference

Using ab (Apache Bench), we simulated 1000 concurrent requests.

# Testing Apache
ab -n 10000 -c 1000 http://localhost:80/test.jpg

# Testing Lighttpd
ab -n 10000 -c 1000 http://localhost:81/test.jpg

The Results:

Handling PHP: Mod_PHP vs FastCGI

This is where Apache usually wins on convenience. mod_php is built-in. It's easy. But it makes every Apache child process heavy because it embeds the PHP interpreter.

Lighttpd uses FastCGI. It talks to a separate PHP process (using php-cgi or spawn-fcgi). This decouples the web server from the application logic.

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

This setup allows you to strictly control how many PHP workers are running, regardless of how many incoming TCP connections Lighttpd is holding open.

Security and Data Integrity in Norway

For our Norwegian clients, compliance with the Personopplysningsloven (Personal Data Act) and the requirements of Datatilsynet is non-negotiable. Logs are critical evidence.

Apache's logging is synchronous. Under heavy write load, logging can block the server. Lighttpd allows for piped logging, which can offload this stress. Furthermore, hosting heavily trafficked sites on CoolVDS guarantees that your data resides on servers physically located within the EEA, satisfying current Safe Harbor and Directive 95/46/EC requirements.

Which One Should You Choose?

It is not always black and white.

• Choose Apache if: You rely heavily on .htaccess files, you are using a CMS that expects standard Apache environments (like many WordPress plugins), or you don't have a dedicated sysadmin to tune FastCGI.
• Choose Lighttpd if: You are serving high-volume static content, you need to support 10,000+ connections on limited RAM, or you are comfortable configuring FastCGI for PHP.

Ultimately, the web server is only as fast as the metal it runs on. A poorly isolated VPS with "noisy neighbors" will make even Lighttpd feel sluggish due to CPU stealing.

At CoolVDS, we utilize KVM virtualization to ensure strict resource isolation. Whether you choose the tank (Apache) or the racer (Lighttpd), our high-performance storage and low-latency network to Oslo provide the foundation you need.

Is your current host slowing you down? Spin up a CoolVDS instance with Debian 6 or CentOS 6 today and test the difference yourself.