Ga naar de inhoud 
Ik zal je laten zien hoe je WordPress PHP-FPM zodat de pagina's ook onder belasting snel worden weergegeven en de server soepel draait. Om dit te doen, gebruik ik specifieke parameters zoals pm.max_kinderen, OPcache, sockets en timeouts en bieden duidelijke, betrouwbare startwaarden.
Centrale punten
- pm.max_kinderen Realistische berekening voor RAM
- Dynamisch als modus voor de meeste sites
- OPcache Activeren en dimensioneren
- Sockets in plaats van TCP voor Nginx/Apache
- Controle Gebruik voor fijnafstelling
Waarom PHP-FPM telt bij WordPress
Ik vertrouw op PHP-FPM omdat de FastCGI Process Manager verzoeken parallel met werkprocessen afhandelt en zo de wachttijden aanzienlijk verkort. WordPress-pagina's reageren aanzienlijk sneller. Vergeleken met oude handlers houdt FPM de CPU- en RAM-belasting onder controle, wat vooral belangrijk is tijdens pieken met veel gelijktijdige aanvragen en storingen voorkomt. Plugins en thema's hebben geheugen nodig, dus elk kind heeft een bepaalde buffer nodig, die ik doorlopend bereken en controleer. Met een slimme poolconfiguratie werk ik door fluctuaties heen zonder inactieve tijd te produceren of de server te overbelasten. Een schone aanpak vermindert de reactietijden, verhoogt de betrouwbaarheid en zorgt ervoor dat de server soepel blijft draaien. Laadtijd constant laag.
Bestanden, pools en zinnige structuur
De FPM poolconfiguratie ziet er meestal als volgt uit /etc/php/[versie]/fpm/pool.d/ of /etc/php-fpm.d/, en ik controleer het exacte pad via php -i om niet het verkeerde bestand te tweaken. Ik gebruik een aparte pool voor elke site omdat geïsoleerde processen het oplossen van problemen vereenvoudigen en de belasting netjes scheiden. Ik definieer de gebruiker, het socketpad, de procesmanager en alle limietwaarden in www.conf of een project-specifieke pool.conf. Ik geef sockets een unieke naam, zoals /run/php/siteA.sock, zodat Nginx specifiek naar de pool wijst en ik niet het risico loop ze door elkaar te halen. Deze duidelijke scheiding zorgt voor consistente Bronnen-toewijzing en stabiele implementaties.
Veiligheid, rechten en schone zwembadisolatie
Ik wed per pool gebruiker en groep overeenkomt met de web root (bijvoorbeeld www-data) zodat de bestandsrechten consistent blijven en de webserver geautoriseerd is om de socket te gebruiken. Voor Unix sockets kies ik listen.owner, listen.group en listen.mode (0660) zodat Nginx/Apache er betrouwbaar toegang toe heeft. Met clear_env=no Ik sta noodzakelijke omgevingsvariabelen toe (bijvoorbeeld voor externe services) zonder de beveiliging te versoepelen. beveiliging.beperken_uitbreidingen naar .php om te voorkomen dat andere bestanden per ongeluk worden uitgevoerd. Optioneel stel ik chdir naar de document root van het project; chroot is mogelijk, maar vereist meer bedieningsinspanning en is niet geschikt voor elke omgeving.
Procesbeheermodi correct selecteren
Voor de meeste installaties gebruik ik de modus dynamisch, omdat het flexibel belastingspieken opvangt en bronnen spaart tijdens inactieve tijden. In de statische modus blijft het aantal processen onveranderd, wat nuttig kan zijn voor extreem uniforme hoge belastingen, maar het RAM-geheugen vastzet. Ondemand start processen alleen wanneer dat nodig is, wat nuttig is op zeer kleine instanties, maar zorgt voor vertragingen bij een koude start. De keuze hangt af van het verkeersprofiel: fluctuerend verkeer heeft baat bij dynamisch, constante pieken spelen met statisch, opstellingen met weinig verkeer draaien vaak beter met ondemand. Ik neem de beslissing altijd in combinatie met echte meetwaarden, omdat alleen gegevens laten zien of een modus voldoet aan de Belasting echt draagt.
| Modus | Gebruik | Voordeel | Tip |
|---|---|---|---|
| dynamisch | Fluctuerend verkeer | Flexibel, goede reactietijd | Solide beginwaarden zijn voldoende voor het begin |
| statisch | Zeer constante hoge belasting | Voorspelbaar RAM-gebruik | RAM moet voldoende zijn |
| ondemand | Lage basisbelasting | Zuinig bij stationair draaien | Overweeg een koude start |
CPU-kernen, I/O en het juiste parallellisme
Ik let op de balans tussen CPU cores en blokkerende operaties. WordPress verzoeken wachten vaak op I/O (database, bestandssysteem, externe API's), dus het aantal kinderen kan het aantal cores overschrijden. Voor CPU-zware setups (beeldverwerking, rapporten) blijf ik dichter bij 1-2x cores, voor I/O-zware sites werken 2-4x cores zolang RAM en timeouts netjes zijn ingesteld. Ik test onder belasting of de CPU permanent vastzit op 100 % (te veel processen) of onderbenut is ondanks een lange wachttijd (I/O-knelpunt, ontbrekende cache).
pm.max_children berekenen: zo ga ik te werk
Ik begin met het RAM-geheugen van de server, het werkelijke verbruik per PHP-proces en een buffer voor de database en webserver, zodat niets het plafond raakt. Grenswaarden meteen stabiel. Voorbeeld: 4 GB RAM, 1 GB buffer voor MySQL/Nginx/cache en Ø 100 MB per PHP proces resulteert in 30-35 kinderen, niet 40, omdat ik rekening houd met reserves. Als je veel geheugenvretende plugins gebruikt, plan dan 120-150 MB per proces en test of het profiel past. Voor pieken oriënteer ik me op gelijktijdige verzoeken: met ongeveer 50 parallelle bezoeken zijn 15-25 kinderen vaak genoeg als caching en OPcache goed werken. Een gedetailleerde afleiding vind je hier: pm.max_children optimaliseren, en ik haal er de logica uit, niet blindelings de cijfers.
Selecteer start-, reserve- en verzoekparameters
Voor dynamisch stel ik pm.start_servers vaak in op 10, pm.min_spare_servers op 5 en pm.max_spare_servers op 20, omdat dit de opstartfase en inactieve tijd goed balanceert en de Reactietijd blijft constant. pm.max_requests met 300-800 voorkomt geheugenlekken van opgeblazen processen; 500 is een solide beginwaarde. Ik verhoog pm.max_spare_servers als er wachtende verzoeken zijn en de wachtrij groeit. Als er te veel inactieve processen zijn, verlaag ik de reservewaarden zodat RAM vrij blijft. Na elke verandering controleer ik de CPU, RAM, de wachtrij voor aanvragen en de foutenlogboeken, anders blijft het afstemmen een gok in plaats van een duidelijke beslissing.
Time-outs, versie en geheugenlimiet
Ik stel request_terminate_timeout meestal in op 60-120 seconden zodat hangende scripts worden beëindigd en de pool vrij blijft. Fout in de code of in integraties. Ik houd de PHP-versie modern, d.w.z. 8.1 of 8.2, omdat nieuwe versies merkbare prestatieverbeteringen en betere typebeveiliging opleveren. De geheugenlimiet is vaak 256M of 512M, afhankelijk van het plugin-landschap en de beeldverwerking. Als je veel hoge resoluties verwerkt, bereken dan reserves, test uploads en houd de logs in de gaten. Wat uiteindelijk telt is of de combinatie van limiet, aanvragen en OPcache zonder uitschieters draait en geen out-of-memory fouten geeft.
OPcache: de CPU-turbo voor WordPress
Ik laat OPcache nooit weg omdat het gecompileerde PHP bytecode in RAM bewaart en zo enorm veel CPU-tijd bespaart; dit ontlast de Werknemer en maakt elke pagina sneller. In productie schakel ik tijdstempelcontroles uit en wijs ik genoeg geheugen toe aan de cache om constante evictions te voorkomen. Voor middelgrote sites is 128-192 MB vaak genoeg, grotere installaties hebben baat bij 256 MB en meer. Ik controleer de hitrate met een OPcache statusscript, anders blijft het onduidelijk of de cache groot genoeg is. Voorbeeldwaarden die succesvol zijn gebleken kun je hier zien:
opcache.enable=1
opcache.geheugen_verbruik=128
opcache.max_versnelde_bestanden=10000
opcache.validate_timestamps=0
opcache.revalidate_freq=0
Voor WordPress schakel ik de JIT meestal uit omdat de workloads er zelden baat bij hebben, maar extra geheugen in beslag zou nemen. Na implementaties warm ik de cache op met de belangrijkste routes of WP-CLI commando's, zodat de eerste gebruikers geen last hebben van overhangende compilaties.
Nginx/Apache: Socket in plaats van TCP en de keuze van handler
Ik gebruik Unix sockets tussen de webserver en FPM omdat de lokale socketaanroep minder overhead heeft dan TCP en dus wat latency bespaart; dit betaalt zich direct terug op de Prestaties in. In Nginx ziet dit er ongeveer zo uit: fastcgi_pass unix:/run/php/wordpress.sock;. In Apache met Proxy-FastCGI werkt de socket ook zolang de rechten correct zijn. Ik controleer ook de actieve PHP handler en kies FPM boven oude varianten. Als je de verschillen in meer detail wilt begrijpen, klik dan door dit overzicht: PHP handlers vergelijken, om misvattingen over mod_php, FPM en proxy-varianten te vermijden.
Webserverparameters die overeenkomen met de FPM-pool
Ik pas de timeouts van Nginx/Apache aan aan de FPM-waarden zodat geen enkele laag te vroeg eindigt. fastcgi_read_timeout Ik oriënteer me op request_terminate_timeout (bijvoorbeeld 120s), fastcgi_connect_timeout Ik houd ze kort (1-5s). Voldoende fastcgi_buffers 502/504 voorkomen voor grote reacties. Ik stel keep-alive en worker limieten realistisch in: veel zeer lange keep-alive verbindingen blokkeren anders slots die PHP backends nodig hebben. Onder Apache gebruik ik Event-MPM, beperk MaxRequestWorkers tot het RAM-geheugen en zorg ervoor dat FPM meer kinderen kan leveren dan de webserver parallel naar de backend afhandelaar stuurt - anders zullen frontend clients in de wachtrij verstrikt raken.
Gericht gebruik van monitoring en FPM-status
Ik meet continu, anders blijft de afstemming puur op gevoel en raakt de werkelijke Oorzaak htop/top laten in één oogopslag zien of het RAM-geheugen bijna leeg is, of processen aan het doordraaien zijn en of de CPU-kernen goed worden gebruikt. De PHP FPM statuspagina toont de wachtrijlengte, actieve en wachtende processen en de gemiddelde verwerkingstijd per verzoek. Als de wachtrij en wachttijd toenemen, ontbreken er meestal processen of werkt de caching niet. Als je geïnteresseerd bent in parallelle processen, is dit een goede plek om te beginnen: PHP-worker bottleneck, omdat het aantal workers uiteindelijk het aantal gelijktijdige PHP verzoeken per instantie beperkt.
Slowlog, backlog en stabiele foutdiagnose
Om uitschieters te vinden, activeer ik de Slowlog per zwembad en set verzoek_slowlog_timeout naar 3-5 seconden. Hierdoor kan ik zien welke scripts hangen en of externe oproepen de boel vertragen. Met catch_workers_output meldingen/waarschuwingen per proces komen in het poollog terecht, wat de analyse van de hoofdoorzaak versnelt. Daarnaast stel ik de socketlisten.backlog hoog (bijvoorbeeld 512-1024) zodat korte pieken niet direct leiden tot 502; ik correleer dit met de kernel backlog (somaxconn) zodat de wachtrij niet faalt door het OS. Als logs vaak “server bereikt pm.max_children” of “zwembad lijkt druk”, is het parallellisme te laag of ligt de oorzaak bij de database/externe services.
Veelvoorkomende struikelblokken en snelle oplossingen
Veel problemen herhalen zich in vergelijkbare patronen, dus ik heb altijd typische symptomen, oorzaken en tegenmaatregelen paraat zodat ik niet elke keer opnieuw hoef te beginnen en kostbare tijd verlies. Tijd verliezen. Hoge responstijden, 502 fouten of geheugenfouten duiden meestal op verkeerd ingestelde procesnummers, verkeerde reservewaarden of overvolle scripts. In de praktijk helpt het om slechts één variabele per ronde te veranderen en dan de metriek te controleren. Wie OPcache vergeet of max requests op oneindig zet, betaalt vaak de prijs met sluipende geheugenlekken. De volgende tabel vat de meest voorkomende gevallen samen:
| Probleem | Oorzaak | Oplossing |
|---|---|---|
| Hoge responstijd | Te weinig max_children | Herbereken en verhoog pm.max_children |
| 502 Slechte gateway | Pool volledig benut of reservewaarden te krap | Verhoog pm.max_spare_servers en controleer logs |
| Toegestane geheugengrootte uitgeput | Lekke scripts of geheugenlimiet te laag | Verminder pm.max_requests, controleer OPcache, verhoog limieten |
| Trage koude start | ondemand bij piekbelasting | Schakel over op dynamisch en verhoog start/spaarwaarden |
WordPress-specifieke belastingstuurprogramma's beperken
Ik controleer typische hotspots: admin-ajax.php, wp-json en heartbeat routes. Veelgebruikte AJAX of REST endpoints kunnen de pool overbelasten als caching in werking treedt maar deze routes moet doorlaten. Kortere timeouts, schone object caches en prioritering kunnen hier helpen: ik draai optioneel een aparte pool met een kleiner aantal kinderen voor /wp-admin/ en /wp-login.php zodat de publieke pool performant blijft, zelfs tijdens redactionele pieken. wp-cron Ik ontkoppel van bezoekersverkeer (echt systeem cron) zodat langlopende taken niet toevallig op gebruikerstoegang vallen. Met een persistente objectcache (Redis/Memcached) wordt de DB-belasting aanzienlijk verminderd; dit betekent dat pm.max_kinderen vaak lager zonder aan prestaties in te boeten.
Instellingen voor veel verkeer: Caching, database en server tuning
Als er veel verkeer is, combineer ik FPM-tuning met agressieve pagina-caching, zodat slechts een fractie van de verzoeken PHP bereikt en de Reactietijd voorspelbaar blijft. Een reverse proxy cache of een goede WordPress cache plugin vermindert vaak drastisch dynamische hits. Gzip of Brotli op de webserver bespaart bandbreedte en verkort de time-to-first-byte voor terugkerende bronnen. Ik houd de database slank: houd de autoload-opties in de gaten, ruim transiënten op en voer query-monitoring uit. Deze modules verhogen de effectieve capaciteit per instantie aanzienlijk zonder de hardware te hoeven veranderen.
Tegendruk regelen en overbelasting voorkomen
Ik definieer bewust waar verzoeken wachten: ik heb liever dat ze in de wachtrij van de webserver staan dan in de FPM pool. Om dit te doen, houd ik de listen.backlog matig en beperk webserverwerkers zodat ze de pool niet ongecontroleerd overspoelen. Een te grote achterstand verbergt knelpunten en verhoogt latentiepieken. Een te kleine achterstand leidt tot 502 fouten. Ik kan de „juiste“ grootte herkennen in de status: als de lijstwachtrij in FPM zelden pieken vertoont en de responstijden toch stabiel blijven, dan is de balans goed.
Implementaties, herladen en geen downtime
Ik geef de voorkeur aan Herlaadbeurten in plaats van harde herstarts, zodat lopende verzoeken netjes worden afgerond. In FPM regel ik dit met proces_controle_time-out, zodat kinderen tijd hebben voor een ordelijke afsluiting. Na het uitrollen van code, leeg ik de OPcache niet blindelings, maar warm hem specifiek op of accepteer een korte mixfase met validate_timestamps=1 voor blauw/groene strategieën. Belangrijk: De webserver moet een graceful reload Anders riskeer je korte 502 vensters, ook al blijft de pool correct werken.
Uitgebreide aantekeningen voor virtualisatie en multi-sites
Op virtuele of container hosts merk ik op dat gemeten RAM-groottes en CFS-quota de effectieve Prestaties Daarom laat ik pm.max_children nooit tot aan de rekenlimiet draaien. Ik scheid multi-site omgevingen per pool zodat een heet project de anderen niet vertraagt. Voor sterk fluctuerend verkeer is automatisch schalen met meerdere kleine instanties vaak beter dan één grote machine. Gedeelde NFS of opslag op afstand breiden bestandstoegang uit; OPcache en lokale uploads bufferen een groot deel. Dit betekent dat het platform voorspelbaar blijft, zelfs als individuele sites uitvallen.
Concrete kengetallen lezen en correct interpreteren
In de FPM-status kijk ik vooral naar de lopende, wachtende en totale processen omdat deze drie getallen de status van de FPM weergeven. zwembaden kan snel worden samengevat. Een permanent groeiende wachtrij duidt op te weinig aanbod of een ontbrekende cache-hit. Als de CPU stilstaat hoewel er aanvragen wachten, zijn I/O of externe diensten vaak aan het blokkeren; profiling en timeouts kunnen hier helpen. Als processen constant herstarten, is pm.max_requests te laag of lekt een plugin geheugen. Ik herken zulke patronen, controleer ze met logs en pas dan pas ik de relevante parameters aan.
Andere praktische waarden die ik in de gaten houd
Ik waardeer „max. bereikte kinderen“ teller, de gemiddelde verwerkingstijd per aanvraag en de maximale lijstwachtrij. Als de „inactief“ permanent erg hoog is in de FPM-status, verspil ik RAM - dan verlaag ik de reservewaarden of het aantal kinderen. Accumuleer „langzame aanvragen“, neem ik eerst mijn toevlucht tot slowlog-analyse en controleer DB-query's, externe API's en beeldverwerking. In Nginx/Apache observeer ik open verbindingen, keep-alive duur en foutcodes; 499/408 wijzen op crashes van clients (langzame netwerken, mobiel), 504 eerder te korte timeouts van backends.
In een notendop: de essentie van snelle WordPress PHP FPM setups
Ik bereken pm.max_children conservatief, gebruik dynamisch, stel start/spaar waarden verstandig in en houd OPcache groot genoeg zodat code in de Cache overblijfselen. Sockets in plaats van TCP verminderen latency, timeouts elimineren hangs en moderne PHP-versies stuwen de prestaties vooruit. Monitoring geeft de waarheid over wachtrijen, geheugen en responstijd; ik meet elke verandering daaraan af. Met een cache voor PHP, een gezonde database en een solide FPM-configuratie blijft de site snel en betrouwbaar. Als je deze aanpak consequent toepast, haal je op de lange termijn het meeste uit WordPress PHP-FPM.
