Stop Wasting RAM: The Definitive Guide to Nginx Reverse Proxy on Linux

The Apache Problem: Why Your Server Is Crawling

It is 3:00 AM. Your monitoring alerts are screaming. Your load average is through the roof, but your CPU usage is barely 10%. What is happening? You have hit the classic Apache bottleneck: RAM exhaustion.

Every time a client requests a 2KB logo image, Apache spawns a heavy process or thread. If you are running PHP (and who isn't?), that process drags the entire PHP interpreter into memory just to serve a static file. When you hit MaxClients, your site doesn't slow down—it vanishes. It stops accepting connections.

In 2010, hardware is getting faster, but throwing more RAM at a bad architecture is just burning budget. The solution isn't a bigger server; it's a smarter gatekeeper. Enter Nginx.

The Architecture: Nginx as the Bouncer

The most robust setup for high-traffic sites right now is not replacing Apache entirely (since .htaccess and mod_rewrite compatibility are still vital for many CMSs like Drupal or WordPress), but placing Nginx in front of it.

Nginx uses an asynchronous, event-driven architecture. Unlike Apache’s blocking process model, Nginx handles thousands of concurrent connections within a tiny memory footprint using the epoll system call on Linux kernel 2.6. It serves the static assets (images, CSS, JS) instantly and proxies only the dynamic PHP requests to Apache.

Configuration: The Reverse Proxy Setup

Assuming you are running CentOS 5.5 or Ubuntu 10.04 LTS, install Nginx. We are going to bind Nginx to port 80 and move Apache to port 8080.

Here is the nginx.conf configuration block that separates the men from the boys. This setup handles the static content and passes the heavy lifting to the backend.

server {
    listen       80;
    server_name  example.no www.example.no;

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

    # Pass everything else to Apache
    location / {
        proxy_pass         http://127.0.0.1:8080;
        proxy_redirect     off;
        
        # Essential headers for the backend to know the real IP
        proxy_set_header   Host             $host;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
        
        # Timeouts for slow backend scripts
        proxy_connect_timeout      90;
        proxy_send_timeout         90;
        proxy_read_timeout         90;
    }
}

Pro Tip: Do not forget to install mod_rpaf on your Apache backend. Without it, Apache sees all traffic coming from 127.0.0.1, which breaks your access logs and security restriction layers.

Disk I/O: The Silent Killer

You can tune Nginx until you are blue in the face, but if your underlying storage subsystem is thrashing, your Time To First Byte (TTFB) will suffer. This is where most VPS providers fail. They cram hundreds of users onto a single SATA array using OpenVZ virtualization.

When your neighbor runs a backup script, your database locks up. This is known as the "noisy neighbor" effect.

At CoolVDS, we reject this model. We utilize Xen virtualization to ensure strict isolation of resources. Furthermore, we are among the first in the Nordic region to deploy enterprise-grade SSD storage arrays for our premium tiers. While standard 15k RPM SAS drives are decent, SSDs eliminate the seek-time latency that plagues database-heavy applications.

The Norwegian Context: Latency Matters

If your target audience is in Oslo, Bergen, or Trondheim, hosting in a datacenter in Texas is negligence. The speed of light is a hard limit. A round trip across the Atlantic adds 100ms+ latency before your server even processes the request.

Local hosting isn't just about speed; it's about compliance with the Norwegian Personal Data Act (Personopplysningsloven). Keeping data within national borders simplifies your adherence to the Data Protection Directive.

CoolVDS peers directly at NIX (Norwegian Internet Exchange). When a user in Oslo requests your site, the packet stays local. Low hops, low latency, instant response.

Benchmarking the Difference

We ran a simple ab (Apache Bench) test: 1000 concurrent requests against a standard WordPress installation.

Conclusion

Efficiency is not optional. By offloading static requests to Nginx, you free up Apache to do what it does best: process code. You reduce memory usage, increase stability, and handle traffic spikes without crashing.

However, software optimization requires reliable hardware. Don't let a generic oversold VPS undercut your engineering efforts. Deploy a Xen-based instance on CoolVDS today and see what sub-millisecond I/O latency does for your application.