{"id":17996,"date":"2026-03-02T08:37:07","date_gmt":"2026-03-02T07:37:07","guid":{"rendered":"https:\/\/webhosting.de\/php-fpm-modi-vergleich-static-dynamic-ondemand-optimierungstuning\/"},"modified":"2026-03-02T08:37:07","modified_gmt":"2026-03-02T07:37:07","slug":"php-fpm-modes-comparaison-static-dynamic-ondemand-optimisation-tuning","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/php-fpm-modi-vergleich-static-dynamic-ondemand-optimierungstuning\/","title":{"rendered":"Comparaison des modes PHP-FPM : Static, Dynamic et Ondemand"},"content":{"rendered":"<p>Dieser Beitrag vergleicht die PHP-FPM Modi <strong>static<\/strong>, <strong>dynamic<\/strong> und <strong>ondemand<\/strong> und zeigt, wie sie Prozesse starten, RAM binden und Latenz beeinflussen. Ich erkl\u00e4re praxisnah, wann welcher Modus \u00fcberzeugt, liefere sinnvolle Startwerte, nenne typische Stolpersteine und zeige Monitoring-Tricks, damit du deine <strong>PHP<\/strong>-Pools sicher einstellst.<\/p>\n\n<h2>Zentrale Punkte<\/h2>\n<p>Damit du schnell loslegen kannst, fasse ich die wichtigsten Aussagen kompakt zusammen. Der Fokus liegt auf Prozesssteuerung, RAM-Bedarf, Latenz und Einsatzfeldern. Jede Auswahl hat klare St\u00e4rken, aber auch Grenzen. Mit ein paar Kennzahlen triffst du belastbare Entscheidungen. So gehst du fokussiert ans <strong>Tuning<\/strong> heran und sparst Zeit.<\/p>\n<ul>\n  <li><strong>Static<\/strong>: Feste Prozesszahl, h\u00f6chste Konstanz bei gleichbleibender Last.<\/li>\n  <li><strong>Dynamic<\/strong>: Automatisches Skalieren zwischen Minimal- und Maximalwerten.<\/li>\n  <li><strong>Ondemand<\/strong>: Start bei Bedarf, sparsam im Leerlauf, Kaltstart-Latenz.<\/li>\n  <li><strong>RAM-Planung<\/strong>: Pro Prozess 20\u201350 MB einkalkulieren, OOM vermeiden.<\/li>\n  <li><strong>Monitoring<\/strong>: Status-Page, Logs und htop f\u00fcr fundierte Entscheidungen.<\/li>\n<\/ul>\n\n<h2>Funktionsweise des Process Managers<\/h2>\n<p>Der PHP-FPM Process Manager steuert, wie viele <strong>Worker<\/strong>-Prozesse Anfragen bearbeiten und wann sie entstehen oder enden. Jede Worker-Instanz h\u00e4lt Interpreter, Erweiterungen und Teile des Bytecodes im Speicher, was pro Prozess typischerweise einige <strong>Megabyte<\/strong> bindet. Die drei Modi ver\u00e4ndern Startverhalten, Lebenszyklus und Leerlauf-Verhalten stark. Static h\u00e4lt eine feste Anzahl aktiv, Dynamic balanciert zwischen Unter- und Obergrenzen, Ondemand erzeugt Prozesse erst bei eingehenden Requests. Diese Steuerung wirkt direkt auf <strong>RAM<\/strong>-Profil, Latenz beim Aufdrehen und System-Lastspitzen.<\/p>\n<p>Wichtige Parameter bilden das R\u00fcckgrat deiner Konfiguration: <strong>pm<\/strong> legt den Modus fest, <strong>pm.max_children<\/strong> begrenzt gleichzeitige Worker hart. Bei Dynamic kommen <strong>pm.start_servers<\/strong>, <strong>pm.min_spare_servers<\/strong> und <strong>pm.max_spare_servers<\/strong> hinzu, die die Breite des Puffers steuern. Ondemand setzt auf <strong>pm.process_idle_timeout<\/strong>, um ruhende Prozesse wieder zu beenden. Mit sinnvollen Werten stellst du sicher, dass Lastspitzen nicht zu Engp\u00e4ssen f\u00fchren und die Maschine nicht in Speicherdruck ger\u00e4t.<\/p>\n<p>Ich pr\u00fcfe vorab den Footprint pro Prozess, die durchschnittliche gleichzeitige Last und die Peak-Verteilung \u00fcber den Tag. Aus diesen Gr\u00f6\u00dfen leite ich den H\u00f6chstwert f\u00fcr <strong>pm.max_children<\/strong> ab, multipliziere mit dem gemessenen Prozess-Speicher und lasse Reserve f\u00fcr Webserver, Datenbank, Cache und Kernel. Diese simple Rechnung verhindert Out-of-Memory-Fehler und sorgt f\u00fcr <strong>Stabilit\u00e4t<\/strong> unter Druck. Wer das beherzigt, erspart sich sp\u00e4ter m\u00fchsames Nachsteuern.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/php-fpm-modi-vergleich-7421.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Static-Modus: konstante Leistung f\u00fcr gleichm\u00e4\u00dfige Last<\/h2>\n<p>Der Static-Modus h\u00e4lt eine feste Zahl an PHP-Workern dauerhaft aktiv, was <strong>Start<\/strong>-Overhead eliminiert. Bei konstanten Traffic-Profilen erzielt dieses Setup sehr geringe Latenzschwankungen und eine gleichm\u00e4\u00dfige <strong>CPU<\/strong>-Last. Die Kehrseite: Im Leerlauf bleibt RAM belegt, obwohl keine Anfragen anliegen. Deshalb w\u00e4hle ich Static nur auf Hosts mit reichlich Arbeitsspeicher und kalkulierbarem Anfragevolumen. Auf stark genutzten Shops oder API-Backends liefert Static h\u00e4ufig die sauberste Reaktionskurve.<\/p>\n<p>Entscheidend ist ein realistisch gesetztes <strong>pm.max_children<\/strong>, das sich am Prozess-Footprint orientiert. F\u00fcr die erste Absch\u00e4tzung rechne ich grob 20\u201350 MB pro PHP-Prozess inklusive Erweiterungen und OPcache. Den finalen Wert verifiziere ich mit Lasttests und dem Systemmonitor. Wer die Berechnung vertiefen m\u00f6chte, findet praxisnahe Schritte unter <a href=\"https:\/\/webhosting.de\/php-fpm-prozess-management-pm-max-children-optimieren-core\/\">pm.max_children optimieren<\/a>. So stellst du sicher, dass deine feste Poolgr\u00f6\u00dfe zur Hardware passt.<\/p>\n<pre><code>[www]\npm = static\npm.max_children = 50\npm.max_requests = 500\n<\/code><\/pre>\n<p><strong>Hinweis<\/strong>: Nach \u00c4nderungen starte ich PHP-FPM neu, pr\u00fcfe Logs und beobachte die Auslastung unter realem Traffic. Bleibt noch viel RAM frei, erh\u00f6he ich vorsichtig. Sehe ich steigende Swap-Nutzung oder OOM-Killer-Eintr\u00e4ge, reduziere ich sofort. Diese kleine Routine sch\u00fctzt die <strong>Verf\u00fcgbarkeit<\/strong> zuverl\u00e4ssig.<\/p>\n\n<h2>Dynamic-Modus: flexibel bei schwankender Nachfrage<\/h2>\n<p>Dynamic startet mit wenigen Prozessen und skaliert die <strong>Worker<\/strong>-Zahl je nach Bedarf in die definierte Spannweite. Dadurch sinkt der Leerlauf-Verbrauch bei ruhigen Phasen, w\u00e4hrend kurze Peaks abgefedert werden. Das Verfahren erzeugt etwas Overhead beim Spawnen, punktet aber mit guter <strong>Ressourcen<\/strong>-Effizienz. In gemischten Umgebungen mit Tagesprofilen liefert Dynamic oft den besten Kompromiss. Gerade f\u00fcr viele CMS-Installationen bleibt dieser Modus die erste Wahl.<\/p>\n<p>Ich setze Start-, Minimal- und Maximalwerte so, dass bei typischer Last keine st\u00e4ndigen Spawn-Events auftreten. H\u00e4ufige Logmeldungen wie \u201eseems busy, spawning children\u201c deuten auf zu enge Limits hin. F\u00fcr WordPress-Stacks hilft es, Caching und OPcache sauber einzustellen und dann moderat zu erh\u00f6hen. Eine kompakte Anleitung deckt die wichtigsten Hebel ab: <a href=\"https:\/\/webhosting.de\/wordpress-php-fpm-optimale-einstellungen-performance-serverboost\/\">optimale WordPress-Einstellungen<\/a>. So erreichst du kurze Antwortzeiten, ohne die <strong>RAM<\/strong>-Reserve zu sprengen.<\/p>\n<pre><code>[www]\npm = dynamic\npm.max_children = 50\npm.start_servers = 5\npm.min_spare_servers = 5\npm.max_spare_servers = 35\n<\/code><\/pre>\n<p><strong>Tipp<\/strong>: Beobachte die Idle-Worker und die durchschnittlichen aktiven Prozesse \u00fcber den Tag. Liegt der Mittelwert nahe am oberen Ende, erh\u00f6he moderat. Verharren viele Prozesse im Leerlauf, senke die Spanne. Mit wenigen Iterationen triffst du die <strong>Sweetspot<\/strong>-Einstellung.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/phpfpm_vergleich_7423.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ondemand-Modus: sparsam im Leerlauf, Start bei Anfrage<\/h2>\n<p>Ondemand erzeugt Prozesse erst, wenn eine <strong>Anfrage<\/strong> eintrifft, und beendet sie nach einer Idle-Zeit. Damit sinkt der RAM-Bedarf in ruhigen Phasen auf ein Minimum, was viele kleine Sites auf einer Maschine beg\u00fcnstigt. Bei Kaltstarts f\u00e4llt jedoch zus\u00e4tzliche Latenz an, weil der Worker erst startet und warm wird. F\u00fcr Entwicklungsumgebungen, Cron-Only-Apps und selten aufgerufene Seiten ist diese Logik ein <strong>Gewinn<\/strong>. Bei Dauerlast w\u00fcrde ich Ondemand nicht einsetzen.<\/p>\n<pre><code>[www]\npm = ondemand\npm.max_children = 50\npm.process_idle_timeout = 10s\npm.max_requests = 500\n<\/code><\/pre>\n<p>Die Idle-Zeit steuere ich meist zwischen 10 und 30 Sekunden, je nach Aufrufmuster und Speicherbudget. Eine k\u00fcrzere Frist spart <strong>RAM<\/strong>, erh\u00f6ht aber die Chance auf Kaltstarts. Eine l\u00e4ngere Frist h\u00e4lt Prozesse warm, kostet jedoch Speicher. Ich beobachte daher die Aufruffrequenz, messe die 95. Perzentil-Latenz und passe dann fein an. So bleibt die <strong>Antwortzeit<\/strong> kalkulierbar, ohne das System zu belasten.<\/p>\n\n<h2>Vergleichstabelle: Eigenschaften der drei Modi<\/h2>\n<p>Die folgende \u00dcbersicht stellt typische Eigenschaften gegen\u00fcber. Ich nutze sie als Gespr\u00e4chsgrundlage, bevor ich ins konkrete Sizing gehe. Die Tabelle ersetzt keine Messung unter Real-Last, liefert aber einen strukturierten <strong>Startpunkt<\/strong>. Wer Werte anpasst, sollte immer Speicherprofil und Latenzverteilung im Blick behalten. So bleibst du bei <strong>Peaks<\/strong> handlungsf\u00e4hig und vermeidest Engp\u00e4sse.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Kriterium<\/th>\n      <th>Static<\/th>\n      <th>Dynamic<\/th>\n      <th>Ondemand<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>Prozesse<\/strong><\/td>\n      <td>Fixe Anzahl, dauerhaft aktiv<\/td>\n      <td>Automatisch zwischen Min\/Max<\/td>\n      <td>Start nur bei Bedarf<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>RAM-Nutzung<\/strong><\/td>\n      <td>Konstant hoch<\/td>\n      <td>Variabel (z. B. 200\u2013600 MB)<\/td>\n      <td>Minimal im Leerlauf (z. B. 50\u2013700 MB)<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Performance<\/strong><\/td>\n      <td>Sehr gleichm\u00e4\u00dfig<\/td>\n      <td>Gut und anpassungsf\u00e4hig<\/td>\n      <td>Gut bei Low-Traffic<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Ideal f\u00fcr<\/strong><\/td>\n      <td>Konstante High-Traffic-Profile<\/td>\n      <td>Variable Nachfrage<\/td>\n      <td>Viele ruhende Sites \/ Shared<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Overhead<\/strong><\/td>\n      <td>Gering<\/td>\n      <td>Mittel (Spawn\/Despawn)<\/td>\n      <td>H\u00f6her bei Kaltstarts<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n<p>Die Tabelle hilft, Erwartungen zu kalibrieren und Priorit\u00e4ten klar zu benennen. Brauchst du h\u00f6chste Reaktionskonstanz, gewinnt oft <strong>Static<\/strong>. Z\u00e4hlt Effizienz bei schwankender Last, arbeitet <strong>Dynamic<\/strong> meist angenehmer. Steht Sparsamkeit im Vordergrund, f\u00fchrt kein Weg an <strong>Ondemand<\/strong> vorbei. Messwerte entscheiden am Ende, nicht Annahmen.<\/p>\n\n<h2>Ressourcenkalkulation und Sizing<\/h2>\n<p>Ich sch\u00e4tze zuerst den Memory-Footprint pro <strong>Prozess<\/strong> ab, multipliziere ihn mit der anvisierten Worker-Zahl und addiere 20\u201330 % Reserve. Zus\u00e4tzlich rechne ich Platz f\u00fcr Nginx\/Apache, Datenbank, Redis\/Memcached und den Kernel ein. Diese Summe darf die physische RAM-Kapazit\u00e4t abz\u00fcglich Sicherheitsmarge nicht \u00fcberschreiten. F\u00fcr OPcache plane ich dedizierten Speicher ein, damit Bytecode nicht verdr\u00e4ngt wird. Mit dieser einfachen <strong>Formel<\/strong> halte ich OOM-Risiken gering.<\/p>\n<p>Im n\u00e4chsten Schritt messe ich gleichzeitige Anfragen per Webserver-Status und APM. Die Peak-Konkurrenz um PHP-Worker bestimmt, wie hoch <strong>pm.max_children<\/strong> sein muss. Reicht der RAM nicht aus, erh\u00f6he ich Cache-Hits, senke Query-Zeiten oder verschiebe Arbeit in Queues. Erst wenn diese Hebel greifen, vergr\u00f6\u00dfere ich den Pool. So bleibt die <strong>Effizienz<\/strong> hoch und die Maschine reagiert verl\u00e4sslich.<\/p>\n\n<h2>Monitoring und Fehlersuche<\/h2>\n<p>Gute Entscheidungen basieren auf <strong>Daten<\/strong>. Ich aktiviere die PHP-FPM-Status-Page und lese aktive sowie idle Prozesse, Queue-L\u00e4nge und akzeptierte Verbindungen aus. Erg\u00e4nzend pr\u00fcfe ich Error-Logs auf Spawn-Warnungen und Zeit\u00fcberschreitungen. In htop beobachte ich CPU-Waits, Load und Swap, um Engp\u00e4sse schneller zu finden. Diese Signale machen Tuning-Schritte <strong>nachvollziehbar<\/strong> und vermeiden Blindflug.<\/p>\n<pre><code>&lt;?php\n$status = @file_get_contents('http:\/\/localhost\/status');\n$data = json_decode($status, true);\necho \"Active: \" . $data['active processes'] . \"\\n\";\necho \"Idle: \" . $data['idle processes'] . \"\\n\";\n?&gt;\n<\/code><\/pre>\n<p>APM-Tools zeigen Traces und Engstellen auf Funktions- oder Query-Ebene. Finde ich dort Ausrei\u00dfer, setze ich zuerst bei Caching und I\/O an. Danach pr\u00fcfe ich, ob die Pool-Limits zur tats\u00e4chlichen Parallelit\u00e4t passen. Erst wenn Applikations-Engp\u00e4sse gel\u00f6st sind, lohnt mehr <strong>Kapazit\u00e4t<\/strong> in FPM. Dieser Ablauf spart Zeit und h\u00e4lt die Architektur schlank.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/phpfpm_modivergleich_0432.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>H\u00e4ufige Tuning-Fehler vermeiden<\/h2>\n<p>Ich sehe oft zu hoch gesetzte <strong>max_children<\/strong>-Werte ohne R\u00fccksicht auf den RAM. Das erzeugt unn\u00f6tigen Swap, lange Garbage-Collection-Phasen und am Ende OOM-Killer. Ebenso schaden zu niedrige Limits, weil sie Warteschlangen aufbauen und Antwortzeiten strecken. Auch fehlender OPcache verschenkt CPU-Zeit und vergr\u00f6\u00dfert den Prozess-Footprint. Mit wenigen <strong>Checks<\/strong> vorab bleiben diese Fallen aus dem Weg.<\/p>\n<p>Ein zweiter Klassiker: unpassende Zeitlimits bei Ondemand, die zu vielen Kaltstarts f\u00fchren. Hier hilft ein kurzer A\/B-Versuch mit 10, 20 und 30 Sekunden Idle-Timeout. Bei Dynamic wiederum erzeugen zu kleine Spare-Werte st\u00e4ndiges Spawnen. Logs verraten diese Muster schnell und leiten die n\u00e4chste <strong>Anpassung<\/strong> ein. So bleibt dein Stack reaktionsfreudig.<\/p>\n\n<h2>PHP-FPM im Kontext anderer PHP-Handler<\/h2>\n<p>PHP-FPM steht oft im Vergleich zu alten CGI-Varianten oder modernen Alternativen wie LSAPI. Die Wahl des Handlers beeinflusst Prozessverwaltung, <strong>Ressourcen<\/strong>-Charakteristik und Fehlerisolierung. Wer die Unterschiede versteht, plant Puffer und Limits realistischer. F\u00fcr einen schnellen \u00dcberblick lohnt ein kurzer <a href=\"https:\/\/webhosting.de\/php-handler-vergleich-cgi-fpm-lsapi-hosting-poolmaster\/\">PHP-Handler Vergleich<\/a>. Danach f\u00e4llt die Entscheidung f\u00fcr FPM-Modi deutlich <strong>zielgerichteter<\/strong> aus.<\/p>\n<p>Ich bleibe meist bei FPM, weil es ausgereift ist, sauber loggt und mit Nginx\/Apache gut zusammenspielt. Entscheidend sind nicht nur Benchmarks, sondern auch Betriebsaspekte wie Observability und Failover. Stimmen diese Grundlagen, holst du mehr aus Static, Dynamic oder Ondemand heraus. Jede Option verdient Tests unter echter Last. So gewinnst du Vertrauen in deine <strong>Einstellungen<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/phpfpm_vergleich_7245.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praxisnahe Entscheidungsstrategie<\/h2>\n<p>Ich starte mit Dynamic als <strong>Default<\/strong>, messe Lastprofile und beobachte Spitzen. Finde ich sehr konstante Auslastung, wechsle ich zu Static und stelle die feste Poolgr\u00f6\u00dfe ein. Treffe ich auf selten genutzte Sites, w\u00e4hle ich Ondemand mit angemessenem Idle-Timeout. Parallel optimiere ich OPcache, Object-Cache und Datenbank-Queries, damit FPM weniger Druck abbekommt. Danach feine ich Limits so aus, dass <strong>Warteschlangen<\/strong> gar nicht erst entstehen.<\/p>\n<p>Diese Reihenfolge senkt Risiko und Aufwand. Erst messen, dann Regeln anpassen, schlie\u00dflich Hardware ber\u00fccksichtigen. Jede \u00c4nderung dokumentiere ich kurz mit Zeitpunkt, Werten und Ziel. Das erleichtert sp\u00e4tere Korrekturen und sorgt f\u00fcr saubere <strong>Transparenz<\/strong>. So bleibt der Stack beherrschbar, auch wenn Traffic-Muster sich \u00e4ndern.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/php-fpm-modes-comparison-9834.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Von Kennzahlen zu belastbaren Werten: so rechne ich<\/h2>\n<p>Ich \u00fcbersetze Lastprofile in konkrete Poolgr\u00f6\u00dfen mit einer einfachen Daumenregel: Wie viele Requests treffen pro Sekunde ein und wie lange dauert die Bearbeitung im Mittel bzw. im 95. Perzentil? Als Orientierung nutze ich <strong>Little\u2019s Law<\/strong> in einfacher Form: gleichzeitige Bearbeitungen \u2248 Durchsatz \u00d7 mittlere Bearbeitungszeit. Beispiel: 120 Requests\/s bei 80 ms im Mittel ergeben rund 9,6 gleichzeitige Ausf\u00fchrungen. Ich gebe 30\u201350 % Puffer f\u00fcr Spitzen drauf und pr\u00fcfe, ob die resultierenden <strong>pm.max_children<\/strong> in mein RAM-Budget passen. F\u00fcr harte Peaks beziehe ich zus\u00e4tzlich das 95. Perzentil ein, um Warteschlangen zu vermeiden.<\/p>\n<p>Wichtig ist, den <strong>Charakter<\/strong> der Workloads zu ber\u00fccksichtigen: Bei I\/O-lastigen Apps (viele Remote-Calls, DB-Zugriffe) bringen etwas mehr Worker oft Vorteile, weil Wartezeiten \u00fcberlappt werden. Bei CPU-lastigem Code limitiere ich st\u00e4rker, damit sich die Prozesse nicht gegenseitig ausbremsen und die Run-Queue nicht explodiert.<\/p>\n\n<h2>pm.max_requests: sauberes Recycling gegen Fragmentierung<\/h2>\n<p>Lang laufende PHP-Prozesse k\u00f6nnen durch <strong>Fragmentierung<\/strong> oder Speicher-Leaks wachsen. Mit <strong>pm.max_requests<\/strong> legst du fest, nach wie vielen abgearbeiteten Anfragen ein Worker beendet und frisch gestartet wird. Das h\u00e4lt den Footprint stabil. Ich beginne meist bei 300\u20131000, je nach Erweiterungen und Code-Basis. Beobachte die RSS-\/PSS-Werte der Prozesse: Wenn sie deutlich wachsen, reduziere den Wert. Da der OPcache <strong>geteilt<\/strong> ist, bleibt Bytecode beim Worker-Recycling erhalten; die meisten Apps sp\u00fcren das Recycling deshalb kaum.<\/p>\n<pre><code>[www]\n; gezieltes Recycling ohne zu h\u00e4ufige Neustarts\npm.max_requests = 800\n<\/code><\/pre>\n<p>Wer regelm\u00e4\u00dfig <strong>Deployments<\/strong> ausrollt, profitiert von einem Reload des Pools. Ich nutze bevorzugt einen <em>graceful reload<\/em> \u00fcber den Dienst-Manager (z. B. \u201esystemctl reload php-fpm\u201c), damit laufende Requests sauber enden und neue Worker mit aktualisierter Config starten.<\/p>\n\n<h2>Slowlog und Timeouts: Engstellen gezielt sichtbar machen<\/h2>\n<p>Die meisten Latenzspitzen stecken in wenigen langsamen Requests. Ich aktiviere daher den <strong>Slowlog<\/strong> mit einem moderaten Schwellwert (z. B. 2\u20135 s) und schaue mir Stacktraces an. So finde ich problematische Funktionen, externe Calls oder teure Queries.<\/p>\n<pre><code>[www]\nrequest_slowlog_timeout = 3s\nslowlog = \/var\/log\/php-fpm\/slowlog-www.log\n<\/code><\/pre>\n<p>Passend dazu gleiche ich die <strong>Timeouts<\/strong> des Webservers ab. Ein zu kurzes Upstream-Timeout (Nginx\/Apache) gegen\u00fcber PHPs max_execution_time f\u00fchrt zu 502\/504-Fehlern, obwohl FPM weiterarbeitet. Ich halte die Kette konsistent: Connect-, Read- und Send-Timeouts des Webservers knapp oberhalb der typischen PHP-Request-Dauer, aber unterhalb harter Obergrenzen.<\/p>\n\n<h2>Warteschlange, Backlog und Statuswerte richtig deuten<\/h2>\n<p>Im FPM-Status beachte ich besonders \u201e<strong>listen queue<\/strong>\u201c und \u201e<strong>max listen queue<\/strong>\u201c. Wachsen diese Werte regelm\u00e4\u00dfig, ist der Pool zu klein oder blockiert. Kurzzeitige Peaks sind normal, aber dauerhafte Staus deuten auf Unterdimensionierung hin. In stark burstigen Umgebungen erh\u00f6he ich den Socket-<strong>Backlog<\/strong> moderat, beobachte die Queue und stelle sicher, dass Kernel-Limits (z. B. somaxconn) nicht der Flaschenhals sind.<\/p>\n<p>Zeigt das Monitoring \u201eseems busy, spawning children\u201c sehr h\u00e4ufig, sind die Reserve-Parameter (Dynamic) zu eng. Bei Ondemand ist ein wiederkehrend hoher Anteil an Kaltstarts ein Hinweis, das Idle-Timeout zu verl\u00e4ngern oder tags\u00fcber einen Minimalpuffer zu halten.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/php-fpm-modes-comparison-9834.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Mehrere Pools: Fairness, Isolation und Quoten<\/h2>\n<p>Auf Multi-Tenant- oder <strong>Shared<\/strong>-Hosts trenne ich Anwendungen in eigene Pools mit individuellen Limits. So verhindere ich, dass ein speicherhungriges Projekt andere verdr\u00e4ngt. F\u00fcr kritische Services (z. B. Login-\/API-Endpunkte) plane ich dedizierte Pools mit fester Minimal-Reserve. Eine klare Benennung (\u201ewww-shop\u201c, \u201ewww-api\u201c, \u201ewww-cron\u201c) und getrennte Logs erleichtern Analyse und <strong>Fehler<\/strong>suche.<\/p>\n<p>Achte darauf, dass die Summe aller <strong>pm.max_children<\/strong> \u00fcber alle Pools zur Maschine passt. Zus\u00e4tzlich beziehe ich <strong>Downstream-Limits<\/strong> ein: DB-<em>max_connections<\/em>, Redis\/Memcached-Threading und externe API-Raten. Ein PHP-Pool, der mehr gleichzeitige Queries feuert als die Datenbank verkraftet, erkauft sich nur l\u00e4ngere Warteschlangen.<\/p>\n\n<h2>OPcache-Warmup, Preload und Kaltstarts z\u00e4hmen<\/h2>\n<p>Um <strong>Ondemand<\/strong>-Kaltstarts zu mildern, halte ich OPcache stabil (ausreichend <em>memory_consumption<\/em> und <em>interned_strings_buffer<\/em>) und setze, falls sinnvoll, auf <strong>Preload<\/strong> zentraler Klassen\/Frameworks. Damit steht Bytecode nach dem ersten Hit bereit, und Wiederholungen bleiben warm. Zus\u00e4tzlich helfen ein gr\u00f6\u00dferer realpath-Cache und ein strukturierter Autoloader, um Dateisystem-Lookups zu reduzieren. In summe verk\u00fcrzt das die Anlaufzeit frisch gestarteter Worker deutlich.<\/p>\n\n<h2>Webserver-Interaktion: Nginx\/Apache sauber ankoppeln<\/h2>\n<p>Ich stelle sicher, dass Webserver- und FPM-Einstellungen zusammenpassen: Puffer und <strong>Timeouts<\/strong> m\u00fcssen symmetrisch sein, Keep-Alive darf FPM nicht mit Zombie-Verbindungen blockieren, und der Upstream-Socket (Unix oder TCP) ist konsistent konfiguriert. Viele 502\/504-Fehler gehen auf falsch gesetzte Read-Timeouts oder ersch\u00f6pfte Backlogs zur\u00fcck. Wer FPM per TCP anspricht, sollte die Latenz des Netz-Stacks und das Risiko <strong>halb-offener<\/strong> Verbindungen im Blick behalten; f\u00fcr lokale Deployments bevorzuge ich meist Unix-Sockets.<\/p>\n\n<h2>Container\/VM-Besonderheiten<\/h2>\n<p>In Containern gelten die <strong>cgroup<\/strong>-Limits, nicht zwingend die Host-Werte. Ich dimensioniere Pools explizit f\u00fcr das Container-RAM und teste mit k\u00fcnstlichen Lastspitzen, ob OOM-Killer greifen k\u00f6nnten. Ein zu knapp bemessenes Limit f\u00fchrt zu harten Abbr\u00fcchen. Ebenso ist Swapping in Containern oft unerw\u00fcnscht \u2013 also lieber etwas konservativer bei <strong>pm.max_children<\/strong> planen und Applikations-Caching priorisieren.<\/p>\n\n<h2>CPU- und I\/O-Charakter erkennen<\/h2>\n<p>Ich beurteile mit htop\/iostat, ob Workloads <strong>CPU<\/strong>&#8211; oder I\/O-gebunden sind. Hohe CPU-Auslastung bei niedrigen I\/O-Waits deutet auf Rechenlast hin \u2013 hier limitiere ich die Worker n\u00e4her an der Kernzahl. Hohe I\/O-Waits rechtfertigen mehr Worker, weil Wartezeiten auf Datenbank, Netzwerk oder Filesystem \u00fcberlappt werden. Die Grenze erkennst du daran, dass die Latenz trotz zus\u00e4tzlicher Worker nicht mehr sinkt, aber die Load deutlich steigt.<\/p>\n\n<h2>Typische 502\/504-Muster schnell entschl\u00fcsseln<\/h2>\n<ul>\n  <li>504 Gateway Timeout: Webserver-Timeout kleiner als PHP-Ausf\u00fchrungszeit oder blockierter Pool (Queue voll).<\/li>\n  <li>502 Bad Gateway: FPM nicht erreichbar (Socket\/Port), Crash\/Restart w\u00e4hrend der Anfrage oder zu kleine Puffer.<\/li>\n  <li>Spikes kurz nach Deploy: OPcache kalt, Autoloader\/Composer-Optimierungen pr\u00fcfen, Warmup einplanen.<\/li>\n<\/ul>\n<p>Ich korreliere Webserver-Errorlog, FPM-Errorlog und Status-Seite im gleichen Zeitfenster. Das zeigt, ob das Problem vor, in oder <strong>nach<\/strong> FPM liegt.<\/p>\n\n<h2>Messhandwerk: Speicherkosten korrekt erfassen<\/h2>\n<p>F\u00fcr die RAM-Planung schaue ich nicht nur auf RSS, sondern auf den <strong>PSS<\/strong> (Proportional Set Size), weil er geteilte Seiten (z. B. OPcache) fair auf Prozesse verteilt. Werkzeuge wie <em>smem<\/em> oder pmap helfen, realistische prozessbezogene Werte zu ermitteln. In der Praxis reichen aber oft Stichproben unter Last: mehrere Prozesse markieren, Mittelwert bilden, mit <strong>Reserve<\/strong> multiplizieren \u2013 das trifft die Realit\u00e4t besser als Theoriewerte aus Foren.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/php-fpm-modi-vergleich-5821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Mini-Checkliste f\u00fcr schnelle Iterationen<\/h2>\n<ul>\n  <li>Lastprofil erfassen (RPS, 50\/95\/99-Perzentile, Parallelit\u00e4t).<\/li>\n  <li>Prozess-Footprint messen (PSS, nicht nur RSS) und <strong>pm.max_children<\/strong> mit Reserve w\u00e4hlen.<\/li>\n  <li>Modus passend zum Muster w\u00e4hlen: Static (konstant), Dynamic (wechselnd), Ondemand (viel Leerlauf).<\/li>\n  <li><strong>pm.max_requests<\/strong> setzen, Wachstum der Worker beobachten, bei Bedarf nachregeln.<\/li>\n  <li>OPcache dimensionieren und Warmup\/Preload pr\u00fcfen, um Kaltstarts zu d\u00e4mpfen.<\/li>\n  <li>Status-Page und Slowlog aktivieren, Queue- und Spawn-Meldungen auswerten.<\/li>\n  <li>Webserver-Timeouts und Puffer gegen FPM- und App-Zeiten abgleichen.<\/li>\n  <li>Limits mit Downstream-Systemen harmonisieren (DB, Caches, externe APIs).<\/li>\n  <li>\u00c4nderungen dokumentieren, nach Deployments gezielt messen und iterieren.<\/li>\n<\/ul>\n\n<h2>Kompakte Zusammenfassung<\/h2>\n<p><strong>Static<\/strong> liefert die gleichm\u00e4\u00dfigste Reaktionszeit und passt zu konstantem Traffic mit reichlich RAM. <strong>Dynamic<\/strong> balanciert Flexibilit\u00e4t und Effizienz und punktet bei wechselnden Mustern. <strong>Ondemand<\/strong> spart Speicher bei Leerlauf und eignet sich f\u00fcr viele ruhende Sites, erkauft sich aber Kaltstart-Latenz. Mit sauberer Ressourcenrechnung, Monitoring und kleinen Iterationen triffst du belastbare Entscheidungen. Halte Prozesse so klein wie n\u00f6tig, setze OPcache ein und w\u00e4hle den Modus, der zu deinem echten <strong>Profil<\/strong> passt.<\/p>\n<p>Mit diesen Leitplanken holst du stabile Leistung bei vertretbarem Verbrauch heraus. Konfiguration bleibt kein Ratespiel, wenn Zahlen auf dem Tisch liegen. Kleine Schritte bringen oft die gr\u00f6\u00dften Effekte. Miss, justiere und dokumentiere. So bleiben deine <strong>PHP-FPM<\/strong>-Pools schnell, sparsam und vorhersehbar.<\/p>","protected":false},"excerpt":{"rendered":"<p>Comparaison des modes PHP-FPM : static, dynamic et ondemand pour un r\u00e9glage optimal de l'h\u00e9bergement. D\u00e9couvrez les avantages, les configs et les meilleures pratiques.<\/p>","protected":false},"author":1,"featured_media":17989,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[780],"tags":[],"class_list":["post-17996","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"875","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"PHP-FPM Modi","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"17989","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/17996","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/comments?post=17996"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/17996\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/17989"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=17996"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=17996"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=17996"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}