PHP-FPM (FastCGI Process Manager): Vollständige Einrichtungs-, Konfigurations- und Optimierungsanleitung

PHP-FPM (PHP FastCGI Process Manager) ist ein leistungsstarker alternativer PHP-Prozessmanager, der das FastCGI-Protokoll implementiert, um die PHP-Ausführung vom Webserver-Prozess zu entkoppeln. Anstatt für jede eingehende HTTP-Anfrage einen neuen PHP-Interpreter zu starten – wie es das traditionelle CGI tut – verwaltet PHP-FPM einen persistenten Pool von Worker-Prozessen, die PHP-Antworten mit deutlich geringerem Overhead entgegennehmen, ausführen und zurückgeben.

Für jeden Produktions-Webserver, der WordPress, Laravel, Symfony oder benutzerdefinierte PHP-Anwendungen betreibt, ist PHP-FPM der Standard-Handler. Er ermöglicht eine detaillierte Kontrolle über den Prozesslebenszyklus, Speicherlimits, Request-Queuing und anwendungsbezogene Isolation – Funktionen, die mit mod_php oder einfachem CGI schlicht nicht verfügbar sind.

Wie sich PHP-FPM von CGI und mod_php unterscheidet

Um zu verstehen, warum PHP-FPM wichtig ist, hilft es zu sehen, was es genau ersetzt und warum diese Alternativen bei größerem Maßstab nicht ausreichen.

CGI forkt für jede Anfrage einen neuen OS-Prozess. Bei moderatem Traffic entstehen dadurch tausende Fork/Exec/Exit-Zyklen pro Minute, die CPU und Speicher auslasten. mod_php bettet den PHP-Interpreter direkt in jeden Apache-Worker ein, was bedeutet, dass jeder Apache-Prozess – selbst einer, der ein statisches Bild ausliefert – die vollständige PHP-Laufzeitumgebung im Speicher hält. PHP-FPM löst beide Probleme: Worker sind persistent und vollständig vom Webserver getrennt, sodass NGINX oder Apache statische Assets nativ verarbeiten, während PHP-FPM ausschließlich die PHP-Ausführung übernimmt.

PHP-FPM-Architektur: Anfrage-Ablauf im Detail

Das Verständnis des internen Anfragepfads ist für die Optimierung und Fehlersuche unerlässlich.

1. Ein Browser sendet eine HTTP-Anfrage für eine .php-Ressource.
2. Der Webserver (NGINX oder Apache) empfängt die Anfrage und gleicht sie mit einem Location-Block oder einer FilesMatch-Direktive ab.
3. Der Webserver leitet die Anfrage über das FastCGI-Protokoll an PHP-FPM weiter – entweder über einen Unix-Domain-Socket (/run/php/php8.2-fpm.sock) oder einen TCP-Socket (127.0.0.1:9000).
4. Der Master-Prozess von PHP-FPM leitet die Anfrage an einen verfügbaren Worker aus dem konfigurierten Pool weiter.
5. Der Worker führt das PHP-Skript aus, schreibt in stdout und gibt die Antwort an den Webserver zurück.
6. Der Webserver liefert das gerenderte HTML an den Client aus.
7. Der Worker-Prozess wird nicht beendet – er kehrt in den Idle-Pool zurück und ist für die nächste Anfrage bereit.

Unix-Sockets werden für die lokale Kommunikation gegenüber TCP bevorzugt, da sie den TCP/IP-Stack vollständig umgehen, die Latenz in Benchmarks um 10–20 % reduzieren und den Overhead durch Port-Bindung und Loopback-Routing eliminieren.

Prozessverwaltungsmodi

PHP-FPM unterstützt drei pm (Process Manager)-Modi, und die Wahl des falschen ist einer der häufigsten Konfigurationsfehler.

pm = static

Eine feste Anzahl von Workern läuft immer, unabhängig vom Traffic. Verwenden Sie diesen Modus auf dedizierten Servern, bei denen Sie vorhersehbaren, vorab zugewiesenen Speicher wünschen und den Idle-Overhead in Kauf nehmen können.

pm = static
pm.max_children = 20

pm = dynamic

PHP-FPM startet eine Grundanzahl von Workern und skaliert innerhalb definierter Grenzen nach oben oder unten. Dies ist der am häufigsten verwendete Modus und der richtige Standard für die meisten VPS-Hosting-Umgebungen.

pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10
pm.max_requests = 500

pm = ondemand

Worker werden nur bei eingehenden Anfragen gestartet und nach pm.process_idle_timeout Sekunden Inaktivität beendet. Dies minimiert den Idle-Speicherverbrauch und ist ideal für Websites mit geringem Traffic oder gemeinsam genutzte Umgebungen, in denen Dutzende von Pools koexistieren.

pm = ondemand
pm.max_children = 20
pm.process_idle_timeout = 10s

Kritischer Fallstrick: ondemand verursacht eine Cold-Start-Latenz bei der ersten Anfrage nach einer Idle-Phase. Für latenzempfindliche Anwendungen ist dynamic immer die bessere Wahl.

pm.max_children korrekt berechnen

Hier machen die meisten Administratoren kostspielige Fehler. Wird pm.max_children zu hoch gesetzt, führt dies zu Speichererschöpfung und OOM-Kills; zu niedrig führt zu Request-Queuing und 502-Fehlern unter Last.

Die korrekte Formel:

pm.max_children = (Available RAM for PHP) / (Average PHP worker memory usage)

So ermitteln Sie den durchschnittlichen PHP-Worker-Speicher:

ps --no-headers -o "rss,cmd" -C php-fpm8.2 | awk '{ sum+=$1 } END { printf "Average: %d MBn", sum/NR/1024 }'

Auf einem VPS mit 2 GB RAM, bei dem NGINX, MySQL und das OS ~600 MB verbrauchen, stehen Ihnen etwa 1.400 MB für PHP zur Verfügung. Wenn jeder Worker ~70 MB verwendet, beträgt Ihr sicherer pm.max_children-Wert 20. Setzen Sie ihn niemals auf Basis von Schätzungen.

PHP-FPM installieren

Debian / Ubuntu

sudo apt update
sudo apt install php8.2-fpm
sudo systemctl enable php8.2-fpm
sudo systemctl start php8.2-fpm

CentOS / AlmaLinux / RHEL (mit Remi-Repository)

sudo dnf install epel-release
sudo dnf install https://rpms.remirepo.net/enterprise/remi-release-9.rpm
sudo dnf module enable php:remi-8.2
sudo dnf install php-fpm
sudo systemctl enable php-fpm
sudo systemctl start php-fpm

Überprüfen Sie, ob der Dienst läuft, und bestätigen Sie den Socket-Pfad:

sudo systemctl status php8.2-fpm
ls -la /run/php/

PHP-FPM-Pools konfigurieren

Die Haupt-PHP-FPM-Konfiguration befindet sich unter /etc/php/8.2/fpm/php-fpm.conf, aber individuelle Pool-Definitionen gehören in /etc/php/8.2/fpm/pool.d/. Auf RHEL-basierten Systemen befinden sich Pool-Dateien in /etc/php-fpm.d/.

Jeder Pool ist eine isolierte Ausführungsumgebung. Wenn mehrere PHP-Anwendungen auf demselben Server betrieben werden – beispielsweise eine WordPress-Website und eine Laravel-API – bedeutet dies, separate Pool-Dateien mit separaten Benutzern, Socket-Pfaden und Ressourcenlimits zu erstellen. Dies ist die korrekte Architektur für Multi-Tenant-Setups und ist wesentlich sicherer als die gemeinsame Nutzung eines einzigen Pools.

Beispiel: Produktions-Pool-Konfiguration

[myapp]
user = myapp
group = myapp

; Unix socket — always prefer this over TCP for local communication
listen = /run/php/myapp-fpm.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

; Process manager
pm = dynamic
pm.max_children = 30
pm.start_servers = 5
pm.min_spare_servers = 3
pm.max_spare_servers = 10
pm.max_requests = 1000

; Slow log — log requests taking longer than 2 seconds
slowlog = /var/log/php-fpm/myapp-slow.log
request_slowlog_timeout = 2s

; Status and ping endpoints
pm.status_path = /fpm-status
ping.path = /fpm-ping

; Environment isolation
clear_env = yes
env[HOSTNAME] = $HOSTNAME
env[PATH] = /usr/local/bin:/usr/bin:/bin

; PHP value overrides per pool
php_admin_value[error_log] = /var/log/php-fpm/myapp-error.log
php_admin_flag[log_errors] = on
php_admin_value[memory_limit] = 256M
php_admin_value[upload_max_filesize] = 64M
php_admin_value[post_max_size] = 64M

Die clear_env = yes-Direktive ist eine sicherheitskritische Einstellung, die häufig übersehen wird. Ohne sie erben PHP-Worker alle Umgebungsvariablen vom Master-Prozess, was potenziell sensible systemseitige Daten in das $_ENV Ihrer Anwendung durchsickern lässt.

PHP-FPM mit NGINX integrieren

NGINX verfügt über keine native PHP-Ausführungsfähigkeit – es verlässt sich vollständig auf FastCGI, um PHP-Anfragen zu delegieren. Dies ist tatsächlich ein architektonischer Vorteil: NGINX verarbeitet statische Dateien nahezu kostenlos, während PHP-FPM nur das übernimmt, was Ausführung erfordert.

server {
    listen 80;
    server_name example.com;
    root /var/www/myapp/public;
    index index.php index.html;

    # Serve static files directly, no PHP involvement
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    # Delegate PHP to PHP-FPM
    location ~ .php$ {
        # Security: prevent executing uploaded files as PHP
        try_files $uri =404;
        fastcgi_split_path_info ^(.+.php)(/.+)$;

        fastcgi_pass unix:/run/php/myapp-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
        include fastcgi_params;

        # Performance tuning
        fastcgi_buffers 16 16k;
        fastcgi_buffer_size 32k;
        fastcgi_read_timeout 300;
    }

    # Block access to the FPM status page from public
    location ~ ^/(fpm-status|fpm-ping)$ {
        allow 127.0.0.1;
        deny all;
        fastcgi_pass unix:/run/php/myapp-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
}

Sicherheitshinweis: Die try_files $uri =404;-Zeile vor fastcgi_pass ist nicht optional. Ohne sie leitet NGINX Anfragen für nicht vorhandene Dateien an PHP-FPM weiter, was Path-Traversal-Angriffe ermöglicht, bei denen ein Angreifer ein Bild mit PHP-Code hochlädt und den Server dazu bringt, diesen auszuführen.

PHP-FPM mit Apache integrieren

Apache benötigt mod_proxy_fcgi, um mit PHP-FPM zu kommunizieren. Im Gegensatz zu mod_php ermöglicht dieser Ansatz Apache, PHP-FPM als separaten Benutzer auszuführen, was die Isolation verbessert.

sudo a2enmod proxy_fcgi setenvif
sudo systemctl restart apache2

Virtual-Host-Konfiguration:

<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/myapp/public

    <Directory /var/www/myapp/public>
        Options -Indexes +FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    <FilesMatch ".php$">
        SetHandler "proxy:unix:/run/php/myapp-fpm.sock|fcgi://localhost/"
    </FilesMatch>

    ErrorLog ${APACHE_LOG_DIR}/myapp-error.log
    CustomLog ${APACHE_LOG_DIR}/myapp-access.log combined
</VirtualHost>

Die PHP-FPM-Statusseite aktivieren und verwenden

Die integrierte Statusseite ist eines der am wenigsten genutzten Diagnose-Tools von PHP-FPM. Sobald pm.status_path in der Pool-Datei konfiguriert ist, können Sie sie direkt abfragen:

sudo -u www-data SCRIPT_NAME=/fpm-status SCRIPT_FILENAME=/fpm-status REQUEST_METHOD=GET cgi-fcgi -bind -connect /run/php/myapp-fpm.sock

Oder praktischer über curl, nachdem sie auf einem eingeschränkten internen Endpunkt verfügbar gemacht wurde:

curl http://127.0.0.1/fpm-status?full

Wichtige zu überwachende Metriken:

• listen queue: Anfragen, die auf einen freien Worker warten. Jeder Wert über 0 unter anhaltender Last bedeutet, dass pm.max_children zu niedrig ist.
• active processes: Worker, die derzeit PHP ausführen. Wenn dieser Wert dauerhaft pm.max_children entspricht, sind Sie an der Kapazitätsgrenze.
• slow requests: Kumulativer Zähler der Anfragen, die request_slowlog_timeout überschritten haben. Ein steigender Wert weist auf Engpässe auf Anwendungsebene hin.

Das Slow Log zur Performance-Fehlersuche verwenden

Das Slow Log erfasst einen vollständigen PHP-Stack-Trace für jede Anfrage, die den konfigurierten Schwellenwert überschreitet. Dies ist unschätzbar wertvoll, um N+1-Query-Probleme, blockierende I/O-Aufrufe oder ineffiziente Schleifen zu identifizieren, ohne einen vollständigen Profiler zu benötigen.

slowlog = /var/log/php-fpm/myapp-slow.log
request_slowlog_timeout = 2s

Ein Slow-Log-Eintrag sieht so aus:

[21-Jun-2025 14:32:11]  [pool myapp] pid 18432
script_filename = /var/www/myapp/public/index.php
[0x00007f3b4c001e80] PDOStatement->execute() /var/www/myapp/vendor/laravel/framework/src/Illuminate/Database/Connection.php:338
[0x00007f3b4c001d40] runQueryCallback() /var/www/myapp/vendor/laravel/framework/src/Illuminate/Database/Connection.php:295

Dies zeigt Ihnen sofort, dass der Engpass eine Datenbankabfrage ist und nicht die PHP-Logik – und lenkt Ihre Optimierungsbemühungen gezielt in die richtige Richtung.

PHP-FPM mit OPcache: Die unverzichtbare Kombination

PHP-FPM allein übernimmt die Prozessverwaltung; OPcache eliminiert die Kosten für das Parsen und Kompilieren von PHP-Quelldateien bei jeder Anfrage. Zusammen bilden sie den vollständigen Performance-Stack für PHP unter Linux.

OPcache in /etc/php/8.2/fpm/php.ini oder einer dedizierten /etc/php/8.2/fpm/conf.d/10-opcache.ini-Datei aktivieren und optimieren:

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.revalidate_freq=0
opcache.validate_timestamps=0
opcache.jit_buffer_size=128M
opcache.jit=tracing

Das Setzen von validate_timestamps=0 deaktiviert die Überprüfung auf Dateiänderungen bei jeder Anfrage – ein erheblicher Performance-Gewinn in der Produktion. Wenn Sie neuen Code deployen, lösen Sie einen Cache-Reset explizit aus:

sudo systemctl reload php8.2-fpm

Auf einem VPS mit cPanel sind OPcache-Einstellungen oft in der PHP-Konfigurationsoberfläche zugänglich, aber die manuelle Optimierung über .ini-Dateien bietet immer eine feinere Kontrolle.

Sicherheitshärtung für PHP-FPM

Jeden Pool als dedizierten Systembenutzer ausführen

Führen Sie PHP-FPM-Pools niemals als root oder als gemeinsam genutzter www-data-Benutzer über mehrere Anwendungen hinweg aus. Erstellen Sie einen dedizierten Systembenutzer pro Anwendung:

sudo useradd --system --no-create-home --shell /usr/sbin/nologin myapp

Setzen Sie dann user = myapp und group = myapp in der Pool-Konfiguration. Dies stellt sicher, dass eine kompromittierte PHP-Anwendung keine Dateien anderer Anwendungen auf demselben Server lesen kann.

PHP-Funktionen einschränken

Deaktivieren Sie im php_admin_value-Block des Pools Funktionen, die in Webanwendungen keinen legitimen Verwendungszweck haben:

php_admin_value[disable_functions] = exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source

Open Basedir einschränken

Beschränken Sie den Dateizugriff von PHP auf das Anwendungsverzeichnis:

php_admin_value[open_basedir] = /var/www/myapp:/tmp

Unix-Sockets mit strikten Berechtigungen verwenden

TCP-Sockets (127.0.0.1:9000) sind für jeden Prozess auf dem Server zugänglich. Unix-Sockets mit listen.mode = 0660 beschränken den Zugriff ausschließlich auf den besitzenden Benutzer und die Gruppe.

Den gesamten Stack überprüfen

Nach der Konfiguration von PHP-FPM und Ihrem Webserver überprüfen Sie die gesamte Kette, bevor Sie live gehen.

Alle Dienste neu laden:

sudo systemctl reload php8.2-fpm
sudo systemctl reload nginx
# or
sudo systemctl reload apache2

NGINX-Konfigurationssyntax vor dem Neuladen testen:

sudo nginx -t

Eine temporäre Info-Datei erstellen (nach der Überprüfung entfernen – sie gibt sensible Serverdaten preis):

echo "<?php phpinfo();" | sudo tee /var/www/myapp/public/phpinfo.php

Öffnen Sie http://example.com/phpinfo.php in einem Browser und bestätigen Sie:

• Server API zeigt FPM/FastCGI
• PHP Version entspricht der installierten Version
• Der OPcache-Abschnitt ist vorhanden und aktiviert

Entfernen Sie die Datei dann sofort:

sudo rm /var/www/myapp/public/phpinfo.php

PHP-FPM in Multi-Anwendungs- und Hochlast-Umgebungen

Auf einem Dedicated Server, der Dutzende von PHP-Anwendungen hostet, wird die Multi-Pool-Architektur unverzichtbar. Jede Anwendung erhält ihren eigenen Pool mit unabhängig optimierten pm.max_children-Werten, Speicherlimits und Slow-Log-Pfaden. Eine fehlerhafte Anwendung, die ihren Worker-Pool erschöpft, beeinträchtigt andere Anwendungen nicht.

Für Hochlast-Szenarien kombinieren Sie PHP-FPM mit:

• NGINX FastCGI-Caching (fastcgi_cache), um gecachte PHP-Antworten als statische Dateien auszuliefern und PHP-FPM bei wiederholten Anfragen vollständig zu umgehen
• Redis oder Memcached für PHP-Session-Speicherung, als Ersatz für die standardmäßigen dateibasierten Sessions, die unter Last I/O-Konflikte verursachen
• Horizontale Skalierung durch den Betrieb von PHP-FPM auf Anwendungsservern hinter einem Load Balancer, mit NGINX auf einem separaten Frontend-Knoten

Wenn Ihr Stack SSL-Terminierung umfasst, stellt die Kombination von PHP-FPM mit ordnungsgemäß konfigurierten SSL-Zertifikaten auf der NGINX-Ebene sicher, dass TLS-Handshakes verarbeitet werden, bevor Anfragen PHP-FPM erreichen, sodass sich die PHP-Worker ausschließlich auf die Anwendungslogik konzentrieren können.

Für rechenintensive PHP-Workloads – Machine-Learning-Inferenz über PHP-Bindings, Bildverarbeitung oder Video-Transcoding – sollten Sie GPU-Hosting in Betracht ziehen, bei dem PHP-FPM schwere Berechnungen an GPU-beschleunigte Bibliotheken delegieren kann, während die standardmäßige Anfrageverarbeitung für die Web-Schicht erhalten bleibt.

Wichtige Entscheidungsmatrix und technische Checkliste

Bevor Sie PHP-FPM in der Produktion einsetzen, überprüfen Sie jeden Punkt auf dieser Checkliste:

Auswahl des Process Managers

• Verwenden Sie pm = dynamic für allgemeine VPS-Workloads
• Verwenden Sie pm = static nur auf dedizierten Servern mit vorhersehbarem, anhaltendem Traffic
• Verwenden Sie pm = ondemand nur für Pools mit geringem Traffic oder Entwicklungs-Pools

Kapazitätsplanung

• Messen Sie den tatsächlichen Worker-Speicher mit ps, bevor Sie pm.max_children festlegen
• Reservieren Sie mindestens 20 % des gesamten RAM für OS, Webserver und Datenbank
• Setzen Sie pm.max_requests zwischen 500–1000, um die Anhäufung von Speicherlecks zu verhindern

Sicherheit

• Jeder Anwendungs-Pool läuft unter seinem eigenen Systembenutzer
• clear_env = yes ist in jedem Pool gesetzt
• open_basedir beschränkt den Dateizugriff auf das Anwendungsverzeichnis
• disable_functions blockiert Shell-Ausführungsfunktionen
• Unix-Sockets werden anstelle von TCP-Sockets verwendet

Beobachtbarkeit

• pm.status_path ist konfiguriert und nur von localhost aus zugänglich
• slowlog ist mit einem request_slowlog_timeout-Wert von 2–5 Sekunden aktiviert
• Log-Rotation ist für alle PHP-FPM-Log-Dateien konfiguriert

Performance

• OPcache ist mit validate_timestamps=0 in der Produktion aktiviert
• NGINX FastCGI-Caching ist für cachefähige Endpunkte konfiguriert
• Der PHP-Session-Handler ist auf Redis oder Memcached gesetzt, nicht auf Dateien

Betrieb

• sudo systemctl reload php8.2-fpm wird für Konfigurationsänderungen ohne Ausfallzeit verwendet (nicht restart)
• phpinfo.php wird unmittelbar nach der Überprüfung aus dem Document Root entfernt
• Die Pool-Konfiguration wird zusammen mit dem Anwendungscode versioniert

FAQ

Was ist der Unterschied zwischen PHP-FPM und mod_php?

mod_php bettet den PHP-Interpreter in jeden Apache-Worker-Prozess ein, verbraucht Speicher auch bei der Auslieferung statischer Dateien und koppelt PHP eng an Apache. PHP-FPM läuft als vollständig separater Dienst, kommuniziert über FastCGI, funktioniert mit jedem Webserver einschließlich NGINX und ermöglicht eine prozessbezogene Isolation pro Anwendung mit unabhängigen Ressourcenlimits.

Wie wähle ich zwischen einem Unix-Socket und einem TCP-Socket für PHP-FPM?

Verwenden Sie einen Unix-Socket (listen = /run/php/app-fpm.sock), wenn PHP-FPM und der Webserver auf derselben physischen oder virtuellen Maschine laufen. Unix-Sockets umgehen den TCP/IP-Stack, reduzieren die Latenz und eliminieren Port-Konflikte. Verwenden Sie einen TCP-Socket (listen = 127.0.0.1:9000) nur, wenn PHP-FPM auf einem anderen Host als der Webserver läuft.

Warum erhalte ich unter Last 502 Bad Gateway-Fehler?

Ein 502-Fehler von NGINX, der auf PHP-FPM verweist, bedeutet fast immer, dass die Listen-Queue voll ist – alle Worker sind beschäftigt und neue Verbindungen werden abgelehnt. Überprüfen Sie pm.status_path auf einen listen queue-Wert ungleich null. Die Lösung besteht entweder darin, pm.max_children zu erhöhen (wenn RAM es erlaubt) oder langsame PHP-Skripte zu optimieren, die über das Slow Log identifiziert wurden.

Wie lade ich PHP-FPM neu, ohne aktive Verbindungen zu unterbrechen?

Verwenden Sie sudo systemctl reload php8.2-fpm anstelle von restart. Das reload-Signal (SIGUSR2) veranlasst den Master-Prozess, Worker graceful neu zu starten: Bestehende Anfragen werden normal abgeschlossen, während neue Worker die aktualisierte Konfiguration übernehmen. Ein hartes restart beendet alle Worker sofort und bricht laufende Anfragen ab.

Kann PHP-FPM mehrere PHP-Versionen gleichzeitig auf einem Server betreiben?

Ja. Installieren Sie mehrere PHP-Versionen (z. B. php7.4-fpm und php8.2-fpm) und konfigurieren Sie jeden Anwendungs-Pool so, dass er den entsprechenden Socket-Pfad verwendet. Verweisen Sie in NGINX fastcgi_pass pro Server-Block auf den korrekten Socket. Dies ist ein Standardmuster auf gemeinsam genutzter Infrastruktur, die über VPS Control Panels verwaltet wird, und wird auf VPS-Hosting mit Root-Zugriff vollständig unterstützt.