Apache vs. Lighttpd: Stop Wasting RAM on Idle Connections
Let’s be honest. If you are running a standard LAMP stack on a default CentOS 5 install, you are probably wasting 40% of your RAM. I saw this just last week with a client running a busy vBulletin forum targeting the Scandinavian market.
Their server wasn't crashing because of CPU load. It was crashing because Apache was spawning hundreds of child processes just to serve favicon.ico and spacer GIFs to users on slow DSL connections. This is the classic C10k problem.
In the world of high-performance hosting, the debate between Apache and Lighttpd (pronounced "lighty") isn't just about preference. It's about architecture. Today, we strip down the marketing fluff and look at how these two handle connections, and why your choice of daemon matters as much as your choice of hardware.
The Incumbent: Apache 2.2
Apache is the bedrock of the internet. It powers over 50% of active websites. Its strength lies in its modularity and the ubiquity of .htaccess files. If you are a hosting provider giving users control over their own rewrite rules without restarting the server, Apache is mandatory.
The Problem: MPM Prefork
Most PHP setups use the Prefork MPM (Multi-Processing Module) because PHP libraries aren't always thread-safe. This means Apache spawns a separate process for every single connection.
# Typical httpd.conf bottleneck
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0
</IfModule>
If your MaxClients is set to 150, and you hit 151 concurrent users, user #151 waits. If you raise MaxClients to 500, you might swap out your memory and crash the box. Apache is heavy. On a standard configuration, an Apache process might consume 15-25MB of RAM just to say "Hello World" via PHP.
The Challenger: Lighttpd 1.4
Lighttpd was designed specifically to address the memory bloat of Apache. Unlike Apache's process-per-connection model, Lighttpd uses an asynchronous, event-driven architecture.
It leverages the epoll() system call available in the Linux 2.6 kernel. This allows it to handle thousands of concurrent connections in a single process loop. It doesn't block. It doesn't spawn a heavy process just because a user is downloading a large image over a 3G mobile connection.
Configuration Simplicity
Lighttpd's configuration is also far more readable than Apache's XML-style tag soup.
# lighttpd.conf example
server.document-root = "/var/www/htdocs/"
server.port = 80
mimetype.assign = (
".html" => "text/html",
".txt" => "text/plain",
".jpg" => "image/jpeg",
".png" => "image/png"
)
War Story: The Hybrid Approach
You don't always have to choose. In a recent deployment for a media portal in Oslo, we utilized a hybrid setup to maximize the hardware on their CoolVDS instance.
We kept Apache on the backend (port 8080) to handle the complex PHP logic and .htaccess rules that the developers relied on. We placed Lighttpd on the frontend (port 80) acting as a reverse proxy and static file server.
Pro Tip: By letting Lighttpd handle images, CSS, and JS, we reduced the Apache process count by 70%. Apache only woke up for dynamic PHP requests. The server load dropped from 8.0 to 0.4 overnight.
Hardware Still Matters
Software optimization can only take you so far. If your underlying storage I/O is slow, your web server will block while waiting for the disk to read data. This is where "Wait I/O" kills performance charts.
Many VPS providers in Europe oversell their storage, putting hundreds of customers on a single SATA array. At CoolVDS, we use Xen virtualization. Unlike OpenVZ, Xen provides strict resource isolation. We also utilize high-performance RAID-10 SAS arrays and are beginning to roll out enterprise SSD caching for database-heavy workloads.
The Norwegian Context
Latency is the silent killer of user experience. If your target audience is in Norway, hosting in Germany or the US adds unnecessary milliseconds (RTT) to every TCP handshake. By the time the handshake completes, the user has already clicked away.
Furthermore, under the Norwegian Personal Data Act (Personopplysningsloven), keeping data within national borders simplifies compliance significantly compared to navigating the complex Safe Harbor agreements required for US hosting.
Verdict: Which One?
- Choose Apache if: You need
.htaccesssupport, you run a legacy CMS that depends on specific Apache modules, or you have plenty of RAM and low concurrency. - Choose Lighttpd if: You are serving high-volume static content, you need to support thousands of concurrent connections, or you are running on a VPS with limited RAM (e.g., 256MB or 512MB slices).
Don't let legacy configurations dictate your performance. Whether you choose the stability of Apache or the speed of Lighttpd, you need a foundation that doesn't steal your CPU cycles. Deploy a Xen-based instance on CoolVDS today and see what your web server can actually do.