It's 2011. Stop Running PHP Like It's 2004.
If you are still serving PHP applications using Apache's mod_php, you are essentially setting money on fire. Every time a static file—a JPEG, a CSS sheet, a favicon—is requested, your server spawns a heavy Apache child process loaded with the entire PHP interpreter. It is inefficient, it eats RAM for breakfast, and it is the primary reason your server falls over when traffic spikes.
We are seeing this daily with clients moving from shared hosting to our infrastructure. They throw more RAM at the problem, but the architecture is fundamentally flawed. The solution isn't more hardware; it's better process management.
Enter PHP-FPM (FastCGI Process Manager).
The Architecture Shift: Nginx + FPM
Since PHP 5.3.3, FPM has been part of the core. It separates the web server (Nginx) from the PHP processing. Nginx handles the static files and massive concurrency (thanks to its event-driven architecture), while passing only the actual PHP execution requests to the FPM service via a Unix socket or TCP.
The result? You can serve 10,000 concurrent static connections with a few megabytes of RAM, leaving your CPU cycles free for the heavy lifting of your application logic.
Configuring FPM for Stability
Installing it is easy (apt-get install php5-fpm on Debian Squeeze or Ubuntu 10.04 LTS), but the default configurations are almost always too conservative or dangerously aggressive. Here is the reality of tuning /etc/php5/fpm/pool.d/www.conf.
The Process Manager (`pm`) Setting
Most tutorials tell you to use dynamic. On a dedicated CoolVDS instance where you know exactly what resources are available, I often recommend static for consistent latency, provided you have the RAM.
; /etc/php5/fpm/pool.d/www.conf
; If you have plenty of RAM and hate latency
pm = static
pm.max_children = 50
; If you are on a smaller VPS and need to save memory
pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 35
Pro Tip: Calculate yourmax_childrenaccurately. Runps -ylC php5-fpm --sort:rssto see the average memory usage per process. If your average process is 60MB and you have a 4GB CoolVDS instance (leaving 500MB for the OS/DB), your absolute max is roughly (3500 / 60) = ~58 children. Set it to 50 to be safe.
Handling the "Thundering Herd"
One specific issue we see in high-load environments involves the listen.backlog. When FPM is busy, requests queue up. If this queue fills, Nginx returns a 502 Bad Gateway.
In your sysctl.conf, you need to ensure the kernel allows a sufficient connection backlog, or FPM's internal settings won't matter.
# /etc/sysctl.conf
net.core.somaxconn = 1024
Then match this in your FPM config:
listen.backlog = 1024
Why Disk I/O is the Silent Killer
You can tune PHP-FPM until you are blue in the face, but if your database is waiting on a slow hard drive, your PHP processes will block. When a process blocks, it sits there doing nothing, consuming a slot in your max_children pool.
This is where infrastructure choice dictates performance. Standard 7200 RPM SATA drives struggle with random I/O operations (IOPS). At CoolVDS, we have deployed enterprise-grade Solid State Drives (SSDs) across our primary clusters. The difference in database query time is not a percentage; it is an order of magnitude. An SSD can clear the I/O wait state instantly, freeing up the PHP worker to handle the next request.
Latency Matters: The Norwegian Context
For those of you targeting users in Oslo, Bergen, or Trondheim, physics is your enemy. Hosting your application in a datacenter in Germany or the US adds 30-100ms of round-trip time (RTT) to every packet.
If your PHP application requires 50 sequential database queries or API calls to load a page, that latency stacks. A 30ms delay becomes 1.5 seconds of pure waiting. CoolVDS infrastructure is peered directly at NIX (Norwegian Internet Exchange), ensuring your data takes the shortest possible path to your users. Low latency plus fast execution means higher conversion rates.
Data Privacy in 2011
A quick note for the CTOs: With the Data Inspectorate (Datatilsynet) keeping a close eye on personal data handling under the Personal Data Act, you need to be careful with your logs. Nginx and FPM log everything by default.
Ensure your log rotation is aggressive so you aren't storing IP addresses longer than necessary. In Nginx:
# /etc/nginx/nginx.conf
log_format private '0.0.0.0 - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent"';
While anonymizing logs makes debugging harder, it keeps you compliant.
The Verdict
Apache is still fine for local development or shared hosting where you don't care about performance. But for serious production workloads in late 2011, the LAMP stack is evolving into LEMP (Linux, Nginx, MySQL, PHP).
Don't let legacy configurations hold your application back. Spin up a CoolVDS SSD instance today, install php5-fpm, and watch your load averages drop.