Stop Apache From Eating Your RAM: The Case for Nginx and PHP-FPM
It is 3:00 AM. Your pager goes off. The load average on your primary web server just hit 50.0. You SSH in, run top, and see the horror: dozens of Apache processes, each consuming 60MB of RAM, fighting over the last scraps of memory while the swap partition cries for mercy. The site is crawling.
If you are running a high-traffic site on a standard LAMP stack (Linux, Apache, MySQL, PHP), this nightmare is inevitable. Apache's prefork MPM with mod_php embeds the PHP interpreter into every single process. Serving a 1KB static image? You just spawned a heavy process to do it. It is inefficient, it is outdated, and quite frankly, it is costing you money.
There is a better way. It involves ditching the Apache bloat for Nginx and coupling it with a specialized patch set for PHP called PHP-FPM (FastCGI Process Manager).
The Problem with mod_php
In the traditional setup, Apache handles everything. When you need to scale, you increase MaxClients. But since every child process carries the full weight of PHP, you run out of RAM long before you run out of CPU. Once you hit swap, your disk I/O spikes, latency to Oslo goes through the roof, and your users leave.
I recently migrated a large Norwegian e-commerce site from a dedicated Apache server to a CoolVDS Xen instance. They were crashing daily. We moved them to Nginx + PHP-FPM, dropped their memory footprint by 60%, and their page load times for customers in Trondheim and Bergen dropped from 2 seconds to 300ms.
Enter PHP-FPM
PHP-FPM is an alternative PHP FastCGI implementation with some additional features useful for heavy-loaded sites. It separates the web server (Nginx) from the PHP processing. Nginx handles the connections and static files (which it does incredibly well using asynchronous I/O), and passes only the PHP requests to the FPM daemon.
Note: As of today in 2009, FPM is not yet in the PHP core. You will need to patch the PHP source or use a repository like Dotdeb (for Debian) or CentALT (for CentOS) that provides pre-patched binaries.
The Configuration
Here is how we tune this for production. The magic happens in php-fpm.conf. Unlike the standard INI files, FPM currently uses an XML format.
<section name="pool">
<value name="name">default</value>
<value name="listen_address">127.0.0.1:9000</value>
<value name="pm">
<value name="style">static</value>
<value name="max_children">50</value>
</value>
<value name="request_terminate_timeout">30s</value>
</section>
Pro Tip: We set the process manager style to static rather than apache-like dynamic spawning. On a dedicated VPS, you want predictable memory usage. If you have enough RAM for 50 children, keep 50 children alive. Don't waste CPU cycles forking and killing processes.
Then, configure Nginx to talk to it:
server {
listen 80;
server_name example.no;
root /var/www/public;
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www/public$fastcgi_script_name;
include fastcgi_params;
}
}
Why Infrastructure Still Matters
Software optimization can only go so far. If your underlying storage is slow, no amount of Nginx tuning will save you when MySQL starts writing heavy temporary tables to disk.
This is why we engineer CoolVDS instances with Enterprise 15k RPM SAS drives in RAID-10. While many budget hosts in Europe are still stuffing SATA drives into overcrowded towers, we ensure that your I/O wait times remain negligible. For a database-heavy PHP application, the disk speed is often the bottleneck.
Norwegian Data & Latency: hosting your data outside the country can introduce unnecessary latency. CoolVDS peers directly at NIX (Norwegian Internet Exchange), ensuring that traffic stays local. Plus, adhering to the Personopplysningsloven (Personal Data Act) is much simpler when your data physically resides in Oslo.
The Verdict
If you are serious about performance, stop relying on the default configurations provided by your OS vendor. Apache is fine for shared hosting, but for a high-performance VPS, the overhead is unacceptable.
By decoupling the web server from the PHP interpreter, you gain stability. By choosing a host with proper virtualization (Xen) and fast disk arrays, you gain speed. It is not rocket science; it is just good systems architecture.
Ready to see the difference? Spin up a CoolVDS instance today. We have pre-built templates for CentOS 5 and Debian Lenny, so you can start compiling your optimized stack immediately.