Stop Letting Apache Kill Your Server RAM
If I see one more httpd.conf with MaxClients set to 256 on a server with 512MB of RAM, I’m going to lose it. It is 2009. We know better. You cannot scale a modern PHP application on a standard LAMP stack alone, especially not when the "Digg Effect" or a link from VG.no hits your site.
Here is the reality: Apache is fantastic at processing PHP, but it is terrible at holding open connections. Every user on a slow connection (Keep-Alive) ties up a heavy Apache process. Your server hits swap, the load average spikes to 50, and you are offline.
The solution isn't "buy more RAM." The solution is architecture. We are going to put Nginx in front of Apache. Nginx will handle the heavy lifting (static files, connection handling) and only pass the necessary PHP requests to Apache.
The Architecture: Nginx + Apache
In this setup, Nginx listens on port 80. It uses an asynchronous, event-driven architecture (thanks to the epoll system call in Linux 2.6). It consumes practically no RAM per connection. Apache listens on port 8080, strictly on localhost, handling only the dynamic content.
Pro Tip: When moving to this architecture, ensure your logging is configured correctly. You want the real client IP in your Apache logs, not 127.0.0.1. You'll need mod_rpaf installed on Apache.
1. Install Nginx (The EPEL Way)
On a standard CentOS 5 server (like the Xen instances we run at CoolVDS), Nginx isn't in the base repo. You need EPEL.
su -
rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
yum install nginx
2. Configure Nginx as a Proxy
Open /etc/nginx/nginx.conf. We are going to tell Nginx to serve images, CSS, and JS directly from the disk (which requires fast I/O) and send everything else to Apache.
Here is a battle-tested config I used last week for a client dealing with a massive traffic spike from a Norwegian news portal:
server {
listen 80;
server_name example.no www.example.no;
root /var/www/html;
# Serve static files directly. No Apache overhead.
location ~* \.(jpg|jpeg|gif|png|css|js|ico|xml)$ {
access_log off;
expires 30d;
}
# Pass everything else to Apache
location / {
proxy_pass http://127.0.0.1:8080/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size 10m;
client_body_buffer_size 128k;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
}
}
Why Hardware Matters (The CoolVDS Factor)
Configuration is only half the battle. Nginx relies heavily on the OS filesystem cache to serve those static files quickly. If your VPS provider puts you on an overloaded SATA array with 50 other neighbors, your iowait will skyrocket. It doesn't matter how good your Nginx config is if the disk head is thrashing.
This is why we architect CoolVDS differently. We use 15k RPM SAS drives in RAID 10 configurations. We are also piloting early enterprise SSDs for database journals. When you combine Nginx's efficiency with high-throughput storage, latency drops to single-digit milliseconds.
| Metric | Apache Only (Prefork) | Nginx Reverse Proxy |
|---|---|---|
| RAM Usage (500 conn) | ~1.5 GB (Swapping) | ~40 MB |
| Max Concurrent Users | 250 (Default limit) | 3,000+ |
| Static File Speed | Slow (Process overhead) | Instant (syscall sendfile) |
A Note on Norwegian Compliance
Working in Norway, we have to respect the Personopplysningsloven (Personal Data Act). When you configure these proxies, you are creating logs in two places (Nginx and Apache). Ensure your log rotation policies in /etc/logrotate.d/ are strict. Don't hoard IP addresses longer than necessary. The Datatilsynet (Data Inspectorate) takes a dim view of excessive data retention.
Conclusion
Stop upgrading your RAM just to feed Apache's bloat. By placing Nginx in front, you reduce memory footprint, increase stability, and prepare your site for traffic spikes. It’s the standard for modern 2009 hosting.
If you need a sandbox to test this configuration without risking your production environment, spin up a Xen-based VPS. We don't oversell resources, so your benchmarks will actually match production reality.