Zum Inhalt springen 
Ich zeige dir, wie du WordPress PHP-FPM so einstellst, dass Seitenaufrufe auch bei Last schnell bleiben und der Server ruhig läuft. Dafür gehe ich konkreten Parametern wie pm.max_children, OPcache, Sockets und Timeouts auf den Grund und liefere klare, belastbare Startwerte.
Zentrale Punkte
- pm.max_children realistisch zum RAM berechnen
- Dynamic als Modus für die meisten Sites
- OPcache aktivieren und dimensionieren
- Sockets statt TCP für Nginx/Apache
- Monitoring für Feintuning nutzen
Warum PHP-FPM bei WordPress zählt
Ich setze auf PHP-FPM, weil der FastCGI Process Manager Anfragen parallel mit Worker-Prozessen bedient und damit Wartezeit spürbar senkt; das macht dynamische WordPress-Seiten deutlich reaktionsfreudiger. Gegenüber alten Handlern hält FPM die CPU- und RAM-Last im Griff, was besonders bei Peaks mit vielen gleichzeitigen Requests wichtig ist und Ausfälle vermeidet. Plugins und Themes fordern Speicher, daher braucht jedes Child einen gewissen Puffer, den ich kalkuliert festlege und laufend prüfe. Mit kluger Pool-Konfiguration arbeite ich Schwankungen ab, ohne Leerlauf zu produzieren oder den Server zu überziehen. Wer hier sauber ansetzt, reduziert Antwortzeiten, erhöht die Zuverlässigkeit und hält die Ladezeit konstant niedrig.
Dateien, Pools und sinnvolle Struktur
Die FPM-Pool-Konfiguration liegt meist unter /etc/php/[version]/fpm/pool.d/ oder /etc/php-fpm.d/, und ich prüfe den genauen Pfad über php -i, um nicht an der falschen Datei zu drehen. Für jede Site nutze ich einen eigenen Pool, weil isolierte Prozesse Fehlersuche vereinfachen und Last sauber trennen. In der www.conf oder einer projektspezifischen pool.conf definiere ich Nutzer, Socket-Pfad, Prozess-Manager und alle Grenzwerte. Sockets benenne ich eindeutig, etwa /run/php/siteA.sock, damit Nginx gezielt auf den Pool zeigt und ich keine Vermischung riskiere. Diese klare Trennung sorgt für konsistente Ressourcen-Zuweisung und stabile Deployments.
Sicherheit, Rechte und saubere Pool-Isolation
Ich setze pro Pool user und group passend zum Webroot (z. B. www-data), damit Dateirechte konsistent bleiben und der Webserver den Socket nutzen darf. Für Unix-Sockets wähle ich listen.owner, listen.group und listen.mode (0660), sodass Nginx/Apache zuverlässig zugreifen. Mit clear_env=no erlaube ich notwendige Umgebungsvariablen (z. B. für externe Services), ohne die Sicherheit zu lockern. security.limit_extensions begrenze ich auf .php, um versehentliche Ausführungen anderer Dateien zu verhindern. Optional setze ich chdir auf den Document-Root des Projekts; chroot ist möglich, erfordert aber einen höheren Betriebsaufwand und passt nicht zu jeder Umgebung.
Prozess-Manager-Modi richtig wählen
Für die meisten Installationen nutze ich den Modus dynamic, weil er Lastspitzen flexibel abfängt und bei Ruhezeiten Ressourcen spart. Im Modus static bleibt die Prozesszahl unverändert, was bei extrem gleichmäßiger Hochlast sinnvoll sein kann, aber RAM fest bindet. Ondemand startet Prozesse erst bei Bedarf, was auf sehr kleinen Instanzen nützlich ist, jedoch Kaltstart-Verzögerungen bringt. Die Wahl hängt vom Traffic-Profil ab: schwankender Traffic profitiert von dynamic, konstante Peaks spielen mit static, Low-Traffic-Setups fahren oft mit ondemand besser. Ich setze die Entscheidung immer in Verbindung mit realen Messwerten, denn nur Daten zeigen, ob ein Modus die Last wirklich trägt.
| Modus | Einsatz | Vorteil | Hinweis |
|---|---|---|---|
| dynamic | Schwankender Traffic | Flexibel, gute Reaktionszeit | Solide Startwerte genügen für den Anfang |
| static | Sehr konstante Hochlast | Vorhersehbare RAM-Nutzung | RAM muss sicher reichen |
| ondemand | Geringe Grundlast | Sparsam bei Leerlauf | Kaltstarts bedenken |
CPU-Kerne, I/O und die richtige Parallelität
Ich beachte die Balance aus CPU-Kernen und blockierenden Operationen. WordPress-Requests warten oft auf I/O (Datenbank, Filesystem, externe APIs), daher kann die Anzahl der Kinder die Zahl der Kerne übersteigen. Bei stark CPU-lastigen Setups (Bildverarbeitung, Reports) bleibe ich näher an 1–2x Kerne, bei I/O-lastigen Sites funktionieren 2–4x Kerne, so lange RAM und Timeouts sauber gesetzt sind. Ich teste unter Last, ob die CPU dauerhaft bei 100 % klebt (zu viele Prozesse) oder trotz hoher Wartezeit unterfordert ist (I/O-Engpass, fehlender Cache).
pm.max_children berechnen: so gehe ich vor
Ich starte mit dem RAM des Servers, dem realen Verbrauch pro PHP-Prozess und einem Puffer für Datenbank und Webserver, damit nichts an die Decke geht; so landen sinnvolle Grenzwerte auf Anhieb stabil. Beispiel: 4 GB RAM, 1 GB Puffer für MySQL/Nginx/Cache und Ø 100 MB je PHP-Prozess ergibt 30–35 Kinder, nicht 40, weil ich Reserven einkalkuliere. Wer viele speicherhungrige Plugins nutzt, plant 120–150 MB pro Prozess ein und testet, ob das Profil passt. Für Peaks orientiere ich mich an gleichzeitigen Anfragen: Bei etwa 50 parallelen Visits reichen oft 15–25 Kinder, wenn Caching und OPcache sauber arbeiten. Eine ausführliche Herleitung findest du hier: pm.max_children optimieren, und ich übernehme daraus die Logik, nicht blind die Zahlen.
Start-, Spare- und Requests-Parameter wählen
Für dynamic setze ich oft pm.start_servers auf 10, pm.min_spare_servers auf 5 und pm.max_spare_servers auf 20, weil damit Anlaufphase und Leerlauf gut ausbalanciert sind und die Antwortzeit konstant bleibt. pm.max_requests mit 300–800 verhindert, dass Memory-Leaks Prozesse aufblähen; 500 ist ein solider Startwert. Ich erhöhe pm.max_spare_servers, falls wartende Requests auftreten und die Queue wächst. Bei zu vielen Leerlauf-Prozessen senke ich die Spare-Werte, damit RAM frei bleibt. Nach jeder Änderung beobachte ich CPU, RAM, Request-Queue und Fehler-Logs, sonst bleibt das Tuning eine Vermutung statt einer klaren Entscheidung.
Timeouts, Version und Memory-Limit
Ich setze request_terminate_timeout meist auf 60–120 Sekunden, damit hängende Skripte beendet werden und der Pool frei bleibt; alles darüber kaschiert nur Fehler im Code oder in Integrationen. Die PHP-Version halte ich modern, also 8.1 oder 8.2, denn neue Versionen liefern spürbare Performance-Gewinne und bessere Typ-Sicherheit. Das memory_limit liegt häufig bei 256M oder 512M, abhängig von Plugin-Landschaft und Bildverarbeitung. Wer viele hohe Auflösungen verarbeitet, kalkuliert Reserven, testet Uploads und beobachtet die Logs. Am Ende zählt, ob die Kombination aus Limit, Requests und OPcache ohne Ausreißer läuft und keine Out-of-Memory-Fehler wirft.
OPcache: der CPU-Turbo für WordPress
OPcache spare ich nie aus, weil es kompilierten PHP-Bytecode im RAM hält und damit CPU-Zeit massiv einspart; das entlastet die Worker und macht jede Seite schneller. In der Produktion deaktiviere ich Timestamp-Checks und verteile genug Speicher auf den Cache, damit nicht ständig verdrängt wird. Für mittelgroße Sites genügen oft 128–192 MB, größere Installationen profitieren von 256 MB und mehr. Die Trefferquote beobachte ich mit einem OPcache-Status-Skript, sonst bleibt unklar, ob der Cache groß genug ist. Beispielwerte, die sich bewährt haben, siehst du hier:
opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=10000
opcache.validate_timestamps=0
opcache.revalidate_freq=0
Für WordPress schalte ich den JIT in der Regel ab, weil die Workloads selten profitieren, aber zusätzlicher Speicher gebunden würde. Nach Deployments wärme ich den Cache mit den wichtigsten Routen oder WP-CLI-Kommandos an, damit die ersten Nutzer keine Kompilier-Überhänge spüren.
Nginx/Apache: Socket statt TCP und die Handler-Wahl
Zwischen Webserver und FPM nutze ich Unix-Sockets, weil der lokale Socket-Aufruf weniger Overhead hat als TCP und damit etwas Latenz spart; das zahlt direkt auf die Performance ein. In Nginx sieht das etwa so aus: fastcgi_pass unix:/run/php/wordpress.sock;. Bei Apache mit Proxy-FastCGI funktioniert der Socket ebenso, solange die Rechte stimmen. Zusätzlich prüfe ich den aktiven PHP-Handler und wähle FPM gegenüber alten Varianten. Wer die Unterschiede genauer verstehen will, klickt sich durch diese Übersicht: PHP-Handler vergleichen, um Fehlannahmen rund um mod_php, FPM und Proxy-Varianten zu vermeiden.
Webserver-Parameter passend zum FPM-Pool
Ich passe Nginx/Apache-Timeouts an die FPM-Werte an, damit kein Layer zu früh abbricht. fastcgi_read_timeout orientiere ich an request_terminate_timeout (z. B. 120s), fastcgi_connect_timeout halte ich kurz (1–5s). Ausreichende fastcgi_buffers verhindern 502/504 bei großen Responses. Keep-Alive und Worker-Limits setze ich realistisch: Viele sehr lange Keep-Alive-Verbindungen blockieren sonst Slots, die PHP-Backends brauchen. Unter Apache nutze ich Event-MPM, limitiere MaxRequestWorkers passend zum RAM und stelle sicher, dass FPM mehr Kinder bereitstellen kann, als der Webserver parallel in den Backend-Handler schickt – sonst staunen Frontend-Clients in der Queue.
Monitoring und FPM-Status zielgerichtet nutzen
Ich messe kontinuierlich, sonst bleibt Tuning reines Bauchgefühl und trifft die eigentliche Ursache oft nicht. htop/top zeigen auf einen Blick, ob RAM eng wird, ob Prozesse thrashen oder ob CPU-Kerne sauber ausgelastet sind. Die PHP-FPM-Statusseite verrät Queue-Länge, aktive und wartende Prozesse sowie durchschnittliche Bearbeitungszeit pro Request. Wachsen Queue und Wartezeit, fehlen meist Prozesse oder Caching arbeitet nicht. Wer sich tiefer mit parallelen Prozessen beschäftigt, findet hier einen guten Startpunkt: PHP-Worker Flaschenhals, denn die Zahl der Worker begrenzt letztlich die gleichzeitigen PHP-Requests pro Instanz.
Slowlog, Backlog und stabile Fehlerdiagnose
Um Ausreißer zu finden, aktiviere ich den Slowlog pro Pool und setze request_slowlog_timeout auf 3–5 Sekunden. So sehe ich, welche Skripte hängen und ob externe Aufrufe bremsen. Mit catch_workers_output landen Notices/Warnings pro Prozess im Pool-Log, was die Ursachenforschung beschleunigt. Zusätzlich stelle ich den Socket-listen.backlog hoch (z. B. 512–1024), damit kurze Peaks nicht direkt zu 502 führen; das korreliere ich mit dem Kernel-Backlog (somaxconn), damit die Warteschlange nicht am OS scheitert. Wenn Logs häufig “server reached pm.max_children” oder “pool seems busy” zeigen, ist entweder die Parallelität zu niedrig oder die eigentliche Ursache liegt bei Datenbank/externen Diensten.
Häufige Stolpersteine und schnelle Abhilfe
Viele Probleme wiederholen sich in ähnlichen Mustern, daher halte ich typische Symptome, Ursachen und Gegenmaßnahmen stets bereit, damit ich nicht jedes Mal bei Null anfange und wertvolle Zeit verliere. Hohe Antwortzeit, 502-Fehler oder Speicherfehler weisen meist auf falsch gesetzte Prozesszahlen, fehlerhafte Spare-Werte oder ausufernde Skripte hin. In der Praxis hilft es, nur eine Variable pro Runde zu ändern und die Metriken danach zu prüfen. Wer OPcache vergisst oder Max-Requests auf unendlich stellt, bezahlt oft mit schleichenden Memory-Leaks. Die folgende Tabelle komprimiert die häufigsten Fälle:
| Problem | Ursache | Lösung |
|---|---|---|
| Hohe Antwortzeit | Zu wenige max_children | pm.max_children neu berechnen und erhöhen |
| 502 Bad Gateway | Pool ausgelastet oder zu enge Spare-Werte | pm.max_spare_servers erhöhen und Logs prüfen |
| Allowed memory size exhausted | Leaky Skripte oder zu geringes memory_limit | pm.max_requests senken, OPcache prüfen, Limits anheben |
| Langsamer Kaltstart | ondemand bei Spitzenlast | Auf dynamic wechseln und Start-/Spare-Werte erhöhen |
WordPress-spezifische Lasttreiber entschärfen
Ich prüfe typische Hotspots: admin-ajax.php, wp-json und Heartbeat-Routen. Stark frequentierte AJAX- oder REST-Endpunkte können den Pool binden, wenn Caching greift, aber diese Routen durchlassen muss. Hier helfen kürzere Timeouts, saubere Objekt-Caches und eine Priorisierung: Optional führe ich für /wp-admin/ und /wp-login.php einen eigenen Pool mit kleinerer Kinderzahl, damit der öffentliche Pool auch bei Redaktionsspitzen performant bleibt. wp-cron entkopple ich von Besucher-Traffic (echter System-Cron), damit langlaufende Tasks nicht zufällig auf Nutzerzugriffe fallen. Mit einem persistenten Objekt-Cache (Redis/Memcached) sinkt die DB-Last signifikant; dadurch lassen sich pm.max_children oft niedriger ansetzen, ohne Performance zu verlieren.
High-Traffic-Setup: Caching, Datenbank und Server-Tuning
Bei viel Traffic kombiniere ich FPM-Tuning mit aggressivem Page-Cache, damit nur ein Bruchteil der Requests PHP erreicht und die Antwortzeit planbar bleibt. Ein Reverse-Proxy-Cache oder ein solides WordPress-Cache-Plugin reduziert dynamische Hits oft drastisch. Gzip bzw. Brotli auf dem Webserver spart Bandbreite und senkt Time-to-First-Byte bei wiederkehrenden Ressourcen. Die Datenbank halte ich schlank: Autoload-Optionen im Auge behalten, Transients aufräumen und Query-Monitoring betreiben. Mit diesen Bausteinen steigt die effektive Kapazität pro Instanz deutlich, ohne die Hardware zu wechseln.
Backpressure steuern und Überlast vermeiden
Ich definiere bewusst, wo Anfragen warten: Lieber in der Webserver-Queue als im FPM-Pool. Dazu halte ich den listen.backlog moderat und limitiere Webserver-Worker so, dass sie den Pool nicht unkontrolliert fluten. Ein zu großes Backlog versteckt Engpässe und erhöht Latenzspitzen. Ein zu kleines führt zu 502-Fehlern. Die „richtige“ Größe erkenne ich im Status: wenn die Listen-Queue in FPM selten Spitzen sieht und die Response-Zeiten trotzdem stabil bleiben, passt die Balance.
Deployments, Reloads und Null-Downtime
Ich bevorzuge Reloads statt harter Restarts, damit laufende Requests sauber fertig werden. In FPM steuere ich das mit process_control_timeout, sodass Kinder Zeit für einen geordneten Shutdown haben. Nach Code-Deploys leere ich nicht blind den OPcache, sondern wärme gezielt an oder akzeptiere eine kurze Mischphase mit validate_timestamps=1 bei Blue/Green-Strategien. Wichtig: Der Webserver sollte ein graceful reload unterstützen, sonst riskierst du kurze 502-Fenster, obwohl der Pool korrekt weiterarbeitet.
Erweiterte Hinweise für Virtualisierung und Multi-Sites
Auf Virtual- oder Container-Hosts beachte ich, dass gemessene RAM-Größen und CFS-Quotas die effektive Leistung begrenzen, weshalb ich pm.max_children nie bis zum rechnerischen Limit hochziehe. Multi-Site-Umgebungen trenne ich per Pool, damit ein heißes Projekt die anderen nicht bremst. Für stark schwankenden Traffic ist Auto-Scaling mit mehreren kleinen Instanzen oft besser als eine große Maschine. Shared-NFS oder Remote-Storage verlängern Dateizugriffe; OPcache und lokale Uploads puffern vieles davon. Damit bleibt die Plattform kalkulierbar, selbst wenn einzelne Sites ausreißen.
Konkrete Kennzahlen lesen und richtig deuten
Ich betrachte im FPM-Status vor allem die laufenden, wartenden und gesamten Prozesse, weil diese drei Zahlen den Zustand des Pools schnell zusammenfassen. Eine dauerhaft wachsende Warteschlange signalisiert Unterversorgung oder fehlenden Cache-Treffer. Steht die CPU still, obwohl Requests warten, blockieren oft I/O oder externe Dienste; hier helfen Profiling und Zeitouts. Wenn Prozesse ständig neu starten, liegt pm.max_requests zu tief oder ein Plugin leakt Speicher. Solche Muster erkenne ich wieder, verifiziere sie mit Logs und ziehe erst dann an den relevanten Parametern.
Weitere Praxiswerte, die ich im Blick behalte
Ich werte „max children reached“-Zähler, durchschnittliche Bearbeitungszeit pro Request und die maximale Listen-Queue aus. Wenn der Anteil „idle“ im FPM-Status dauerhaft sehr hoch ist, verschwende ich RAM – dann reduziere ich Spare-Werte oder Kinderzahl. Häufen sich „slow requests“, greife ich zuerst zu Slowlog-Analyse und prüfe DB-Queries, externe APIs und Bildverarbeitung. In Nginx/Apache beobachte ich offene Verbindungen, Keep-Alive-Dauer und Fehler-Codes; 499/408 deuten auf Clientabbrüche (Langsam-Netze, Mobile), 504 eher auf zu knappe Backend-Timeouts.
Kurz und knapp: die Essenz für schnelle WordPress-PHP-FPM-Setups
Ich rechne pm.max_children konservativ aus, nutze dynamic, setze Start-/Spare-Werte sinnvoll und halte OPcache groß genug, damit Code im Cache bleibt. Sockets statt TCP mindern Latenz, Timeouts räumen Hänger weg und moderne PHP-Versionen schieben die Performance nach vorn. Monitoring liefert die Wahrheit über Warteschlangen, Arbeitsspeicher und Reaktionszeit; jede Änderung messe ich gegen. Mit Cache vor PHP, einer gesunden Datenbank und solider FPM-Konfiguration bleibt die Site schnell und verlässlich. Wer dieses Vorgehen konsequent anwendet, holt aus WordPress PHP-FPM dauerhaft das Maximum heraus.
