Overzichten van oppervlakkige features vertellen zelden het hele verhaal wanneer je managed WordPress hosting vanuit het perspectief van een developer evalueert. Je wil namelijk onder andere begrijpen hoe PHP threadtoewijzing gelijktijdige verzoekafhandeling beïnvloedt, hoe meerdere cachinglagen samenwerken om databasebelasting te verminderen en of containerisatie in de praktijk daadwerkelijk problemen voorkomt.
Deze gids beschrijft de technische architectuur van Kinsta voor PHP thread management, meerlaagse caching en containerisolatie. We hebben ook citaten van Nikola Djuric toegevoegd, senior support engineer bij Kinsta, over de fijne kneepjes van PHP thread management.
Laten we beginnen met hoe PHP verzoeken daadwerkelijk afhandelt.
PHP threads begrijpen en waarom ze belangrijk zijn voor WordPress prestaties
PHP threads verwerken inkomende ongecachete verzoeken. Elke thread verwerkt één verzoek tegelijk, dus het aantal beschikbare threads heeft direct invloed op hoeveel bezoekers je site gelijktijdig kan bedienen.
Wanneer een bezoeker een pagina laadt die niet in de cache zit, een formulier indient of een item aan zijn winkelwagen toevoegt:
- De webserver ontvangt het verzoek en stuurt het door naar PHP-FPM.
- PHP wijst het verzoek toe aan een beschikbare thread.
- Die thread voert de PHP code uit, haalt gegevens op uit de database en genereert dynamische output.
- Na afronding komt de thread weer beschikbaar.
De meeste mensen realiseren zich niet dat één ongecachet verzoek één PHP thread gebruikt en dat de verwerkingssnelheid afhankelijk is van de reactietijd van PHP plus MySQL.
Gecachete verzoeken slaan dit hele proces over (ze komen sowieso niet met PHP in aanraking). Daarom is een cache HIT de grootste factor in hoeveel threads je daadwerkelijk nodig hebt.
WooCommerce sites, ledendashboards, REST API verkeer en headless setups omzeilen caching veel vaker, waardoor ze sneller threads verbruiken.
Als je gemiddelde API respons bijvoorbeeld 250 milliseconden duurt, kan elke thread vier verzoeken per seconde verwerken. Met acht threads is je theoretische maximale doorvoer dan 32 verzoeken per seconde, maar alleen als elk verzoek ook daadwerkelijk binnen 250 ms wordt afgerond.
Hoe gelijktijdig verkeer PHP threads verbruikt
Het aantal threads is vooral van belang bij gelijktijdig verkeer. Als je site vier threads heeft en zes gelijktijdige ongecachet verzoeken ontvangt:
- Vier verzoeken worden direct verwerkt.
- Twee verzoeken wachten tot er een thread vrijkomt.
Als nieuw verkeer sneller binnenkomt dan threads beschikbaar komen, ontstaat er een wachtrij.
Trage databaseverzoeken maken dit probleem groter. Een databaseverzoek dat bijvoorbeeld 10 seconden duurt, houdt één thread die volledige tijd bezet. Ontvang je drie gelijktijdige verzoeken die elk zo’n traag verzoek triggeren, dan zijn drie threads in totaal 30 seconden geblokkeerd. In die periode moeten de resterende threads al het andere verkeer afhandelen.
Wanneer je daar WooCommerce filters, accountpagina’s of checkout workflows aan toevoegt, neemt de druk op PHP threads nog verder toe.
Voor PHP threads hebben eenvoudige sites vaak genoeg aan vier threads. Maar voor e-commerce is alles onder de zes aan de lage kant, vanwege de hoge cache-bypass ratio.
De relatie tussen het aantal threads en de uitvoeringstijd
Een grove manier om je threadbehoefte in te schatten is:
Benodigde threads ≈ (ongecachete verzoeken per seconde × gemiddelde uitvoeringstijd)
Een site met 10 ongecachete aanvragen per seconde en een gemiddelde uitvoeringstijd van 0,5 seconde heeft dus ongeveer vijf threads nodig om de belasting zonder wachtrijen te verwerken.
Dit laat zien waarom simpelweg meer threads toevoegen geen garantie is voor betere prestaties. Als trage databasequery’s de gemiddelde uitvoeringstijd verhogen van 0,5 naar 2 seconden, verviervoudigt het aantal benodigde threads.
De oplossing zit in snellere uitvoering. Het optimaliseren van verzoeken (query’s), het verminderen van externe API calls en het inzetten van goede object caching kunnen de uitvoeringstijd – en daarmee het aantal benodigde threads – sterk verlagen.
PHP threads toewijzen in Kinsta pakketten
Kinsta wijst PHP threads toe op basis van de CPU- en RAM-resources die beschikbaar zijn voor de container van elke site. Elke Kinsta site draait in zijn eigen LXD container, waardoor resources volledig zijn geïsoleerd.
Globaal per pakket:
- Instapniveau: 2–4 threads met 256 MB per thread. Ideaal voor blogs en sites met vooral statische content en hoge cache HIT rates.
- Middenklasse: 6–8 threads met 256 MB per thread, waarbij sommige Agency pakketten het geheugen uitbreiden naar 512 MB per thread.
- Hogere pakketten: 10–16 threads met 512 MB per thread, geschikt voor drukbezochte of complexe sites.
- Multisite: 8–14 threads, afhankelijk van het pakket.
Je kunt de threadtoewijzing aanpassen in MyKinsta > Info > PHP performance, door de geheugenpool of het aantal threads te verhogen op basis van het verkeersgedrag van je site.
Deze flexibiliteit stelt je in staat PHP af te stemmen op je daadwerkelijke workload, in plaats van te vertrouwen op vaste standaardinstellingen.
Schatten hoeveel PHP threads jouw site nodig heeft
Verschillende typen sites vragen om een andere threadconfiguratie, afhankelijk van hoeveel verkeer de cache omzeilt:
- Sites met statische content. 2–4 threads zijn meestal voldoende, omdat vrijwel al het verkeer via de cache wordt afgehandeld.
- WooCommerce winkels. Start met 8–12 threads, afhankelijk van catalogusgrootte, filtercomplexiteit en checkout volume.
- API-intensieve of headless apps. Baseer je schatting op uitvoeringstijd (bijv. aanvragen van 0,25 s ≈ 4 per seconde per thread).
- Lidmaatschapssites en LMS-platforms. Ingelogde gebruikers omzeilen caching volledig en gedragen zich vergelijkbaar met e-commerce.
De analytics in MyKinsta helpen je inzicht te krijgen in je actuele threadgebruik.
Zie je wachtrijen of time-outs tijdens piekverkeer, dan moet je threadtoewijzing waarschijnlijk worden aangepast.
Wat gebeurt er als je de PHP threadlimiet overschrijdt?
Threaduitputting volgt een herkenbaar patroon:
Er is geen aparte wachtrij voor verzoeken. Het aantal PHP threads bepaalt hoeveel ongecachete verzoeken tegelijk kunnen worden verwerkt. Komt er een verzoek binnen terwijl alle threads bezet zijn, dan moet het wachten. Duurt dat te lang, dan ontstaan 502- of 503 bad gateway errors.
Typische symptomen:
- Verzoeken hopen zich op in NGINX/PHP-FPM wanneer alle threads bezet zijn.
- Eindgebruikers merken als eerste vertraging, zoals ladende spinners, trage checkout of afgebroken AJAX calls.
- 502- of 504-fouten verschijnen zodra de wachtrijcapaciteit is bereikt.
- Herstel treedt meestal binnen 30–120 seconden op zodra trage processen afronden en de cache weer is bijgwerkt.
Trage databaseverzoeken zijn de meest voorkomende oorzaak.
Trage databaseverzoeken kosten PHP threads veel verwerkingstijd en zijn vaak de reden dat sites prestatieproblemen krijgen.
Externe API calls kunnen hetzelfde effect hebben. Betalingsgateways, belastingdiensten en verzend API’s blokkeren vaak threads tijdens het afrekenen.
Voor een goede diagnose moet je meerdere databronnen combineren. Kinsta’s APM tool traceert trage verzoeken en knelpunten, slow query logs tonen databaseproblemen, NGINX wachtrijdata laat achterstanden zien en cache HIT/MISS ratio’s maken duidelijk of caching effectief is.
De oplossing ligt in het verlagen van de uitvoeringstijd:
- Trage databaseverzoeken vragen om indexering, queryoptimalisatie of minder queries.
- Zware plugins kun je soms vervangen door lichtere alternatieven.
- Cron jobs verplaats je bij voorkeur naar daluren.
- Externe API calls hebben baat bij caching, achtergrondverwerking of circuit breakers.
Optimalisatie moet altijd vóór het toevoegen van extra threads komen. Meer threads helpen pas als de gemiddelde uitvoeringstijd onder controle is.
Kinsta’s meerlaagse cachingarchitectuur
Caching verlaagt het aantal verzoeken dat PHP bereikt. Kinsta gebruikt drie lagen:
- Edge caching serveert statische HTML vanaf wereldwijde locaties dicht bij de bezoeker.
- Object caching met Redis vermindert databasebelasting door queryresultaten in geheugen op te slaan.
- Het Kinsta CDN levert statische assets via een wereldwijd netwerk.
Samen minimaliseren deze lagen het aantal verzoeken dat PHP threads en de database bereikt.
Edge caching via Cloudflare
Het wereldwijde edge netwerk van Cloudflare serveert gecachete HTML op basis van cache keys zoals:
- URL en query parameters
- bepaalde cookies
- authenticatiestatus
- WooCommerce winkelwagen- en sessiecookies
Zo wordt voorkomen dat gepersonaliseerde content bij de verkeerde gebruiker terechtkomt.
Cache-bypass regels zorgen er bovendien voor dat dynamische content die actueel moet blijven – zoals WordPress admin of WooCommerce checkout pagina’s – niet wordt gecachet.
Verzoeken die met Edge Cache opgelost worden, omzeilen PHP threads volledig. Als 80% van je verkeer via de Edge Cache komt, heb je PHP threads alleen nodig voor de resterende 20%.
Object caching met Redis
Kinsta biedt Redis als add-on, geïntegreerd met het object caching systeem van WordPress, in plaats van via plugins van derden.
Redis slaat resultaten van databasequery’s op in geheugen, zodat dezelfde queries niet telkens opnieuw hoeven te worden uitgevoerd.
Redis is een prestatieverbeteraar voor goed opgebouwde sites – geen wondermiddel voor zware queries of niet-geïndexeerde tabellen.
Redis helpt vooral wanneer:
- Veel gebruikers dezelfde data opvragen (berichten, producten, categorieën)
- WooCommerce winkels veel categorie- en productchecks uitvoeren
- API’s identieke queries herhalen
Redis versnelt geen trage PHP logica, blokkerende externe API calls of slecht geoptimaliseerde loops.
Kinsta CDN voor wereldwijde levering van assets
Kinsta CDN levert statische assets via meer dan 260 wereldwijde locaties. Dit verlaagt de latency voor internationale bezoekers en voorkomt dat assets vanaf je origin server geladen moeten worden. Afbeeldingen worden automatisch geconverteerd naar WebP waar browsers dat ondersteunen.
Cache control headers bepalen hoe lang assets worden bewaard. Je kunt cacheduur per assettype instellen, afhankelijk van hoe vaak ze wijzigen. Core CSS kan bijvoorbeeld langer worden gecachet. Cache legen voor CDN en edge caching regel je via MyKinsta, afzonderlijk of tegelijk.
Samen zorgen edge caching en het Kinsta CDN ervoor dat HTML, dynamische content en statische assets efficiënt worden afgehandeld, waardoor de meeste verzoeken je origin server of PHP threads nooit bereiken.
Containerisolatie: een oplossing voor het ‘noisy neighbor’ probleem
Managed hosting heeft vaak last van buren die te veel resources verbruiken. Kinsta voorkomt dit met LXD containerisolatie, waarbij elke site een eigen container krijgt met:
- dedicated CPU
- toegewezen RAM
- een geïsoleerd bestandssysteem
- een onafhankelijke softwarestack
Andere sites kunnen jouw resources niet beïnvloeden en problemen in één container hebben geen impact op andere containers.
Containers draaien op geoptimaliseerde hardware, wat zorgt voor stabiele en voorspelbare prestaties, zelfs tijdens verkeerspieken.
Schalen op basis van je behoeften
Heeft je site structureel meer resources nodig dan je huidige pakket biedt, dan kun je verticaal schalen binnen je container.
De PHP Performance add-on biedt bijvoorbeeld extra threads en geheugen voor sites met een hogere behoefte aan rekenkracht.
Je kunt ook upgraden naar een hoger pakket, waarmee je meer resources, threads en geheugen per thread krijgt. Dat is geschikt voor sites die hun huidige capaciteit ontgroeien.
De kernvraag blijft of je optimalisatie of extra capaciteit nodig hebt. Als threads verzadigd raken terwijl CPU gebruik laag blijft, ligt het probleem bij trage queries of externe API calls – niet bij het aantal threads. Meer threads toevoegen zonder die vertragingen aan te pakken, betekent alleen dat meer verzoeken langer moeten wachten.
Samenvatting
PHP thread management, meerlaagse caching en containerisolatie spelen samen een sleutelrol in WordPress prestaties op schaal. Begrijp je hoe threads werken en hoe caching hun belasting verlaagt, dan wordt het eenvoudiger om het juiste pakket te kiezen en je site gericht te optimaliseren.
Wil je zelf ervaren hoe de infrastructuur van Kinsta met WordPress workloads omgaat? Ontdek dan vandaag nog het managed hosting platform van Kinsta.
