Als het zover is om een hostingpakket te kiezen, dan is het belangrijk om het pakket te selecteren dat het beste past bij de eisen van je WordPress site.
Zo zal een e-commerce site met 50.000 maandelijkse bezoeken over het algemeen een stuk meer resources vereisen dan een eenvoudige blog met dezelfde hoeveelheid verkeer.
Dat komt door het feit dat e-commerce sites over het algemeen dynamischer zijn en dus meer resources nodig hebben voor PHP- en databasequery’s.
Dat is waarom PHP workers belangrijk zijn. Lees hieronder meer over wat PHP workers zijn en hoe ze gebruikt kunnen worden voor het verwerken van aanvragen op je site.
Wat is een PHP worker?
Als je met WordPress werkt, dan worden PHP workers onder andere gebruikt om pagina’s te bouwen en vooraf geplande achtergrondtaken te verwerken. Gezien PHP workers rechtstreeks verantwoordelijkheid zijn voor het genereren van HTML pagina’s die de bezoeken op je site ondersteunen, bepalen ze hoeveel niet-gecachete aanvragen jouw site tegelijkertijd kan verwerken.
Stel je voor dat je WordPress site voorzien is van twee PHP workers en er geen paginacaching is ingesteld. Als jouw site vervolgens vier aanvragen tegelijkertijd ontvangt, dan zullen twee van die aanvragen direct verwerkt worden terwijl de twee overige aanvragen aan de beurt komen nadat de eerste twee zijn verwerkt.
Bij Kinsta zijn PHP workers één van de variabelen binnen onze verschillende pakketten. WP 5 pakketten hebben bijvoorbeeld 4 PHP workers per site, terwijl Enterprise pakketten beginnen vanaf 8 PHP workers per site.
Hoewel we server-level caching hebben geïmplementeerd, zijn PHP workers nog steeds erg belangrijk voor aanvragen waarbij de cache wordt omzeild of ontbreekt, omdat zij verantwoordelijk zijn voor deze aanvragen.
Gewoonlijk zijn er veel niet-gecachete aanvragen op e-commerce en community/forumsites. Daarom hebben die sites meer PHP workers nodig om ervoor te zorgen dat elke aanvraag wordt verwerkt zonder vertraging of timeouts.
Als je site is geoptimaliseerd of überhaupt weinig PHP code bevat (geen complex thema en/of weinig WordPress plugins), dan zou elke aanvraag bijna direct moeten worden verwerkt. Zelfs met 2 PHP workers en 4 aanvragen zouden deze aanvragen heel snel verwerkt worden.
Simpel gezegd, een PHP worker voert in de achtergrond op de server PHP code uit.
Hoe gebruikt WordPress PHP workers?
Voordat we ingaan op het optimaliseren van hoe WordPress PHP workers gebruikt, is het belangrijk eerst te begrijpen hoe WordPress precies de PHP workers gebruikt.
Een typische aanvraag in een niet-gecachete omgeving wordt ongeveer op deze manier uitgevoerd:
- De webserver (Nginx of Apache) ontvangt een aanvraag van een bezoeker.
- Nginx leidt de aanvraag door naar PHP.
- PHP maakt een verzoek aan de MySQL database en gebruikt de PHP templates van je thema om een HTML pagina te genereren.
- PHP stuurt een gegenereerde HTML pagina terug naar de webserver.
- De pagina wordt aan de bezoeker aangeboden.
In het bovengenoemde proces kost stap 3 de meeste tijd en resources (CPU en RAM). Een geoptimaliseerde site met zo min mogelijk databasequery’s en efficiënte PHP code zal je relatief snel door de derde stap loodsen.
Een site met slecht geschreven PHP-code die veel gebruikt maakt van onnodige databasequery’s zal daarentegen een stuk meer tijd kwijt zijn met stap 3. Daardoor zullen deze aanvragen de PHP workers bezighouden.
De relatie tussen PHP workers en CPU
Als het op WordPress prestaties aankomt, is het belangrijk rekening te houden met hoe PHP Workers en de beschikbare CPU zich tot elkaar verhouden.
Als problemen met je site worden veroorzaakt door een tekort aan CPU resources, dan zal het verhogen van het aantal PHP workers de prestaties van je site niet verbeteren; het zorgt er alleen voor dat je site meer aanvragen tegelijkertijd kan verwerken – met lagere prestaties per verzoek.
Stel je een brandkraan voor waaraan één slang is bevestigd. Als alleen die ene slang aangesloten is, dan zal de kraan genoeg waterdruk hebben. Maar wat gebeurt er als er tien slangen aan de kraan zijn aangesloten?
De waterdruk wordt over de tien slangen verdeeld, wat betekent dat elke afzonderlijke slang minder waterdruk heeft om goed te functioneren. In deze analogie is de brandkraan de CPU en zijn de slangen de PHP workers.
Met dit in het achterhoofd is er reden genoeg om sceptisch te zijn als je host je adviseert het aantal PHP workers te verhogen zonder het ook over de CPU te hebben.
Hier bij Kinsta zijn onze aangepaste LXD containers geconfigureerd met voldoende CPU en RAM bronnen. We gebruiken ook C2 en C3D virtuele machines die zijn uitgerust met de snelste CPU’s van Google Cloud om de PHP workers van je site efficiënter te laten werken. Onze schaalbare infrastructuur zorgt ervoor dat de PHP workers op jouw WordPress site genoeg CPU resources hebben om optimaal te functioneren.
Laten we nog even terugkomen op het voorbeeld van de brandkraan.
Stel je voor dat je in een situatie zit waar je tien branden met vijf slangen moet blussen. Nadat je de vijf slangen bevestigd hebt realiseer je je dat de kraan nog steeds genoeg waterdruk heeft om goed te kunnen blussen.
In dit geval zou het logisch zijn om nog enkele slangen te bevestigen, omdat de waterdruk van de kraan in dit geval niet het probleem is.
Op eenzelfde manier moet je bij het verbeteren van prestaties zeker kijken naar het verhogen van het aantal PHP workers, maar alleen als je genoeg CPU en RAM ter beschikking hebt.
Zo optimaliseer je het gebruik van de PHP workers op je site
We legden eerder al uit dat PHP workers achtergrondprocessen zijn die door middel van PHP code HTML pagina’s genereren. Wil je het verbruik van PHP workers verminderen en optimaliseren, dan is de meest voor de hand liggende methode om ervoor te zorgen dat de aanvragen minder vragen van je CPU’s en PHP bronnen.
Dat doe je zo.
1. Stel caching in op je WordPress site
De eerste stap om het verbruik van PHP workers te verminderen is door verschillende lagen met caching in te stellen op je WordPress site. Standaard is WordPress een dynamische CMS die elk paginaverzoek on-demand uitvoert.
Voor veel websites, zoals blogs, online tijdschriften en portfolio’s is het echter helemaal niet nodig om PHP te gebruiken voor het genereren van pagina’s.
Caching van pagina’s
De blogpost die je aan het lezen bent, is een perfect voorbeeld van een pagina die niet dynamisch gegenereerd hoeft te worden. Zoals ook bij veel van onze andere artikelen is de inhoud van het artikel bedoeld als statische content. Hierdoor zijn er CPU resources nodig die continu dezelfde pagina’s moeten genereren.
Het is dus veel beter om de PHP van een pagina één keer te laden en de pagina vervolgens te leveren vanuit de cache. Paginacaching heeft veel voordelen ten opzichte van het constant dynamisch genereren vanuit PHP.
Stel je voor dat een blogartikel op je site viraal gaat en binnen een paar uur 100.000 paginaweergaven ontvangt. Zonder paginacaching zouden je PHP workers deze verkeerspiek niet aankunnen, waardoor je server kan crashen.
Met paginacaching wordt alleen de eerste paginaweergave dynamisch gegenereerd. De overige 99.999 verzoeken worden vervolgens aangeboden vanuit de cache van je pagina, wat relatief minder CPU resources gebruikt.
Er zijn twee manieren om paginacaching in te stellen op je WordPress site.
- Server-level paginacaching met een webserver als Nginx.
- Op plugins gebaseerde caching met een WordPress plugin als WP-Rocket.
Voor optimale prestaties adviseren wij waar mogelijk server-level paginacaching te gebruiken. Op Kinsta gebruiken we voor al onze sites Nginx’s FastCGI cache module voor de snelste prestaties.
Als je host geen server-level paginacaching aanbiedt, dan kun je het beste een cachingplugin van WordPress gebruiken om caching op applicatieniveau te implementeren.
Objectcaching
Voor WooCommerce winkels, communityfora en andere WordPress sites die geen gebruik kunnen maken van efficiënte paginacaching, is het toevoegen van persistent object cache als Redis aan je MySQL database een manier om prestaties te verbeteren en de druk op PHP workers te verminderen.
Zonder persistent object cache worden MySQL databasequery’s uitgevoerd voor elk verzoek, zelfs als het resultaat identiek is aan de vorige query.
Een communitysite omzeilt de paginacache vaak vanwege de dynamische aard van een forum. Echter, de databasequery’s die naar de database worden verstuurd om data op te halen voor het bouwen van de pagina, zijn wel vaak identiek.
Voor sites met veel verkeer en die veel gebruik maken van databases is deze manier van verzoeken opvragen inefficiënt, omdat het PHP workers gebruikt om identieke zoekresultaten te genereren voor afzonderlijke verzoeken. Dit probleem wordt door Redis opgelost.
Redis slaat de resultaten van database query’s op in de RAM, waardoor PHP de resultaten op kan pikken van eerder uitgevoerde query’s. Met deze methode van object caching zorg je ervoor dat PHP workers minder CPU resources nodig hebben en minder tijd hoeven te besteden in het uitvoeren van een verzoek, omdat het de noodzaak voor herhaalde databasequery’s weghaalt.
2. Je PHP code optimaliseren
Naast het instellen van paginacaching is het optimaliseren van je PHP code een andere manier om het verbruik van je PHP workers te verminderen. Het “optimaliseren van PHP code” kan binnen WordPress verschillende dingen betekenen. Laten we daar dus wat dieper op ingaan.
Een van de meest geliefde en tevens meest besproken features van WordPress is dat het uitgebreid kan worden met plugins en code.
Als je bijvoorbeeld een widget aan je WordPress site wilt toevoegen die de beurskoersen laat zien, dan is daar een plugin voor. Wil je je eigen code toevoegen aan functions.php om je eigen aangepaste lettertype toe te voegen, dan kan dat ook.
Het uitbreiden van de WordPress code met verschillende features is zo eenvoudig geworden dat we vaak te enthousiast zijn in het toevoegen van features, zonder dat we ons de mogelijke impact realiseren op de prestaties van de site.
Daarom is het eerste wat je kan doen om je PHP-code te optimaliseren, te identificeren welke plugins en code noodzakelijk zijn voor het functioneren van je site en welke niet.
Ga bij plugins voor kwaliteit
Vaak is het aantal plugins op je WordPress site minder belangrijk dan de kwaliteit van die plugins. Als een plugin in de afgelopen zes maanden niet is bijgewerkt, dan adviseren wij een andere plugin te kiezen die wel helemaal actueel is.
De reden daarvoor is dat WordPress constant wordt verbeterd. Als een plugin in jaren niet is bijgewerkt, dan is er een grote kans dat de code niet inhaakt op de meest recente ontwikkelingen en veiligheidsstandaarden van WordPress.
Als een plugin daarentegen elke paar weken van een update wordt voorzien, dan is de kans groot dat de ontwikkelaar kwaliteit serieus neemt. Een betere keuze dus voor je WordPress site.
Gebruik alleen plugins als ze nodig zijn
Als je een eenvoudige taak uitgevoerd wilt hebben, zoals het toevoegen van JavaScript of CSS, is het niet altijd nodig om een plugin te gebruiken. In plaats daarvan kun je zelf code toevoegen in de templates van je PHP thema of in het style.css bestand, door middel van een child-thema.
Als je in de toekomst overweegt een plugin te installeren, kijk dan eerst eens goed of dat echt nodig is. Soms kun je niet om het installeren van een plugin heen, en dat is ook prima. Maar vaak kun je voorkomen dat je extra vertragende code toevoegt door een onnodige plugin te installeren.
Kies lichtgewicht thema’s
Op basis van het monitoren van duizenden WordPress sites is gebleken dat thema’s regelmatig de oorzaak zijn voor matige PHP prestaties. Om in te spelen op de veelzijdigheid van WordPress als een CMS voor algemeen gebruik, hebben sommige ontwikkelaars code geschreven voor thema’s die voor meerdere doelen te gebruiken zijn.
Vaak leidt dit tot veel code en volgepropte thema’s die niet efficiënt gebruik maken van PHP en databasequery’s.
Tijdens de bouw van een WordPress site is het belangrijk een thema te kiezen dat het beste presteert en aanpasbaar is, zoals bijvoorbeeld GeneratePress, OceanWP en Astra.
3. Kies een prestatiegerichte WordPress host
Geloof het of niet, het kiezen van een goede WordPress host die bij je past, kan een hele grote invloed hebben op de prestaties van je site. Gezien de efficiëntie van een PHP workers direct gerelateerd is aan CPU en RAM, kan het hosten van je site op een moderne server met de meest recente hardware helpen bij het optimaliseren van het verbruik van je PHP workers.
Hier zijn twee voorbeelden die laten zien waarom een prestatiegerichte host belangrijk is voor je WordPress site.
High-performance CPU’s
PHP gebruikt CPU resources om code uit te voeren. Een snellere CPU betekent snellere code-uitvoering. Bij Kinsta gebruiken we de snelste servers van Google Cloud – compute-optimized C2 en compute engine general-purpose C3D VMs.
Deze VM’s zijn uitgerust met de nieuwste Intel Xeon processors die kunnen werken op 3,8 GHz all-core turbo. In onze benchmarktests zagen we dat C2 machines 2-4x beter presteerden dan traditionele N1 machines, terwijl de responstijden van C3D machines met nog eens 20% tot 50% verbeterden.
Snelle SSD opslag
Disk I/O snelheid kan ook directe gevolgen hebben op de uitvoering van code en database query’s. Als je database opgeslagen is op een langzame mechanische disk of op een cloud-based SSD met voldoende IOPS (input/output operaties per seconde), dan zullen je PHP workers gedwongen worden meer tijd te steken in het uitvoeren van een aanvraag.
Wij gebruiken de high-performance SSD opslag van het Google Cloud Platform om ervoor te zorgen dat je WordPress site toegang heeft tot een snelle disk I/O.
4. Werk met een performance-expert (optioneel)
Als je niet zeker weet hoe je de prestatieproblemen op je site kan oplossen lossen, dan adviseren wij je om een gekwalificeerde performance-expert in te schakelen die je helpt bij het achterhalen van het probleem.
Door middel van geavanceerde tools als New Relic of de WordPress plugin Query Monitor kan een expert je helpen bij het identificeren van specifieke problemen binnen je code.
Door op de individuele PHP processen en databasequery’s in te zoomen en deze te onderzoeken, is het mogelijk specifieke blokken code te identificeren die de PHP workers van je site het meest belasten.
Houd de volgende tips in het achterhoofd als je je PHP workers aan het optimaliseren bent.
- CPU en RAM moeten parallel met PHP workers geüpgraded worden Als je CPU aan zijn max zit, dan zal het toevoegen van meer PHP workers prestaties niet verbeteren.
- Door je site op een prestatiegerichte host te plaatsen kun je veel prestatieproblemen verhelpen.
- Paginacaching en objectcaching kunnen de werkdruk op PHP workers aanzienlijk verlagen.
- Door kwalitatief hoogwaardige WordPress plugins en thema’s te gebruiken kun je de hoeveelheid onnodige code verminderen.
- Mocht het nodig zijn, werk dan met een prestatie expert om complexe problemen op te sporen en op te lossen.
Gevolgen van het hebben van te weinig PHP workers
Om te zorgen voor snelle en betrouwbare performance van je WordPress site, is het belangrijk ervoor te zorgen dat de site genoeg PHP workers heeft. Wanneer de PHP workers aan het werk zijn terwijl er een verzoek binnenkomt, dan zal er zich een wachtrij vormen.
Als je je limiet van PHP workers hebt bereikt, dan zal de wachtrij oudere aanvragen laten vallen, wat kan leiden tot 504 foutmeldingen of onvolledige aanvragen.
Een andere veelvoorkomende foutmelding die we tegenkomen als er te weinig PHP workers zijn, zijn 502 Bad Gateway foutmeldingen. Die verschillen van 504 fouten, omdat de foutmelding optreedt na een timeout van 60 seconden in de wachtrij van de PHP workers.
Deze foutmeldingen leiden niet alleen tot een slechte gebruikerservaring van bezoekers, maar kunnen ook een negatieve invloed hebben op de SEO van je site.
Er zijn verschillende factoren waardoor pagina’s traag laden of er foutmeldingen optreden. Een voorbeeld is als een niet-gecachete aanvraag veel data uit een database nodig heeft, waardoor het 20-30 seconden kan duren voordat de aanvraag voltooid is.
In dit geval zal een PHP worker voor minstens een halve minuut bezet zijn. Als je site maar twee PHP workers heeft, dan kunnen twee of drie van deze lange verzoeken er al voor zorgen dat er foutmeldingen optreden.
Dit kun je echter oplossen door je MySQL database te optimaliseren en het aantal PHP workers te verhogen, mits de CPU nog niet aan de maximale capaciteit zit.
Het aantal benodigde PHP workers inschatten
Alle hostingpakketten van Kinsta bevatten een vast aantal PHP workers. Het aantal PHP workers in een pakket hebben we bepaald aan de hand van de gegevens die we de afgelopen jaren hebben verzameld over het historische gebruik van resources. In de regel vereisen sites met voornamelijk statische content (zoals bijvoorbeeld artikelen, statische pagina’s en portfolio’s) niet veel PHP workers.
Voor geavanceerdere WordPress sites, die meer dynamische features bevatten, zoals e-commerce of discussiefora, blijkt dat 4 PHP workers een goed beginpunt is. Dit kan echter per site verschillen, omdat elke site een eigen set van unieke thema’s, plugins, databasequery’s en cached-to-uncached ratio heeft.
Soms zijn er dus meer PHP workers nodig om snelle en betrouwbare prestaties te garanderen. Als je niet goed weet hoeveel PHP workers jouw site nodig heeft op Kinsta, dan staat ons sales- en supportteam klaar om je verder te helpen.
Grafiek PHP workerslimiet
De PHP workerslimiet grafiek in MyKinsta analytics laat je zien hoe vaak de PHP engine het maximaal toegewezen aantal workers in het foutenlogboek meldde. Deze grafiek geeft inzicht of prestatie-optimalisaties effect hebben op het verbruik van je PHP workers.
Stel dat je op je site van PHP versie van 5.6 naar 7.4 bent overgestapt, dan zul je waarschijnlijk een daling zien in de beperkingen van PHP workers, omdat PHP 7.4 veel sneller is dan 5.6.
Na overleg met een performance-expert over lange wachttijden van je database zul je, na het overstappen naar een meer lichtgewicht thema, gebruik kunnen maken van de PHP workerslimiet grafiek om te zien wat de gevolgen zijn van de optimalisatie.
Cache analyse grafiek
Je kunt ook gebruik maken van het cache-analyserapport in MyKinsta om de hoeveelheid cacheresultaten, bypasses, misses en expirations te bekijken. Deze data is met name zinvol tijdens het optimaliseren van het gebruik van PHP workers op jouw site.
Cache omzeiling met querystrings
Standaard zullen URL’s met een querystring, zoals https://kinstalife.com/?query=123 de paginacache omzeilen. Soms kunnen querystrings leiden tot pieken van onnodig verbruik van PHP en de CPU.
Als je bijvoorbeeld een link van Facebook bezoekt, dan zie je vaak de querystring ?fbclid= aan het einde van de URL. Soortgelijke UTM trackingparameters zijn vaak te zien als je op een link in een e-mailnieuwsbrief klikt.
Als een bericht op je site viraal gaat en continu met een querystring bezocht wordt, dan kan je een dergelijke URL identificeren met het cache-analyserapport van MyKinsta.
Met deze informatie kun je vervolgens contact opnemen met ons supportteam om voor die specifieke URL de cache te forceren, zodat je je PHP workers ontlast.
Plugins identificeren die veel resources gebruiken
In sommige gevallen kan de cache-analysegrafiek ook gebruikt worden om resource-intensieve plugins en processen te identificeren.
Als je bijvoorbeeld ziet dat de top cache bypass URL wijst naar een bestand binnen de map van een specifieke plugin, dan is er een grote kans dat de plugin zorgt voor een hoge druk op de PHP workers.
Als je veel plugin-gerelateerde aanvragen in je cache bypass lijst ziet, dan kun je met een ontwikkelaar het probleem bespreken of naar een plugin overstappen die minder resources gebruikt.
Samenvatting
Als je een snelle WordPress wilt, dan is je doel om te zorgen voor maximale efficiëntie binnen de backend. Als PHP workers op de juiste manier gebruikt worden, door een balans te vinden tussen het aantal PHP workers, CPU verbruik en code-optimalisatie, dan kan WordPress een extreem goed presterende CMS zijn.
Mocht je vragen hebben over hoeveel PHP workers jij eventueel nodig hebt of als je denkt dat je mogelijk foutmeldingen ziet die komen door een gebrek aan PHP workers, maak dan een ticket aan bij ons supportteam voor ondersteuning.
En nu jij: wat voor optimalisatiestrategieën gebruik jij om jouw WordPress site soepel te laten functioneren? Laat het ons weten in de reacties!
Kan het zijn dat een bepaalde hostingpartij niet werkt met deze PHP workers, maar als alternatief werkt met FastCGI? Ik ben benieuwd of dat inderdaad alternatieven van elkaar zijn en of Fast CGI ook ‘goed’ is?