Stop Wasting RAM: Migrating from Apache mod_php to Nginx & PHP-FPM

Let’s be honest: if you are still running PHP embedded inside Apache (mod_php) in late 2011, you are actively choosing to burn money. I see this configuration every day on client servers. A standard 2GB VPS falls over under a Digg effect or a modest Slashdotting, not because the CPU is maxed, but because Apache is spawning massive child processes just to serve a 4KB CSS file.

It is archaic. It is inefficient. And with the release of PHP 5.3.3 merging FPM (FastCGI Process Manager) into the core, there is no excuse anymore.

I’m going to show you how to strip out the bloat and switch to the Nginx + PHP-FPM stack. We recently migrated a high-traffic Norwegian e-commerce client from a bloated Apache setup to this architecture on CoolVDS. The result? Load average dropped from 5.0 to 0.4, and page load times for customers in Oslo went from "noticeable lag" to instantaneous.

The Problem: The Apache Memory Hog

When you use mod_php, every single Apache worker process carries the weight of the entire PHP interpreter. Even if that worker is just serving logo.png, it's holding onto 20MB+ of RAM.

If you have a VPS with 1GB of RAM, you hit your MaxClients limit fast. Once you start swapping to disk, your site effectively dies. In the hosting world, disk I/O is the bottleneck. Standard SATA drives on oversold hosts cannot handle swap thrashing.

The Solution: PHP-FPM & Nginx

The architecture is simple: Let Nginx handle the heavy lifting of connections (the C10k problem) and serving static files. It is non-blocking and event-driven. It hands off only the PHP requests to a separate pool of PHP workers managed by FPM.

Step 1: Installing the Stack on CentOS 6

First, enable the EPEL and Remi repositories to ensure you aren't stuck with ancient packages. We want PHP 5.3.8 or newer.

rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-5.noarch.rpm
rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-6.rpm
yum --enablerepo=remi install nginx php-fpm php-mysql

Step 2: Tuning the Pool

The default configuration is rarely optimal for production. Open /etc/php-fpm.d/www.conf. The most critical directive is the process manager.

; Use 'dynamic' for general VPS use, or 'static' if you have dedicated RAM
pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 35
; Prevent memory leaks by respawning workers periodically
pm.max_requests = 500

Pro Tip: Don't blindly set max_children to 500. Calculate your average PHP process size (usually 20-30MB) and divide your available RAM (minus OS overhead) by that number. If you oversubscribe, you will crash.

Step 3: Configuring Nginx

Tell Nginx to pass .php files to the FPM daemon listening on port 9000 (or a unix socket if you want to shave off a few more milliseconds of latency).

server {
    listen 80;
    server_name example.no;
    root /var/www/html;

    location / {
        try_files $uri $uri/ /index.php;
    }

    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;
    }
}

Why Storage Speed Matters (The CoolVDS Factor)

Even with FPM, your database is likely the next bottleneck. When PHP sessions are written to disk or MySQL performs complex joins, you are at the mercy of the disk spindle speed.

Most hosting providers in Europe are still running 7.2k RPM SATA drives in RAID 10. That’s reliable, but slow. At CoolVDS, we are aggressive adopters of Solid State Drive (SSD) arrays for our storage tiers. The difference in random I/O performance is staggering.

When a session file needs to be read, an SSD retrieves it in sub-millisecond timeframes. A spinning disk has to physically move a head. In a high-concurrency environment, those seek times add up to "Server Too Busy" errors.

Local Nuances: Latency and Law

For those of us operating in Norway, latency to NIX (Norwegian Internet Exchange) is paramount. Hosting your application in a datacenter in Texas adds ~140ms of round-trip time. That makes your snappy PHP-FPM application feel sluggish to a user in Trondheim.

Furthermore, with the Personopplysningsloven (Personal Data Act) strictly enforced by Datatilsynet, keeping customer data within Norwegian borders is not just a performance tweak—it's often a compliance requirement for serious businesses. CoolVDS infrastructure is physically located here, ensuring you meet both latency targets and legal obligations.

The Verdict

Apache mod_php served us well in the 2000s, but the web has evolved. Users expect desktop-application responsiveness. By decoupling your web server from your PHP interpreter, you gain stability, scalability, and sanity.

If you are tired of tweaking KeepAliveTimeout only to see your RAM vanish, it’s time to switch. And if your current host is still running your database on spinning rust, you are fighting a losing battle.

Don't let slow I/O kill your SEO. Deploy a test CentOS 6 instance on CoolVDS SSD infrastructure in 55 seconds and feel the difference.