Scaling PHP in 2009: Why We Are Abandoning mod_php for PHP-FPM
If you are running a high-traffic site on a standard LAMP stack (Linux, Apache, MySQL, PHP) right now, you know the nightmare. It’s 2:00 AM, traffic spikes because of a Digg or Slashdot link, and your server starts swapping. Apache hits its MaxClients limit, and suddenly your site is dragging.
The culprit is almost always mod_php. While convenient, embedding the PHP interpreter inside every Apache process is a memory disaster for modern applications like Drupal, Joomla, or Magento.
There is a better way. It involves patching PHP source code and moving to a dedicated FastCGI Process Manager (PHP-FPM). Here is how we do it in production.
The Problem: The Fat Apache Process
When you use Apache with mod_php, every single worker process carries the weight of the entire PHP environment, even if it’s just serving a static logo.jpg. On a standard CentOS 5 server, an Apache child process might consume 20MB to 50MB of RAM. If you have 2GB of RAM, you can only handle roughly 40-50 concurrent users before you hit swap.
That is unacceptable efficiently.
The Solution: Nginx + PHP-FPM
We are seeing a massive shift toward Nginx (Engine-X). Unlike Apache's blocking architecture, Nginx uses an event-driven, asynchronous approach. It can handle thousands of connections with a tiny memory footprint.
However, Nginx cannot process PHP natively. It needs a backend. That is where PHP-FPM (FastCGI Process Manager) comes in. Currently, FPM is a set of patches for the PHP source maintained by Andrei Nigmatulin. It brings enterprise features to FastCGI:
- Adaptive process spawning
- Graceful restarts (no downtime during config changes)
- Slow logging (essential for debugging)
- Emergency restart in case of accidental opcode corruption
Pro Tip: Since PHP-FPM is not in the PHP core yet (as of PHP 5.2.9), you must compile it manually. Do not rely on default RPMs unless you are using a custom repository like Dotdeb. You need root access for this, which is why shared hosting fails here.
War Story: Saving a Norwegian Media Site
Last month, we migrated a popular Norwegian news portal hosted in Oslo. They were crashing daily on a quad-core server with 4GB RAM running Apache. The latency to the NIX (Norwegian Internet Exchange) was fine, but the server load was consistently over 10.0.
We replaced Apache with Nginx 0.7.x and compiled PHP 5.2.9 with the FPM patch. We separated the static file serving (handled instantly by Nginx) from the dynamic processing.
The Results
| Metric | Apache + mod_php | Nginx + PHP-FPM |
|---|---|---|
| RAM Usage (Idle) | 1.2 GB | 350 MB |
| Max Concurrent Users | ~150 | ~800+ |
| Load Average | 8.5 | 0.8 |
Configuration Implementation
If you are on a CoolVDS Xen VPS, you have the compilation tools needed. First, grab the PHP source and the FPM diff patch. When configuring, ensure you enable FPM:
./configure --enable-fastcgi --enable-fpm --with-mcrypt --with-mysql ...
Once installed, you need to configure the XML file (yes, FPM uses XML for config currently). Inside /usr/local/etc/php-fpm.conf, tune your child processes carefully:
<value name="max_children">50</value>
<value name="process_control_timeout">5s</value>
<value name="rlimit_files">1024</value>
Then, tell Nginx to pass PHP requests to the FPM daemon listening on port 9000:
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www/site$fastcgi_script_name;
include fastcgi_params;
}
Why Hardware Matters (Even with FPM)
Software optimization can only go so far. Database writes can still bottle-neck your application. While many hosts overload their nodes with SATA drives, we recognize that I/O wait is the silent killer of performance.
At CoolVDS, we utilize 15k RPM SAS drives in RAID 10 configurations. This ensures that when PHP-FPM writes session data or MySQL flushes buffers, the disk subsystem doesn't choke. Combined with our low-latency connection to the main Scandinavian hubs, your Time-To-First-Byte drops significantly.
Furthermore, because we use Xen virtualization, your RAM is dedicated. Unlike OpenVZ, where a neighbor's memory leak can crash your PHP processes, our allocation is strict. This stability is critical when tuning max_children in your FPM config.
Next Steps
Apache served us well for a decade, but for high-performance dynamic content, the future is FastCGI. If you are serious about handling traffic spikes without buying a farm of servers, you need to compile PHP-FPM.
Ready to compile your own stack? Deploy a developer-friendly Xen VPS on CoolVDS today and get full root access in under 2 minutes.