The RAM Eater vs. The Featherweight: Choosing Your Web Server Architecture

I watched a server melt yesterday. It wasn't a hardware failure—our RAID arrays at the data center in Oslo were green across the board. It was a classic case of resource starvation caused by architectural legacy. The client, running a popular Norwegian classifieds portal, saw a traffic spike during prime time. Their weapon of choice? A stock Apache 2.2 installation running mod_php on CentOS 5.

The result was predictable. As concurrent connections climbed past 400, the Apache child processes—fat with PHP libraries—devoured the available RAM. The machine started swapping to disk. Load averages skyrocketed from 0.5 to 50.0 in minutes. Site latency went from 40ms to 12 seconds.

If you are serious about hosting in 2010, you cannot simply `yum install httpd` and hope for the best. Today, we are tearing down the differences between the reigning champion, Apache HTTP Server, and the lightweight challenger, Lighttpd (Lighty), to see which one belongs on your Virtual Dedicated Server (VDS).

The Apache 2.2 Philosophy: Compatibility is King

Apache has been the backbone of the internet since the mid-90s. Its power lies in its modularity and the ubiquity of .htaccess files. If you are running a shared hosting environment or complex legacy CMS applications that rely on dynamic overrides, Apache is often the only choice. However, its architecture is process-based (specifically the Prefork MPM often used with PHP).

Every incoming connection spawns a thread or process. If that process includes the PHP interpreter, it's heavy. Here is what a typical bottleneck configuration looks like in /etc/httpd/conf/httpd.conf:

<IfModule prefork.c>
StartServers       8
MinSpareServers    5
MaxSpareServers   20
ServerLimit      256
MaxClients       256
MaxRequestsPerChild  4000
</IfModule>

The danger here is MaxClients. If your average Apache process consumes 25MB of RAM (common with Drupal or Magento), and you allow 256 clients, you need 6.4GB of dedicated RAM just for the web server. If you are on a standard 2GB or 4GB VPS, you will hit swap, and your I/O wait will kill the server performance.

Pro Tip: Never set MaxClients to a value higher than (Total RAM - OS Overhead - DB Memory) / Avg Process Size. It is better to reject connections than to swap.

The Lighttpd 1.4 Philosophy: Asynchronous Speed

Lighttpd takes a different approach. It uses an asynchronous, event-based architecture. Instead of blocking a process for every user, it handles thousands of connections in a single process loop using epoll() on Linux. It is designed specifically to solve the "C10k problem" (handling 10,000 concurrent connections).

Lighttpd does not embed PHP. It passes dynamic requests to a separate FastCGI process (like php-cgi spawned via spawn-fcgi). This means the web server stays lean, only consuming memory for active data transfer, while PHP processes are reused efficiently.

Configuring Lighttpd for High Performance

Migrating from Apache to Lighttpd requires a mindset shift. You lose .htaccess, so rewrite rules must go in the main config. Here is a robust setup for a high-traffic site:

# /etc/lighttpd/lighttpd.conf
server.modules = (
  "mod_access",
  "mod_alias",
  "mod_compress",
  "mod_redirect",
  "mod_rewrite",
  "mod_fastcgi"
)

server.max-fds = 2048
server.event-handler = "linux-sysepoll"
server.network-backend = "linux-sendfile"

# FastCGI Configuration for PHP
fastcgi.server = ( ".php" =>
  (( 
    "host" => "127.0.0.1",
    "port" => 9000,
    "broken-scriptfilename" => "enable"
  ))
)

Benchmark: Static File Serving

We ran a benchmark using ab (Apache Bench) against a CoolVDS instance running CentOS 5.5, equipped with high-performance RAID 10 storage. We requested a 5KB static image with 1,000 concurrent requests.

The difference is staggering. For static content—images, CSS, JavaScript—Lighttpd is vastly superior. It serves more users with a fraction of the hardware resources.

The Hidden Variable: Disk I/O and Latency

While software architecture is critical, your underlying infrastructure defines your ceiling. Even Lighttpd will stall if it's waiting on a slow hard drive to read a log file or a database query.

This is where the "noisy neighbor" effect of shared hosting destroys performance. If another user on the node is compiling a kernel, your disk I/O wait goes up. At CoolVDS, we utilize KVM virtualization rather than OpenVZ. KVM provides stricter isolation of resources. Furthermore, our storage arrays utilize high-speed SAS 15k RPM drives in RAID 10, providing the I/O throughput necessary for database-heavy applications.

Latency Matters for Norway

For Norwegian businesses, physical location is also a compliance and performance factor. Hosting your data outside the EEA can introduce legal headaches regarding the Personopplysningsloven (Personal Data Act). More importantly, the latency from Oslo to a server in Frankfurt is roughly 25-35ms. The latency to a CoolVDS server in our Oslo facility is 2-5ms.

When you are performing hundreds of small SQL queries or HTTP requests, that 30ms difference compounds. A page loading 50 assets could see a 1.5-second delay strictly due to the speed of light.

Hybrid Approach: The Best of Both Worlds?

You don't always have to choose. A popular architectural pattern emerging in 2010 is using Lighttpd as a reverse proxy/load balancer in front of Apache. Lighttpd handles the slow clients and static files (images, css), and only proxies the heavy PHP requests to Apache on a loopback interface.

# Lighttpd Proxy Config
$HTTP["url"] =~ "\.(php|pl|py)$" {
  proxy.server = ( "" => (
    ( "host" => "127.0.0.1", "port" => 8080 )
  ) )
}

This setup prevents the "Slowloris" attack and keeps Apache threads free for processing actual code, not waiting for a user on a slow 3G connection to download a logo.

Conclusion

If you require absolute compatibility with existing .htaccess files or specialized Apache modules, stick with Apache, but tune your MaxClients aggressively and ensure you have ample RAM. However, if your goal is raw performance, scalability, and handling high concurrency on a budget, Lighttpd is the clear winner.

Regardless of your web server choice, low latency and disk throughput are non-negotiable. Don't let your code wait on a spinning platter. Deploy your optimized stack on a CoolVDS instance today and experience the stability of local Norwegian hosting.