Is Your Web Server Choking on Traffic? It's Probably mod_php.
It is 3:00 AM. Your Nagios alert goes off. Load average is spiking above 20. You SSH in, run top, and see a wall of Apache processes consuming 80MB of RAM each. You aren't being DDoS'd; you just got a link on a popular blog, and your server is melting under legitimate traffic.
If this sounds familiar, you are likely still using the default LAMP stack configuration: Apache with mod_php. In 2011, this is the architectural equivalent of trying to commute to work in a main battle tank. It works, but it’s heavy, slow, and expensive.
There is a better way. It is called PHP-FPM (FastCGI Process Manager).
The Problem: Apache and Memory Bloat
When you run PHP as an Apache module (mod_php), every single Apache worker process embeds the PHP interpreter. This means if you are serving a 2KB static CSS file, Apache still loads the entire PHP engine into memory for that request. It is a massive waste of RAM.
Furthermore, Apache usually relies on the prefork MPM (Multi-Processing Module) to be thread-safe with PHP. This forces it to spawn a new process for every connection. If you have 2GB of RAM and each process takes 50MB, you hit your limit at roughly 40 concurrent users. That is unacceptable for a modern business.
The Solution: Decoupling with PHP-FPM
PHP-FPM separates the web server from the PHP processing. We use Nginx (which is event-driven and uses negligible RAM) to handle connections and static files. When Nginx encounters a PHP script, it passes the request to a dedicated pool of PHP-FPM workers via a TCP or Unix socket.
The result? Your web server memory footprint drops by 80%. You can handle thousands of concurrent static connections, and your PHP workers only wake up when actual code needs execution.
Configuration: Tuning the Pool
Installing PHP-FPM on CentOS 6 or Debian Squeeze is straightforward, but the default configs are rarely optimized for high traffic. The magic happens in /etc/php5/fpm/pool.d/www.conf.
Here is a configuration optimized for a CoolVDS instance with 4GB RAM. We use the dynamic process manager to scale based on load:
; /etc/php-fpm.d/www.conf
user = nginx
group = nginx
pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 35
pm.max_requests = 500
Pro Tip: Calculate pm.max_children carefully. If your average PHP process uses 60MB, and you have 3GB of free RAM allocated for PHP: 3072MB / 60MB = ~51 max children. Setting this too high causes swapping, which kills performance instantly.
Connecting Nginx
Apache is dying. Nginx is the future. Here is how you configure the virtual host to talk to your FPM backend:
server {
listen 80;
server_name example.com;
root /var/www/html;
# Serve static files directly (super fast)
location ~* \.(jpg|jpeg|gif|css|png|js|ico|html)$ {
expires max;
}
# Pass PHP scripts to FastCGI server
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
}
Infrastructure Matters: The Role of I/O
Software optimization can only take you so far. PHP sessions are written to disk. MySQL temporary tables are written to disk. If you are hosting on a provider that crams 500 users onto a single hard drive, your optimized config will just wait on I/O wait (iowait).
This is where CoolVDS differs from the budget shared hosting flooding the market. We don't oversubscribe.
| Feature | Generic Shared Hosting | CoolVDS KVM VPS |
|---|---|---|
| Virtualization | OpenVZ (Oversold RAM) | KVM (Guaranteed RAM) |
| Storage | Slow SATA 7.2k RPM | Enterprise SSD RAID-10 |
| Latency to Oslo | 40-100ms (Hosted in Germany/US) | < 5ms (Local Peering) |
Local Latency and Compliance
For our clients in Norway, physical location is critical. Routing traffic through Frankfurt or Amsterdam adds unnecessary milliseconds to every handshake. If your application makes multiple database calls per request, that latency compounds.
Furthermore, keeping data within Norwegian borders satisfies the strict requirements of the Personal Data Act (Personopplysningsloven) and Datatilsynet guidelines. Do not risk your reputation by hosting sensitive customer data on a budget server in a jurisdiction you don't understand.
The Verdict
Moving to PHP-FPM reduces memory usage, increases concurrency, and stabilizes your server under load. But software needs a solid foundation. You need guaranteed RAM and fast I/O to truly see the benefits.
Stop letting Apache eat your RAM. Deploy a CoolVDS SSD VPS today and watch your load average drop to zero.