Wat zijn PHP workers en wanneer raken ze ‘uitgeput’?
PHP is de programmeertaal waarin WordPress geschreven is. Elke keer dat iemand jouw website bezoekt, wordt er op de server PHP-code uitgevoerd om die pagina dynamisch te genereren. PHP workers zijn de individuele processen op de server die zulke websiteverzoeken afhandelen. Je kunt ze zien als de “werkpaarden” of werknemers die telkens één taak (één pagina-aanvraag) tegelijk uitvoeren.
Stel je een supermarkt voor met een paar kassa’s. Een PHP worker is als een kassamedewerker die één klant tegelijk helpt. Als alle kassa’s bezet zijn en er komen nieuwe klanten, moeten die wachten in de rij totdat er een kassa vrijkomt. Net zo op je website: als alle PHP workers bezig zijn, moeten nieuwe verzoeken wachten. Wanneer er te veel aanvragen tegelijk binnenkomen, kan de pool van beschikbare PHP workers inderdaad uitgeput raken – oftewel, er zijn niet genoeg “kassa’s” (workers) om alle “klanten” (verzoeken) meteen te bedienen. Dit leidt tot wachtrijen op de server. In zo’n geval merk je vertragingen en kan de server zelfs beginnen met het teruggeven van fouten als bepaalde verzoeken te lang moeten wachten of helemaal niet meer verwerkt worden. Met andere woorden: “PHP workers uitgeput” betekent dat alle beschikbare PHP-processen op de server in gebruik zijn, waardoor extra verzoeken moeten wachten en je site daardoor traag of onbereikbaar wordt.
Hoe herken je dat je PHP workers uitgeput zijn?
Wanneer de PHP workers van je site hun handen vol hebben, zul je dat als gebruiker of beheerder op een aantal manieren merken. De symptomen kunnen in eerste instantie subtiel zijn, maar worden duidelijker naarmate de overbelasting langer duurt:
- Trage laadtijden van pagina’s: Pagina’s kunnen af en toe heel langzaam laden of helemaal niet verschijnen. Je bezoekt bijvoorbeeld je site en merkt dat het laden veel langer duurt dan normaal, of de pagina blijft hangen.
- Foutmeldingen zoals 502/504 Gateway Timeout: In ernstigere gevallen krijg je in de browser een foutmelding te zien, zoals “502 Bad Gateway” of “504 Gateway Timeout”. Dit betekent dat een verzoek zo lang in de wachtrij heeft gestaan dat de server het heeft opgegeven. Soms zie je ook een blanco pagina of een “white screen of death”, wat erop neerkomt dat de server de pagina niet meer kon genereren.
- WordPress-dashboard reageert niet: Je admin-omgeving (wp-admin) kan extreem traag worden of zelfs onbereikbaar. Je klikt bijvoorbeeld op een menu-optie in het dashboard, maar niks lijkt te gebeuren. Dit komt doordat ook backend-acties een PHP worker nodig hebben; als die allemaal bezet zijn, kan zelfs het beheer van je site vastlopen.
- Piekmomenten verergeren het probleem: Vaak zie je deze verschijnselen tijdens piekverkeer, bijvoorbeeld wanneer je net een nieuwsbrief hebt gestuurd of een productlancering hebt. Op zulke momenten komen er veel gelijktijdige bezoekers, waardoor de kans groter is dat alle PHP workers tegelijk bezet raken. Tijdens zo’n verkeerspiek kan de Time To First Byte (TTFB) – de tijd voordat de eerste data van de server komt – flink oplopen.
Als je een of meer van deze symptomen opmerkt, is de kans groot dat je site tegen de limiet van zijn PHP workers aanloopt. In feite “staat je site in de rij te wachten” op servercapaciteit, vergelijkbaar met klanten die in een overvolle winkel op de enige vrije kassa wachten.
Waardoor raken PHP workers uitgeput?
Maar waardoor gebeurt dit eigenlijk? Er zijn een aantal veelvoorkomende oorzaken voor het uitputten van PHP workers. Meestal is het een combinatie van factoren die samen voor te veel drukte zorgen. Hier zijn de belangrijkste boosdoeners op een rij:
- Veel gelijktijdige verzoeken (piekbelasting): De meest voor de hand liggende oorzaak is een plotselinge toename in verkeer. Denk aan een promotie waarbij veel mensen tegelijk je site bezoeken, of zelfs kwaadaardige bots/verkeer. Als er in korte tijd veel ongecachete pagina-aanvragen binnenkomen, kunnen alle workers bezet raken. Elke bezoeker die een nieuwe pagina opvraagt, vraagt een stukje werk van PHP – en bij genoeg bezoekers tegelijk is het limiet snel bereikt.
- Langzame plugins of zware processen: Niet alle pagina-aanvragen zijn even snel afgehandeld. Sommige plugins of themafuncties kunnen een pagina erg traag maken. Bijvoorbeeld een plugin die een ingewikkelde databasequery uitvoert of veel berekeningen doet, zal een PHP worker langere tijd bezighouden. Zolang die worker aan het “worstelen” is met die taak, kan hij geen andere verzoeken oppakken. Eén zo’n langzaam proces (bijv. het genereren van een groot rapport of laden van veel data) kan dus al een kettingreactie geven: andere verzoeken moeten wachten.
- Externe koppelingen die vertragen: Als je site bij het laden van een pagina contact moet maken met externe diensten, kan dat ook voor vertraging zorgen. Denk aan een thema of plugin die bij elke pagina een verzoek doet naar een externe API (bijvoorbeeld voor het ophalen van verzendkosten in real-time, of social media feeds). Wanneer die externe dienst traag reageert, blijft de PHP worker ook zolang “in de wacht” staan. Hierdoor duurt het verwerken van dat verzoek extra lang, en stapelen andere verzoeken zich intussen op.
- Cronjobs en geplande taken op drukke momenten: WordPress voert via WP-Cron regelmatig geplande taken uit op de achtergrond – zoals het publiceren van geplande berichten, uitvoeren van backups, of synchronisaties met andere systemen. Als zo’n zware cronjob precies gaat draaien terwijl er ook veel bezoekers op de site zijn, kan dat extra PHP workers opslokken. Voorbeeld: een backup-plugin die op het uur data gaat wegschrijven of een import-script dat veel producten inlaadt. Die taken kunnen één of meerdere workers langdurig bezighouden, waardoor er minder overblijven voor reguliere bezoekersverzoeken.
- Beperkte serverresources of hostinglimieten: Niet elke hostingomgeving is even ruimhartig met PHP-capaciteit. Sommige (shared) hostingpakketten bieden slechts een handjevol PHP workers tegelijkertijd aan. Als jouw pakket bijvoorbeeld maximaal 2 gelijktijdige PHP-processen toestaat, zit je site al bij de derde gelijktijdige bezoeker aan zijn plafond. Veel managed WordPress-hosters hanteren een vast maximum aantal PHP workers per site; zodra je daar overheen gaat, moet je upgraden naar een duurder plan of accepteren dat verzoeken in de rij blijven staan. Ook schaarse CPU- of geheugenbronnen op de server spelen mee – een zwakke server kan minder processen vlot laten draaien. Kortom, een klein of gedeeld hostingpakket is eerder “uitgeput” dan een krachtigere server.
Al deze factoren dragen bij aan het uitputten van PHP workers. In de praktijk is het vaak een combinatie: bijvoorbeeld een piek in verkeer én een niet-gecachete, zware pagina (zoals een WooCommerce winkelwagen) tegelijkertijd. Het resultaat is hoe dan ook dat alle beschikbare workers bezet raken en nieuwe verzoeken moeten wachten.
Wat gebeurt er achter de schermen bij een WordPress-verzoek?
Om beter te begrijpen waarom PHP workers zo belangrijk zijn, is het handig om te weten wat er achter de schermen gebeurt als iemand een pagina opvraagt op je WordPress-site. Ik neem je in vogelvlucht mee door het proces, van klik tot resultaat:
- Een bezoeker doet een verzoek: Iemand klikt op een link of typt je URL in. Dit is het moment waarop er een verzoek naar jouw webserver gaat voor bijvoorbeeld jouwsite.nl/voorbeeldpagina.
- Webserver ontvangt het verzoek: De webserver (bijvoorbeeld Apache of Nginx) die bij je hosting draait, krijgt dat verzoek binnen. De server ziet: dit is een PHP-gebaseerde site (WordPress), dus PHP moet ingeschakeld worden om de pagina te bouwen.
- PHP (worker) gaat aan de slag: De server geeft het verzoek door aan een PHP worker. Die worker draait de WordPress-code om de pagina samen te stellen. WordPress haalt bijvoorbeeld de juiste inhoud uit de database (via MySQL) en genereert met de PHP-scripts van je thema en plugins een HTML-pagina. Dit kost processortijd en geheugen, afhankelijk van hoe complex de pagina is.
- Database en bestanden worden geraadpleegd: Tijdens dat proces doet de PHP-code databasevragen (queries) om bijvoorbeeld de tekst van je bericht op te halen, en laadt hij de benodigde thema- en pluginbestanden in. Dit alles gebeurt binnen diezelfde PHP worker. Als de code efficiënt is en de database vlot reageert, is dit klusje in fracties van een seconde gepiept. Maar als er veel data verwerkt moet worden of de database zoekacties zwaar zijn, duurt het langer.
- PHP levert de output terug aan de webserver: Zodra de PHP worker klaar is met de pagina bouwen, geeft hij de resulterende HTML terug aan de webserver, die de pagina naar de bezoeker stuurt.
Al deze stappen doorloopt je server voor elke niet-gecachede paginaview. Gelukkig zijn er manieren om het aantal benodigde PHP-bewerkingen te verminderen. Caching speelt daarbij een grote rol. Bij caching wordt een eerder gegenereerde pagina tijdelijk bewaard, zodat bij volgende bezoeken die kant-en-klare versie direct geserveerd kan worden zonder dat PHP het opnieuw hoeft te berekenen. Een volledig gecachte pagina kan direct door de server aan de bezoeker gegeven worden zonder tussenkomst van een PHP worker. Dit maakt zulke pagina’s razendsnel, omdat ze de “rij bij de kassa” overslaan. Alleen wanneer een pagina niet in de cache staat of wanneer er dynamische (persoonlijke) inhoud moet worden gegenereerd, is een PHP worker echt aan het werk.
Je kunt het zo zien: een ongecachede WordPress-pagina is als à la minute koken in een restaurant – de kok (PHP worker) moet het gerecht nog bereiden met ingrediënten uit de voorraad (database). Een gecachede pagina is als een maaltijd die al klaarstaat om opgediend te worden. Logischerwijs kost het tweede scenario vrijwel geen wachttijd of inspanning. Daarom merk je bij sites met goede caching dat ze veel meer verkeer aankunnen zonder traag te worden: veel bezoekers krijgen simpelweg een eerder voorbereide pagina, en de PHP workers worden nauwelijks belast.
Maar als je site bijvoorbeeld een webwinkel is waarbij elke bezoeker unieke winkelwageninformatie ziet, of je hebt gepersonaliseerde content, dan wordt er vaker niet uit de cache geserveerd. Dan moeten de PHP workers echt aan de bak voor ieder bezoek. In zo’n geval is het des te belangrijker dat de code en database optimaal presteren en dat je voldoende servercapaciteit hebt, omdat de “kassa-rij” anders snel volloopt.
Ligt het probleem aan WordPress of aan de hosting?
Wanneer je te maken krijgt met uitgeputte PHP workers, is het natuurlijk de vraag waar je moet kijken: zit het probleem in mijn website (WordPress zelf, of een plugin), of komt het door de grenzen van mijn hostingserver? Het eerlijke antwoord is dat het vaak een combinatie is.
WordPress-kant
Aan de WordPress-kant zou je kunnen zeggen: bepaalde plugins, thema’s of custom code vragen misschien wel erg veel van elke pagina-opvraag. Als je bijvoorbeeld tientallen plugins actief hebt, of één plugin die structureel zware werkzaamheden uitvoert bij elke bezoeker, dan belast dat elke PHP worker onnodig lang. Optimaliseren van je website (slanke code, minder onnodige features, goede caching) kan de druk verlichten. Hoe sneller een PHP worker klaar is met een taak, hoe sneller hij door kan naar de volgende in de wachtrij. Een geoptimaliseerde site kan dus meer bezoekers verwerken met hetzelfde aantal workers, omdat iedere taak minder tijd kost. Als je merkt dat je vaak het maximum aantal workers raakt, kan dat een teken zijn dat er prestatie-issues in je sitecode zitten of dat je site structureel meer verkeer/dynamiek heeft dan je huidige setup vlot aankan. Hier is inzicht in je eigen site belangrijk: een simpele blog kan met 2 workers prima uit de voeten, maar een WooCommerce-shop met veel klanten en zonder caching heeft er waarschijnlijk meer nodig.
Hosting-kant
Aan de andere kant legt je hostingomgeving de fundamentele grenzen vast. Elk hostingpakket heeft een bepaalde capaciteit, vergelijkbaar met het formaat van een keuken en het aantal koks dat erin werkt. Op shared hosting (“gedeelde keuken”) deel je de serverbronnen met vele andere sites. Vaak is er een limiet op het aantal PHP-processen dat je tegelijk mag draaien, en moet je bij overschrijding duurdere hosting afnemen. Ook worden CPU en geheugengebruik meestal streng gemonitord. Dit betekent dat zelfs als je website zelf goed is ingericht, een klein hostingpakket gewoon niet meer dan X gelijktijdige verzoeken aankan voordat de rest in de wachtrij gezet wordt. Sommige hostingproviders isoleren iedere WordPress-site in een eigen container met een vast aantal PHP threads/workers. Dit is goed voor veiligheid en stabiliteit, maar het betekent ook dat je site niet boven dat aantal uit kan, ongeacht hoeveel rek de server verder nog heeft. Het is dus niet puur WordPress dat “faalt” – de server zegt op een gegeven moment gewoon: “ik heb alle processen vol, wacht op je beurt.” Serversoftware zoals PHP-FPM heeft bovendien zijn eigen wachtrijmechanisme. Als alle PHP workers vol bezig zijn, worden nieuwe inkomende verzoeken even in de rij gezet. Maar die rij is niet onbeperkt; als hij te lang wordt of als verzoeken te lang blijven hangen, dan gaan er dingen mis. Je krijgt dan situaties zoals eerder beschreven: time-outs (502/504 errors) of processen die door de server worden afgebroken. Dit is geen fout in WordPress zelf, maar een gevolg van hoe de server met teveel gelijktijdige vragen omgaat (een stukje interne regel die zegt “liever een fout geven dan oneindig laten wachten”).
Neutraal bekeken ligt de oorzaak van uitgeputte PHP workers dus zowel bij wat jouw website aan werk veroorzaakt als bij wat de server maximaal aan kan. WordPress is van zichzelf best efficiënt, maar eenmaal gevuld met plugins en actieve gebruikers kan het een flinke berg aan taken genereren. En de hosting bepaalt hoe hoog die berg mag worden voordat er wachtrijproblemen ontstaan.
Inzicht: begrip van het probleem is de eerste stap
Nu je weet wat PHP workers zijn en hoe ze werken, begrijp je hopelijk beter waarom je WordPress-site soms traag wordt zonder dat er direct een duidelijke fout in je code is. Het is vergelijkbaar met een logistiek probleem: te veel pakketjes en te weinig bezorgers betekent vertraging. Zo ook hier: te veel verzoeken en te weinig workers geeft wachttijd.
Het belangrijkste inzicht is dat “PHP workers uitgeput” geen mysterieus of zeldzaam probleem is, maar een situatie die ontstaat als je site hard moet werken met de middelen die beschikbaar zijn. Door te weten hoe WordPress achter de schermen pagina’s bouwt en waar de knelpunten kunnen zitten, kun je gerichter naar oplossingen kijken. Misschien betekent dat iets aan je site optimaliseren zodat elke pagina minder zwaar is, of misschien betekent het praten met je hostingprovider over wat er mogelijk is qua capaciteit. In ieder geval ben je gewapend met kennis: je weet dat wanneer jouw site traag of onbereikbaar wordt bij drukte, het niet zomaar pech is, maar een concreet mechanisme van te veel werk en te weinig “handjes”.
Hopelijk heb ik je hiermee een duidelijker beeld gegeven van wat er speelt wanneer PHP workers uitgeput raken op jouw WordPress-site. Begrip van het probleem is de eerste stap – zonder meteen in oplossingen te duiken, kun je nu in elk geval herkennen en uitleggen wat er aan de hand is als je site onder de druk bezwijkt. Zo sta je sterker in gesprekken met ontwikkelaars of hostingpartijen, en kun je samen bekijken hoe je voorkomt dat jouw “kassa’s” overbelast raken.