Stop Letting Apache Eat Your RAM: The Nginx Reverse Proxy Guide

It is 3:00 AM. Your Nagios pager goes off. Load average is 25.0 on a dual-core box. You check top and see a wall of httpd processes, each consuming 40MB of RAM, all stuck in KEEPALIVE waiting for clients on slow 3G connections. Your swap is thrashing. Your site is dead.

If you are still serving static content and handling slow clients directly with Apache in 2010, you are doing it wrong. The traditional LAMP stack is robust, but it cannot handle the C10k problem (10,000 concurrent connections) efficiently. The process-based model of Apache scales linearly with memory usage. Nginx does not.

In this guide, we are replacing the standard architecture with a high-performance Nginx reverse proxy sitting in front of your heavy Apache backends. This is how we stabilize high-traffic portals in Oslo without buying more hardware.

The Architecture: Event-Driven vs. Process-Based

Apache creates a thread or process for every connection. If a user in Tromsø is downloading a 5MB PDF over a spotty DSL line, that Apache process—and its memory—is locked for the duration of the transfer.

Nginx is event-driven and asynchronous. It uses a small, fixed amount of memory to handle thousands of connections. It buffers the request from the slow client, hands it to Apache (running on localhost) only when ready, and accepts the response instantly, freeing up Apache to serve the next request. Nginx then trickles the data back to the client.

The Configuration

Assuming you are running CentOS 5.5 or Debian Lenny. First, move Apache to listen on port 8080. Then, configure Nginx on port 80.

Here is the battle-tested nginx.conf snippet for a reverse proxy setup:

server {
    listen 80;
    server_name example.no;

    # Serve static files directly (bypass Apache)
    location ~* \.(jpg|jpeg|gif|png|css|js|ico|xml)$ {
        root /var/www/html;
        expires 30d;
        access_log off;
    }

    # Pass dynamic content to Apache
    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        
        # Essential for slow connections
        proxy_buffering on;
        proxy_buffer_size 8k;
        proxy_buffers 8 8k;
        
        # Timeouts
        proxy_connect_timeout 60;
        proxy_send_timeout 60;
        proxy_read_timeout 60;
    }
}

Pro Tip: Install mod_rpaf on your backend Apache server. Without it, Apache will think all traffic is coming from 127.0.0.1, making your logs useless and your IP-blocking scripts ineffective.

The Hardware Reality: I/O Wait is the Silent Killer

You can optimize your software stack until you are blue in the face, but you cannot code your way out of bad disk I/O. In the VPS market, "overselling" is the standard business model. Many budget hosts jam hundreds of OpenVZ containers onto a single server with standard SATA 7.2k drives.

When one neighbor decides to run a backup or compile a kernel, your Nginx proxy stalls because it can't read from the disk buffer. Latency spikes.

This is where CoolVDS differs. We don't play the "burst RAM" game. We use Xen HVM virtualization, which provides true hardware isolation. More importantly, our storage arrays are built on 15k SAS drives in RAID-10 or Enterprise SSDs for premium nodes. When you run iostat on a CoolVDS instance, you get consistent throughput, not a lottery ticket.

Data Sovereignty and Latency in Norway

Latency matters. If your target audience is in Scandinavia, hosting in Texas or even Frankfurt adds unnecessary milliseconds. Packets have to travel through multiple hops. By hosting on infrastructure physically located near the NIX (Norwegian Internet Exchange), you reduce RTT (Round Trip Time) drastically.

Compliance: Personopplysningsloven

Legal compliance is not just for lawyers; it is a systems architecture constraint. Under the Norwegian Personopplysningsloven (Personal Data Act) and the EU Data Protection Directive (95/46/EC), you are responsible for where your user data lives. While the US Safe Harbor framework exists, many Norwegian enterprises prefer their data to never leave the EEA.

Using a provider like CoolVDS with data centers in Oslo ensures you aren't accidentally routing sensitive customer data through a Patriot Act-compliant server farm in Virginia.

Summary

To survive the modern web traffic patterns of 2010:

1. Decouple: Use Nginx for connections/static files, Apache for PHP logic.
2. Isolate: Avoid OpenVZ overselling. Choose Xen-based virtualization.
3. Locate: Host near your users to minimize latency and simplify legal compliance.

Do not let your infrastructure be the bottleneck. If you are ready to move off sluggish shared hosting, spin up a CoolVDS Xen instance today. We offer a standard build with CentOS 5 pre-configured for high performance.