PHP-FPM modi in vergelijking: Statisch, Dynamisch en Ondemand

Dit artikel vergelijkt de PHP-FPM modi statisch, dynamisch en ondemand en laat zien hoe ze processen starten, RAM binden en latency beïnvloeden. Ik leg op een praktische manier uit wanneer welke modus overtuigend is, geef zinnige startwaarden, noem typische struikelblokken en laat monitoringtrucs zien zodat u uw PHP-zwembaden veilig.

Centrale punten

Om je snel op weg te helpen, zal ik de belangrijkste verklaringen compact samenvatten. De focus ligt op procesbesturing, RAM-vereisten, latentie en toepassingsgebieden. Elke selectie heeft duidelijke sterke punten, maar ook beperkingen. Met een paar kerncijfers kun je betrouwbare beslissingen nemen. Zo kunt u gericht te werk gaan Afstemmen en tijd besparen.

• StatischVast procesnummer, maximale consistentie bij constante belasting.
• DynamischAutomatisch schalen tussen minimum- en maximumwaarden.
• OndemandStarten op verzoek, zuinig stationair draaien, koude start latentie.
• RAM planningSta 20-50 MB per proces toe, voorkom OOM.
• ControleStatuspagina, logboeken en htop voor gefundeerde beslissingen.

Hoe de procesmanager werkt

De PHP-FPM procesmanager bepaalt hoeveel Werknemer-verwerkt verzoeken en wanneer ze beginnen of eindigen. Elke worker instantie houdt interpreters, uitbreidingen en delen van de bytecode in het geheugen, wat meestal een paar Megabyte bindt. De drie modi veranderen het startgedrag, de levenscyclus en het rustgedrag aanzienlijk. Static houdt een vast aantal actief, Dynamic balanceert tussen onder- en bovengrenzen, Ondemand maakt alleen processen aan als er verzoeken binnenkomen. Deze controle heeft een direct effect op RAM-profiel, latentie bij opstarten en pieken in systeembelasting.

Belangrijke parameters vormen de ruggengraat van je configuratie: pm definieert de modus, pm.max_kinderen beperkte gelijktijdige werkers moeilijk. Met Dynamic pm.start_servers, pm.min_spare_servers en pm.max_spare_servers die de breedte van de buffer bepalen. Ondemand vertrouwt op pm.process_idle_timeout, om slapende processen weer te beëindigen. Met verstandige waarden kun je ervoor zorgen dat belastingspieken niet leiden tot bottlenecks en dat de machine niet onder geheugendruk komt te staan.

Ik controleer vooraf de voetafdruk per proces, de gemiddelde gelijktijdige belasting en de piekverdeling over de dag. Uit deze variabelen leid ik de maximale waarde voor pm.max_kinderen vermenigvuldigen met het gemeten procesgeheugen en een reserve achterlaten voor de webserver, database, cache en kernel. Deze eenvoudige berekening voorkomt out-of-memory fouten en zorgt voor Stabiliteit onder druk. Als je dit ter harte neemt, bespaar je jezelf het gedoe van later bijstellen.

Statische modus: constant vermogen voor gelijkmatige belasting

De statische modus houdt een vast aantal PHP-werkers permanent actief, wat Start-overhead wordt geëlimineerd. Met constante verkeersprofielen bereikt deze opstelling zeer lage latentiefluctuaties en een consistente CPU-belasting. Het nadeel: In idle blijft het RAM bezet, ook al zijn er geen aanvragen. Daarom kies ik Static alleen op hosts met veel RAM en een berekenbaar aanvraagvolume. Op intensief gebruikte shops of API backends levert Static vaak de schoonste responscurve.

De doorslaggevende factor is een realistisch pm.max_kinderen, die is gebaseerd op de procesvoetafdruk. Voor de eerste schatting bereken ik ruwweg 20-50 MB per PHP proces, inclusief extensies en OPcache. Ik controleer de uiteindelijke waarde met belastingstests en de systeemmonitor. Als je de berekening verder wilt uitdiepen, kun je praktische stappen vinden op pm.max_children optimaliseren. Dit zorgt ervoor dat je vaste poolgrootte overeenkomt met de hardware.

[www]
pm = statisch
pm.max_kinderen = 50
pm.max_aanvragen = 500

TipNa wijzigingen start ik PHP-FPM opnieuw op, controleer ik de logs en observeer ik het gebruik onder echt verkeer. Als er nog steeds veel RAM vrij is, verhoog ik het voorzichtig. Als ik toenemend swapgebruik of OOM killer entries zie, verminder ik onmiddellijk. Deze kleine routine beschermt de Beschikbaarheid betrouwbaar.

Dynamische modus: flexibel bij fluctuerende vraag

Dynamic begint met slechts een paar processen en schaalt de Werknemer-aantal naar behoefte in het gedefinieerde bereik. Dit vermindert stationair verbruik tijdens rustige fases, terwijl korte pieken worden opgevangen. Het proces genereert wat overhead tijdens het paaien, maar scoort punten met goede Bronnen-efficiëntie. In gemengde omgevingen met dagelijkse profielen biedt Dynamic vaak het beste compromis. Vooral voor veel CMS-installaties blijft deze modus de eerste keuze.

Ik heb de start-, minimum- en maximumwaarden zo ingesteld dat er geen constante spawngebeurtenissen optreden onder normale belasting. Regelmatige logmeldingen zoals „seems busy, spawning children“ geven aan dat de limieten te krap zijn. Voor WordPress stacks helpt het om de caching en OPcache goed in te stellen en ze dan gematigd te verhogen. Een compacte gids behandelt de belangrijkste hendels: Geoptimaliseerde WordPress-instellingen. Hierdoor kunt u korte reactietijden bereiken zonder de RAM-reserve.

[www]
pm = dynamisch
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 35

TipObserveer de inactieve werknemers en de gemiddelde actieve processen gedurende de dag. Als de gemiddelde waarde dicht bij de bovengrens ligt, verhoog dan matig. Als veel processen inactief blijven, verlaag dan het bereik. Met slechts een paar iteraties zul je de Lekkere plek-instelling.

Ondemand modus: zuinig in inactieve modus, start op verzoek

Ondemand maakt alleen processen aan wanneer een Aanvraag en beëindigt het na een inactieve tijd. Dit beperkt de RAM-vereisten tot een minimum in rustige fases, wat gunstig is voor veel kleine sites op één machine. Tijdens een koude start is er echter sprake van extra vertraging omdat de worker eerst opstart en opwarmt. Voor ontwikkelomgevingen, cron-only apps en zelden gebruikte pagina's is deze logica een Winst. Ik zou Ondemand niet gebruiken bij continue belasting.

[www]
pm = ondemand
pm.max_children = 50
pm.proces_idle_timeout = 10s
pm.max_aanvragen = 500

Ik stel de inactieve tijd meestal in op 10 tot 30 seconden, afhankelijk van het belpatroon en het geheugenbudget. Een kortere periode bespaart RAM, maar verhoogt de kans op koude starts. Een langere periode houdt processen warm, maar kost geheugen. Ik houd daarom de oproepfrequentie in de gaten, meet de 95e percentiel latentie en pas deze dan nauwkeurig aan. Dit houdt de Reactietijd berekenbaar zonder het systeem te belasten.

Vergelijkingstabel: Eigenschappen van de drie modi

Het volgende overzicht vergelijkt typische eigenschappen. Ik gebruik het als basis voor discussie voordat ik inga op specifieke dimensionering. De tabel vervangt geen meting onder echte belasting, maar geeft een gestructureerd overzicht. Startpunt. Als u waarden aanpast, moet u altijd het geheugenprofiel en de latency-distributie in de gaten houden. Dus blijf bij Pieken en knelpunten te vermijden.

Criterium	Statisch	Dynamisch	Ondemand
Processen	Vast aantal, permanent actief	Automatisch tussen min/max	Alleen starten wanneer nodig
RAM-gebruik	Constant hoog	Variabel (bijv. 200-600 MB)	Minimaal in inactieve modus (bijv. 50-700 MB)
Prestaties	Zeer gelijkmatig	Goed en flexibel	Goed voor weinig verkeer
Ideaal voor	Constante profielen met veel verkeer	Variabele vraag	Veel slapende sites / Gedeeld
Overhead	Laag	Medium (spawn/despawn)	Hoger voor koude start

De tabel helpt om verwachtingen te ijken en prioriteiten duidelijk te identificeren. Als je maximale consistentie van respons nodig hebt, is de winnaar vaak Statisch. Telt efficiëntie met fluctuerende belasting, werkt Dynamisch meestal aangenamer. Als zuinigheid een prioriteit is, kun je er niet omheen. Ondemand over. Uiteindelijk beslissen gemeten waarden, niet veronderstellingen.

Hulpbronnen berekenen en dimensioneren

Ik schat eerst de geheugenafdruk per Proces vermenigvuldig dit met het beoogde aantal werkers en voeg 20-30 % reserve toe. Ik neem ook ruimte op voor Nginx/Apache, database, Redis/Memcached en de kernel. Dit totaal mag niet groter zijn dan de fysieke RAM capaciteit minus de veiligheidsmarge. Ik plan dedicated geheugen voor OPcache zodat bytecode niet wordt verplaatst. Met deze eenvoudige Formule Ik beschouw OOM-risico's als laag.

In de volgende stap meet ik gelijktijdige aanvragen via webserverstatus en APM. De piekconcurrentie voor PHP-werkers bepaalt hoe hoog pm.max_kinderen moet zijn. Als het RAM niet voldoende is, verhoog ik de cache-hits, verkort ik de query-tijden of verplaats ik werk naar wachtrijen. Pas als deze hefbomen effect hebben, verhoog ik de pool. Dit houdt de Efficiëntie hoog en de machine reageert betrouwbaar.

Bewaking en probleemoplossing

Goede beslissingen zijn gebaseerd op Gegevens. Ik activeer de PHP-FPM statuspagina en lees actieve en inactieve processen, wachtrijlengte en geaccepteerde verbindingen uit. Ik controleer ook de foutlogs op spawn-waarschuwingen en time-outs. In htop monitor ik CPU wachttijden, belasting en swap om knelpunten sneller te vinden. Deze signalen maken tuningstappen begrijpelijk en voorkom dat je blind vliegt.

<?php
$status = @file_get_contents('http://localhost/status');
$data = json_decode($status, true);
echo "Active: " . $data['active processes'] . "\n";
echo "Idle: " . $data['idle processes'] . "\n";
?>

APM-tools tonen sporen en knelpunten op functie- of query-niveau. Als ik daar uitschieters vind, begin ik eerst met caching en I/O. Daarna controleer ik of de poollimieten overeenkomen met het werkelijke parallellisme. Pas als de knelpunten in de applicatie zijn opgelost, is het de moeite waard om meer te doen. Capaciteit in FPM. Dit proces bespaart tijd en houdt de architectuur slank.

Veelvoorkomende afstemfouten vermijden

Ik zie vaak te hoge max_kinderen-waarden ongeacht het RAM-geheugen. Dit zorgt voor onnodige swap, lange vuilnisophaalfases en uiteindelijk OOM-killers. Te lage limieten zijn ook schadelijk omdat ze wachtrijen opbouwen en reactietijden rekken. Een gebrek aan OPcache verspilt ook CPU-tijd en vergroot de procesvoetafdruk. Met een paar Controles Deze vallen worden van tevoren uit de weg gehouden.

Een tweede klassieker: ongeschikte tijdslimieten met Ondemand, die leiden tot veel koude starts. Een korte A/B-test met 10, 20 en 30 seconden idle timeout helpt hier. Bij Dynamic daarentegen leiden te kleine reservewaarden tot constant spawnen. Logboeken onthullen deze patronen snel en geven richting aan de volgende Aanpassing aan. Hierdoor blijft je stapel responsief.

PHP-FPM in de context van andere PHP-handlers

PHP-FPM wordt vaak vergeleken met oude CGI-varianten of moderne alternatieven zoals LSAPI. De keuze van de handler beïnvloedt het procesbeheer, Bronnen-karakteristieken en foutisolatie. Als je de verschillen begrijpt, kun je buffers en limieten realistischer plannen. Voor een snel overzicht is het de moeite waard om een korte PHP handler vergelijking. Daarna is de beslissing ten gunste van FPM-modi duidelijk gerichter van.

Ik blijf meestal bij FPM omdat het volwassen is, netjes logt en goed werkt met Nginx/Apache. Niet alleen benchmarks zijn doorslaggevend, maar ook operationele aspecten zoals observeerbaarheid en failover. Als deze basis goed is, haal je meer uit Static, Dynamic of Ondemand. Elke optie verdient het om getest te worden onder echte belasting. Zo krijg je vertrouwen in je Instellingen.

Praktische beslissingsstrategie

Ik begin met Dynamic als Standaard, Ik meet belastingsprofielen en observeer pieken. Als ik een zeer constant gebruik aantref, schakel ik over naar Static en stel ik de vaste poolgrootte in. Als ik zelden gebruikte sites tegenkom, selecteer ik Ondemand met een geschikte idle timeout. Tegelijkertijd optimaliseer ik OPcache, object cache en database queries zodat FPM minder onder druk staat. Vervolgens stel ik de limieten zo af dat Wachtrijen in de eerste plaats niet ontstaan.

Deze volgorde vermindert risico's en inspanningen. Eerst meten, dan de regels aanpassen en dan de hardware overwegen. Ik documenteer elke wijziging kort met het tijdstip, de waarden en het doel. Dit maakt het eenvoudiger om later correcties aan te brengen en zorgt voor een schone omgeving. Transparantie. Dit houdt de stack beheersbaar, zelfs als verkeerspatronen veranderen.

Van kengetallen naar betrouwbare waarden: zo bereken ik het

Ik vertaal belastingsprofielen naar concrete poolgroottes met behulp van een eenvoudige vuistregel: Hoeveel aanvragen komen er per seconde binnen en hoe lang duurt het gemiddeld of bij het 95e percentiel om ze te verwerken? Ik gebruik het volgende als richtlijn De Wet van Little in eenvoudige vorm: gelijktijdige verwerking ≈ doorvoer × gemiddelde verwerkingstijd. Voorbeeld: 120 aanvragen/s bij gemiddeld 80 ms resulteren in ongeveer 9,6 gelijktijdige uitvoeringen. Ik voeg 30-50 % buffers toe voor pieken en controleer of de resulterende pm.max_kinderen binnen mijn RAM-budget passen. Voor harde pieken neem ik ook het 95e percentiel op om wachtrijen te voorkomen.

Het is belangrijk om Karakter van de werklasten: Bij I/O-zware apps (veel remote calls, DB-toegangen) leveren iets meer workers vaak voordelen op omdat wachttijden worden overlapt. Met CPU-zware code beperk ik meer zodat de processen elkaar niet vertragen en de run-wachtrij niet explodeert.

pm.max_requests: schone recycling tegen fragmentatie

Langlopende PHP processen kunnen worden gestopt door Versnippering of geheugenlekken groeien. Met pm.max_aanvragen definieer je na hoeveel verwerkte verzoeken een werker wordt beëindigd en opnieuw gestart. Dit houdt de voetafdruk stabiel. Ik begin meestal met 300-1000, afhankelijk van de extensies en de codebasis. Observeer de RSS/PSS-waarden van de processen: Als ze aanzienlijk groeien, verlaag dan de waarde. Aangezien de OPcache gedeeld bytecode blijft behouden tijdens het recyclen van werkers; de meeste apps merken daarom nauwelijks iets van het recyclen.

[www]
doelgericht recyclen zonder al te vaak opnieuw opstarten
pm.max_requests = 800

Iedereen die regelmatig Inzet profiteert van een herlading van de pool. Ik gebruik liever een graceful reload via de servicemanager (bijvoorbeeld „systemctl reload php-fpm“) zodat lopende verzoeken netjes eindigen en nieuwe workers starten met een bijgewerkte configuratie.

Slowlog en timeouts: knelpunten gericht visualiseren

De meeste latentiepieken worden veroorzaakt door een paar langzame aanvragen. Daarom activeer ik de Slowlog met een gematigde drempelwaarde (bijv. 2-5 s) en kijk naar stack traces. Zo vind ik problematische functies, externe aanroepen of dure query's.

[www]
request_slowlog_timeout = 3s
slowlog = /var/log/php-fpm/slowlog-www.log

In overeenstemming hiermee pas ik de Time-outs van de webserver. Een upstream timeout (Nginx/Apache) die te kort is vergeleken met PHP's max_execution_time leidt tot 502/504 fouten, hoewel FPM blijft werken. Ik houd de keten consistent: verbind, lees en verzend timeouts van de webserver net boven de typische PHP aanvraagduur, maar onder harde bovengrenzen.

Wachtrij-, backlog- en statuswaarden correct interpreteren

In de FPM-status let ik vooral op „luisterwachtrij“ en „max luisterwachtrij“. Als deze waarden regelmatig stijgen, is het zwembad te klein of geblokkeerd. Kortstondige pieken zijn normaal, maar permanente congestie duidt op te kleine socket. In omgevingen met veel pieken verhoog ik de socketachterstand matig, let op de wachtrij en zorg ervoor dat kernellimieten (bijv. somaxconn) niet de bottleneck zijn.

Als de monitoring heel vaak „seems busy, spawning children“ laat zien, zijn de reserveparameters (Dynamisch) te krap. Bij Ondemand is een terugkerend hoog percentage koude starts een indicatie om de idle timeout te verlengen of om overdag een minimale buffer aan te houden.

Meerdere pools: Eerlijkheid, isolatie en quota

Op multi-tenant of Gedeelde-hosts, scheid ik applicaties in hun eigen pools met individuele limieten. Dit voorkomt dat een project dat veel geheugen nodig heeft andere projecten verdringt. Voor kritieke diensten (bijvoorbeeld login/API endpoints) plan ik speciale pools met een vaste minimale reserve. Een duidelijke naamgeving („www-shop“, „www-api“, „www-cron“) en aparte logs maken het eenvoudiger om de gegevens te analyseren en te beheren. Foutzoeken.

Zorg ervoor dat de som van alle pm.max_kinderen past op de machine in alle zwembaden. Ik koop ook Limieten stroomafwaarts op: DB-max_verbindingen, Redis/Memcached threading en externe API rates. Een PHP pool die meer gelijktijdige query's afvuurt dan de database aankan, bezorgt zichzelf alleen maar langere wachtrijen.

Opwarmen, voorladen en koude start van OPcache temmen

Naar Ondemand-om koude starts te beperken, houd ik de OPcache stabiel (voldoende geheugen_verbruik en interned_strings_buffer) en, indien van toepassing, ingesteld op Voorbelasting centrale klassen/frameworks. Dit betekent dat bytecode beschikbaar is na de eerste hit en dat herhalingen warm blijven. Daarnaast helpen een grotere realpath cache en een gestructureerde autoloader om het zoeken op het bestandssysteem te verminderen. Alles bij elkaar verkort dit de opstarttijd van pas opgestarte workers aanzienlijk.

Webserverinteractie: Nginx/Apache netjes verbinden

Ik zorg ervoor dat de instellingen van de webserver en FPM overeenkomen: Buffer en Time-outs moet symmetrisch zijn, keep-alive mag FPM niet blokkeren met zombieverbindingen en de upstream socket (Unix of TCP) moet consistent geconfigureerd zijn. Veel 502/504 fouten worden veroorzaakt door verkeerd ingestelde leestimeouts of uitgeputte backlogs. Iedereen die FPM aanspreekt via TCP moet rekening houden met de latentie van de netwerk stack en het risico op halfopen Houd de verbindingen in de gaten; ik geef meestal de voorkeur aan Unix sockets voor lokale implementaties.

Speciale kenmerken Container/VM

In containers is de cgroup-limieten, niet noodzakelijkerwijs de hostwaarden. Ik dimensioneer pools expliciet voor de container RAM en gebruik kunstmatige belastingspieken om te testen of OOM-killers effect kunnen hebben. Een te krappe limiet leidt tot harde annuleringen. Het verwisselen van containers is ook vaak ongewenst - het is dus beter om iets conservatiever te zijn met pm.max_kinderen applicatiecaching plannen en prioriteren.

CPU en I/O-karakter herkennen

Ik gebruik htop/iostat om te beoordelen of werklasten CPU- of I/O-gebonden zijn. Hoog CPU-gebruik met lage I/O-wachttijden duidt op een computerbelasting - hier beperk ik de werkers dichter bij het aantal cores. Hoge I/O wachttijden rechtvaardigen meer werkers omdat wachttijden op de database, het netwerk of het bestandssysteem elkaar overlappen. Je kunt de limiet herkennen aan het feit dat de latentie niet langer afneemt ondanks extra werkers, maar dat de belasting aanzienlijk toeneemt.

Snel typische 502/504 patronen decoderen

• 504 Gateway timeout: Web server timeout korter dan PHP uitvoeringstijd of geblokkeerde pool (wachtrij vol).
• 502 Slechte gateway: FPM niet bereikbaar (socket/poort), crash/herstart tijdens het verzoek of buffer te klein.
• Pieken kort na implementatie: OPcache koud, controleer optimalisaties autoloader/composer, plan opwarming.

Ik correleer het foutlogboek van de webserver, het FPM-foutlogboek en de statuspagina in hetzelfde tijdsvenster. Dit laat zien of het probleem zich voor, in of naar FPM bevindt zich.

Handel meten: Opslagkosten correct registreren

Voor RAM-planning kijk ik niet alleen naar RSS, maar ook naar de PSS (Proportional Set Size) omdat het gesplitste pagina's (bijvoorbeeld OPcache) eerlijk verdeelt over processen. Gereedschappen zoals smem of pmap helpen om realistische procesgerelateerde waarden te bepalen. In de praktijk zijn willekeurige steekproeven onder belasting echter vaak voldoende: markeer meerdere processen, bereken het gemiddelde, vergelijk met Reserve vermenigvuldigen - dit weerspiegelt de werkelijkheid beter dan theoretische waarden van forums.

Mini-checklist voor snelle iteraties

• Belastingsprofiel opnemen (RPS, 50/95/99 percentiel, parallellisme).
• Meet de procesvoetafdruk (PSS, niet alleen RSS) en pm.max_kinderen met voorbehoud.
• Selecteer de modus die bij het patroon past: Statisch (constant), Dynamisch (wisselend), Ondemand (veel inactieve tijd).
• pm.max_aanvragen instellen, de groei van de werksters observeren en indien nodig bijstellen.
• Dimensioneer OPcache en controleer opwarmen/voorladen om koude starts te temperen.
• Statuspagina en slowlog activeren, wachtrij analyseren en berichten spawnen.
• Synchroniseer webserver timeouts en buffers met FPM en app tijden.
• Harmoniseer limieten met downstream systemen (DB, caches, externe API's).
• Documenteer wijzigingen, meet en itereer na implementaties.

Compact overzicht

Statisch levert de soepelste reactietijd en is geschikt voor constant verkeer met veel RAM. Dynamisch balanceert flexibiliteit en efficiëntie en scoort hoog bij veranderende patronen. Ondemand spaart geheugen in inactieve toestand en is geschikt voor veel slapende sites, maar gaat ten koste van de latentie bij een koude start. Met een schone resourceberekening, monitoring en kleine iteraties kunt u betrouwbare beslissingen nemen. Houd processen zo klein als nodig, gebruik OPcache en kies de modus die past bij je werkelijke behoeften. Profiel past.

Met deze relingen kun je stabiele prestaties bereiken met een redelijk verbruik. Configuratie is geen raadspelletje als de cijfers op tafel liggen. Kleine stappen hebben vaak het grootste effect. Meet, pas aan en documenteer. Zodat uw PHP-FPM-pools snel, economisch en voorspelbaar.