Console Login
Home / Blog / Server Administration / Apache vs Lighttpd: The Battle for Throughput in High-Load Environments
Server Administration 0 views

Apache vs Lighttpd: The Battle for Throughput in High-Load Environments

@

Apache vs Lighttpd: The Battle for Throughput in High-Load Environments

It starts with a simple marketing campaign. You send out an email blast, or perhaps you get lucky and hit the front page of Digg. Suddenly, your load average spikes from 0.5 to 35.0. Your SSH session lags. The kernel starts killing processes to save memory. If you are running a standard LAMP stack out of the box, the culprit is almost always the same: Apache is eating your RAM alive.

As a systems architect working with high-availability clusters across Oslo and Kyiv, I see this scenario weekly. The debate isn't about which software is "better" generally; it's about the right tool for the job. Today, we are dissecting the industry standard, Apache 2.2, against the lightweight challenger, Lighttpd (Lighty), to see which one deserves the port 80 slot on your server.

The Heavyweight: Apache 2.2

Apache has been the backbone of the internet since the mid-90s. It is robust, modular, and compatible with everything. However, its default architecture (MPM Prefork) is a relic when it comes to high-concurrency static content.

Apache handles requests by spawning a new process (or thread, depending on MPM) for every connection. If you have 500 concurrent users, you need 500 workers. If each PHP process consumes 20MB of RAM, you are suddenly needing 10GB of memory just to keep the lights on. On a standard VPS, you will hit swap immediately.

Optimization Strategy

If you must stick with Apache (perhaps you rely heavily on .htaccess files, which Lighttpd does not support), you must stop it from over-committing memory. In your httpd.conf, you need to calculate your MaxClients based on your actual available RAM, not the default settings.

StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 150 MaxRequestsPerChild 1000
Pro Tip: Turn off KeepAlive or lower the KeepAliveTimeout to 2 seconds. You don't want idle browsers occupying a precious Apache process while your server is under siege.

The Challenger: Lighttpd

Lighttpd was designed to solve the C10k problem (handling 10,000 concurrent connections). Unlike Apache, it is event-driven. It uses a single process with an event loop (using epoll on Linux 2.6 kernels) to handle thousands of connections without blocking.

We recently migrated a high-traffic media portal in Trondheim from Apache to Lighttpd. The results were immediate: RAM usage dropped by 90% and CPU load stabilized. Lighttpd excels at serving static content (images, CSS, JS) and proxies dynamic requests to PHP via FastCGI.

The Configuration Difference

Lighttpd configuration is more logical, resembling a programming language. Here is how we tune the event handler for maximum throughput:

server.max-fds = 2048 server.event-handler = "linux-sysepoll" server.network-backend = "linux-sendfile" # FastCGI for PHP fastcgi.server = ( ".php" => (( "socket" => "/tmp/php-fastcgi.socket", "bin-path" => "/usr/bin/php-cgi", "max-procs" => 4, "idle-timeout" => 20 )) )

Infrastructure Matters: The CoolVDS Standard

Software optimization can only go so far. If your underlying storage subsystem is slow, your web server will block while waiting for disk I/O. This is critical for database-driven applications.

At CoolVDS, we don't oversell our host nodes. We utilize enterprise-grade 15k RPM SAS RAID arrays and high-speed memory. While many budget providers crowd OpenVZ containers until performance degrades, we utilize Xen virtualization to ensure strict resource isolation. When you buy 512MB of RAM, you get 512MB of RAM, not a burstable promise that vanishes when the neighbor starts compiling a kernel.

Data Integrity and Norwegian Law

For our clients operating in Norway, compliance with the Personal Data Act (Personopplysningsloven) is mandatory. Hosting your data within Norwegian borders ensures you are under the jurisdiction of Datatilsynet, providing legal stability that offshore hosting cannot match.

Conclusion: Which One?

Feature Apache 2.2 Lighttpd 1.4
Architecture Process/Thread based Event-driven (Asynchronous)
Memory Usage High (scales with clients) Low (constant footprint)
.htaccess Support Yes (Native) No (Requires main config access)
Best Use Case Shared hosting, Complex modules High-traffic static files, API endpoints

If you rely on mod_rewrite complexity or .htaccess files in a shared environment, Apache remains the king of flexibility. However, if your goal is raw speed, low latency, and surviving a traffic spike without upgrading hardware, Lighttpd is the superior technical choice for 2009.

Stop letting I/O wait times kill your conversion rates. Deploy a Xen-based instance on CoolVDS today and experience the difference of managed hosting done right.

/// TAGS

/// RELATED POSTS

Surviving the Spike: High-Performance E-commerce Hosting Architecture for 2012

Is your Magento store ready for the holiday rush? We break down the Nginx, Varnish, and SSD tuning s...

Read More →

Automate or Die: Bulletproof Remote Backups with Rsync on CentOS 6

RAID is not a backup. Don't let a typo destroy your database. Learn how to set up automated, increme...

Read More →

Xen vs. KVM: Why Kernel Integration Wars Define Your VPS Performance

Red Hat Enterprise Linux 6 has shifted the battlefield from Xen to KVM. We analyze the kernel-level ...

Read More →

Escaping the Shared Hosting Trap: A SysAdmin’s Guide to VDS Migration

Is your application choking on 'unlimited' shared hosting? We break down the technical migration to ...

Read More →

IPTables Survival Guide: Locking Down Your Linux VPS in a Hostile Network

Stop script kiddies and botnets cold. We dive deep into stateful packet inspection, fail2ban configu...

Read More →

Sleep Soundly: The Paranoid SysAdmin's Guide to Bulletproof Server Backups

RAID is not a backup. If you accidentally drop a database table at 3 AM, mirroring just replicates t...

Read More →
← Back to All Posts