PHP-FPM Performance Tuning: Stop Letting Apache Eat Your RAM

If you are still serving PHP through Apache's mod_php in late 2012, you are voluntarily burning money. I said it. The traditional LAMP stack is dying, and the bottleneck is almost always the memory footprint of the Apache process prefork model. Every time a client requests a 2KB CSS file, Apache spawns a heavy child process with the entire PHP interpreter embedded, wasting precious RAM.

It is time to get serious. It is time to embrace the LEMP stack (Linux, Nginx, MySQL, PHP-FPM).

I recently migrated a high-traffic e-commerce client in Oslo from a legacy hosting environment to a dedicated LEMP setup. Their load times dropped from 1.2s to 350ms, and their RAM usage was cut in half. The secret? Properly tuned PHP-FPM (FastCGI Process Manager) paired with APC (Alternative PHP Cache).

The Architecture: Why FPM Wins

Unlike mod_php, FPM runs as a standalone daemon. Nginx handles the heavy lifting of static assets (images, CSS, JS) with negligible memory usage, and only passes actual PHP execution requests to the FPM socket. This decoupling allows you to scale the web server independently from the application server.

However, FPM is not magic; out of the box, most distributions like Ubuntu 12.04 LTS or CentOS 6 ship with configurations designed for safety, not speed. Let's fix that.

Step 1: Process Manager - Static vs. Dynamic

The most controversial setting in /etc/php5/fpm/pool.d/www.conf is the pm directive. By default, it is set to dynamic.

• Dynamic: FPM starts a few children and spawns more as load increases. Good for shared hosting, bad for predictable performance.
• Static: FPM starts a fixed number of children and keeps them alive. No spawning overhead. No latency spikes.

Pro Tip: If you have a VPS with dedicated RAM (like the KVM slices we provision at CoolVDS), use pm = static. If you are on a resource-constrained shared environment, stick to dynamic, but honestly, you should upgrade.

Calculating pm.max_children

Don't guess this number. Do the math. If you overshoot, the OOM (Out of Memory) killer will nuke your PHP process and your site goes 502 Bad Gateway. If you undershoot, you waste idle CPU cycles.

Run this command during peak load to see the average memory per PHP process:

Let's say your average process is 40MB and you have a 2GB VPS. Leave 512MB for the OS and MySQL. That leaves ~1.5GB for PHP.

1500MB / 40MB = 37 children.

Here is how your configuration should look for a high-performance setup:

; /etc/php5/fpm/pool.d/www.conf

[www]
user = www-data
group = www-data

; Use a Unix socket for lower latency than TCP
listen = /var/run/php5-fpm.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

; PERFORMANCE SETTINGS
pm = static
pm.max_children = 37
pm.max_requests = 1000

; Logs
request_slowlog_timeout = 5s
slowlog = /var/log/php5-fpm.log.slow

Setting pm.max_requests is crucial. It forces the child process to restart after processing 1000 requests, which is a failsafe against the notorious memory leaks often found in 3rd party PHP libraries.

Step 2: The Holy Grail - APC Caching

If you run PHP 5.3 or 5.4 without an opcode cache, you are forcing the server to re-compile your PHP scripts from source code to bytecode on every single request. This is madness.

Install APC immediately:

Then, tune apc.ini. The default shared memory segment (32MB) is laughably small for any modern CMS like Magento or Drupal.

; /etc/php5/conf.d/apc.ini
extension=apc.so

; Turn it on
apc.enabled=1
apc.shm_segments=1

; Give it enough RAM to hold all your opcodes. 
; Check apc.php stats to confirm fragmentation is low.
apc.shm_size=128M

; Time to live. 0 means don't expire unless full.
apc.ttl=7200
apc.user_ttl=7200

; vital for including files with relative paths
apc.stat=1

With APC enabled and tuned, I typically see CPU usage drop by 40% and response times improve by 300%. It is the single most effective change you can make.

Step 3: Unix Sockets vs. TCP

You will see many guides connecting Nginx to PHP via 127.0.0.1:9000. While TCP is robust and allows you to run PHP on a separate server, it adds overhead from the networking stack. For a single-server architecture, Unix Sockets are faster. They bypass the TCP handshake and routing entirely.

Just ensure your permissions are correct in the Nginx config, or you will hit 502 errors:

# /etc/nginx/sites-available/default

server {
    listen 80;
    server_name example.no;

    root /var/www/html;
    index index.php index.html;

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        
        # The faster way
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        
        fastcgi_index index.php;
        include fastcgi_params;
    } 
}

The Hardware Reality

You can tweak configurations until 3 AM, but you cannot code your way out of slow I/O. When PHP-FPM and APC are running hot, your bottleneck shifts to the disk. Database reads and session writes can cripple a server relying on standard 7.2k RPM SATA drives.

This is where infrastructure choice dictates performance limits. At CoolVDS, we have been experimenting with SSD caching and pure SSD storage arrays. The difference in IOPS (Input/Output Operations Per Second) is staggering—often 100x faster than traditional spinning rust.

Furthermore, because we utilize KVM virtualization, your RAM is yours. In the OpenVZ environments sold by budget hosts, "burst RAM" is a marketing myth that vanishes when the host node gets busy. For pm = static to work reliably, you need the guaranteed memory isolation that KVM provides.

Compliance and Reliability

For those of you hosting data for Norwegian customers, remember that speed isn't just about user experience; it's about reliability. The Datatilsynet (Data Inspectorate) is becoming increasingly strict about data availability and integrity under the Personal Data Act. A server crashing due to OOM errors isn't just a technical failure; it's a service availability failure.

Keep your data in Norway, keep your latency low (pinging Oslo from Amsterdam is fast, but pinging Oslo from Oslo is instant), and keep your stack optimized.

Summary

1. Move from Apache mod_php to Nginx + PHP-FPM.
2. Set pm = static if you have the RAM.
3. Enable APC with at least 128MB shared memory.
4. Use Unix Sockets over TCP.
5. Host on KVM virtualization with high-speed storage.

Don't let legacy configurations hold back your application. Spin up a Debian or Ubuntu instance on CoolVDS today, apply these settings, and watch your server load average drop to near zero.