Stop Letting Apache Eat Your RAM

I looked at a client's top output yesterday and wanted to weep. They were running a standard LAMP stack on a generic VPS. Apache was spawning prefork children like there was no tomorrow, each one dragging a full PHP interpreter along with it just to serve a 4KB CSS file. The server was thrashing swap so hard I could practically hear the hard drive heads screaming from the datacenter.

It is 2011. We have better ways to do this. If you are still relying on mod_php for high-traffic sites, you are burning money on RAM you don't need.

The solution is decoupling. We need Nginx to handle the heavy lifting of connections and static files, and PHP-FPM (FastCGI Process Manager) to handle the logic. Since PHP 5.3.3, FPM is part of the core. It’s stable. It’s fast. And unlike the old spawn-fcgi hacks we used in 2009, it actually manages processes intelligently.

The Architecture: Nginx + PHP-FPM

In this setup, Nginx acts as a reverse proxy. It handles the "C10k" problem (10,000 concurrent connections) with its event-driven architecture. When it sees a .php file, it passes the request via TCP or a Unix Socket to the PHP-FPM daemon.

This means your web server footprint drops from hundreds of megabytes to a fraction of that. But installing it is only step one. Tuning it is where the professionals separate themselves from the amateurs.

Configuring the Pool: The Meat of the Matter

The default configuration in CentOS 6 (via EPEL) or Debian Squeeze is usually safe, but safe doesn't handle traffic spikes. You need to edit your pool config, usually found at /etc/php-fpm.d/www.conf.

1. Choose Your Manager

You have three choices: static, dynamic, or ondemand (if you are on the cutting edge). For serious production servers, I often prefer static if I know the hardware capacity exactly.

If you use dynamic (common for shared environments), you must tune the children limits. Do not guess these numbers. Calculate them.

2. Calculating Max Children

Run this command to see how much memory an average PHP-FPM process consumes on your site:

If your average process is 40MB and you have a 2GB CoolVDS instance (leaving 500MB for the OS and DB), you have roughly 1.5GB for PHP.

1500MB / 40MB = 37 max_children.

Set your config accordingly:

pm.max_children = 35
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 15
pm.max_requests = 500

Pro Tip: Always set pm.max_requests. PHP has a history of memory leaks. Recycling the process after 500 requests is a safety net that keeps your server stable over months of uptime.

The I/O Bottleneck nobody talks about

You can tune PHP all day, but if your disk subsystem is slow, your database queries will pile up, locking your PHP processes waiting for I/O. This creates a backlog. Your load average spikes, Nginx returns 502 Bad Gateway, and your phone starts buzzing.

This is where infrastructure choice becomes critical. Most cheap hosting providers in Europe are still spinning 7.2k RPM SATA drives in RAID 5. That is suicide for a database-heavy application.

At CoolVDS, we have moved aggressively to Enterprise SSD storage and SAS 15k setups in RAID-10. We don't oversubscribe our disk I/O. When you run a vzdump backup or a heavy MySQL JOIN, you aren't fighting 50 other neighbors for disk time.

Local Latency: The Norwegian Advantage

If your customers are in Oslo, Bergen, or Trondheim, why are you hosting in Texas? The speed of light is a hard limit. Hosting in the US adds 120ms+ of latency to every single packet. For a PHP application making multiple round-trips to the browser, that adds up to seconds of load time.

By keeping your data within the Nordics, you also simplify compliance with the Personopplysningsloven (Personal Data Act). While Safe Harbor exists, keeping data on Norwegian soil (or within the EEA) satisfies the Datatilsynet requirements and builds trust with your local user base. We peer directly at NIX (Norwegian Internet Exchange), meaning your local traffic stays local.

Conclusion

Moving from Apache mod_php to Nginx + PHP-FPM is the single most effective upgrade you can make for a high-load site in 2011. It lowers memory footprint and increases concurrency.

But software can only do so much. If your underlying virtualization is built on oversold OpenVZ containers with slow spinning disks, you will hit a wall. Don't let IOwait kill your SEO rankings.

Ready to test the difference? Deploy a KVM-based instance with SSD storage on CoolVDS today. We can have your root access ready in under 60 seconds.