We denken vaak dat het echte risico voor een website-eigenaar of -bureau met meerdere sites is dat een van hun sites offline gaat. Dit is vooral waar als drukke periodes naderen, omdat downtime vooral dan erg kostbaar kan zijn voor je bedrijf en je klanten. Het risico van downtime is echter meetbaar en kan worden aangepakt. Het echte risico voor site-eigenaren? Operationele onzekerheid.
Onzekerheid is het constante gevoel dat er iets mis kan gaan. Het is niet weten of de server het verkeer van een promotiecampagne aankan, niet begrijpen waarom het afrekenen langzaam gaat of niet weten hoe de kosten zullen stijgen als het aantal sitegebruikers toeneemt.
Onzekerheid schuilt in het gebrek aan transparantie van providers, onvolledige of onduidelijke informatie of beloften van onbeperkte resources die je krijgt in plaats van specifieke technische specificaties van een dienst. In de IT-sector is echter niets onbeperkt. Achter een overdreven marketingbelofte gaan vaak de echte beperkingen van de service schuil.
Operationele onzekerheid ondermijnt je vermogen om te voorspellen hoe je site zal presteren, waardoor het onmogelijk wordt om de impact of het succes van een marketinginitiatief te garanderen. Wat gebeurt er als je duizenden dollars investeert in een promotiecampagne en de site dramatisch vertraagt of onder het gewicht van de aanvragen bezwijkt omdat je de limiet van je server niet kende?
Het antwoord is simpel: Verbrand reclamebudget, aangetaste merkreputatie en gederfde inkomsten.
Het voorspellen van het gedrag van je site is waardevoller dan vertrouwen op een belofte van uptime, omdat voorspelbaarheid een directe invloed heeft op je bedrijfsresultaten.
Het risico is niet downtime: Onzekerheid doodt het bedrijf
De meeste hostingproviders verkopen een droom: onbeperkte resources. Het moet echter gezegd worden dat op het gebied van informatietechnologie niets onbeperkt is. Geen enkele resource is onbeperkt: het aantal verzoeken dat een CPU kan verwerken, het aantal gebruikers dat tegelijkertijd toegang heeft tot de database en het aantal PHP-processen per seconde.
Hostingproviders garanderen vaak een hoge uptime-99,999%, eventueel ondersteund door een SLA en je kunt tevreden zijn met deze garantie. Uptime is echter vaak een onbetrouwbare metriek die niets zegt over de werkelijke belasting die je site aankan.
Stel je voor dat je online bent tijdens een marketingproject of een druk koopseizoen, en je merkt dat het 10 seconden duurt voordat je winkelwagentje geladen is omdat tientallen klanten tegelijkertijd bezig zijn met het afronden van hun aankopen. Technisch gezien komt je provider zijn uptime-belofte na. Toch verlaten je klanten gefrustreerd hun winkelwagentje, verlies je omzet en heb je geld verspild aan reclame. En als klap op de vuurpijl heeft je IT-team geen idee wat er aan de hand is of hoe het te repareren. Dat is het risico van onzekerheid.
Als je hostingprovider het woord “onbeperkt” gebruikt, bieden ze je niet meer vermogen. Ze verbergen de realiteit van beperkte resources. Dit gebrek aan transparantie is de belangrijkste factor die operationele onzekerheid veroorzaakt, waardoor je geen beslissingen kunt nemen op basis van werkelijke gegevens.
Wat gebeurt er als je de werkelijke limiet van je hosting bereikt?
Als de belasting van je site aanzienlijk toeneemt, zullen veel providers je site niet uit de lucht halen, maar wel de beschikbare resources verminderen om hun infrastructuur te beschermen. Ze kunnen bijvoorbeeld het aantal PHP-processen verminderen, waardoor je site langzamer wordt. Technisch gezien zal je site nog steeds werken, maar hij zal vrijwel onbruikbaar zijn.
Als er dingen misgaan, neemt de onzekerheid verder toe omdat je niet over de mogelijkheden beschikt om de problemen op te lossen. Je wordt misschien gedwongen om een supportticket te openen en te wachten op menselijke tussenkomst. Soms wordt het probleem nog groter omdat je moet wachten op een Level 2 engineer die kan ingrijpen, en je moet misschien extra betalen voor gekwalificeerde ondersteuning. Meer verloren tijd en omzet, onverwachte kosten en grote hoofdpijn.
Als je de exacte limieten van je plan niet kent (zoals het aantal PHP threads of de geheugenlimieten van je containers), heb je niet de gegevens om een productlancering, een promotieaanbieding of reclame voor het komende winkelseizoen te plannen. De infrastructuur die je site ondersteunt is een soort zwarte doos die je dwingt om te gokken met de resources van je bedrijf.
Of anders gezegd: Als je een rederij was, zou je precies weten hoeveel containers er op een schip passen; als je een fabriek was, zou je weten hoeveel eenheden product je per uur kunt produceren. In de praktijk is capaciteit in de meeste sectoren een bekende variabele. In de hostingsector is dit niet het geval. Providers hebben vaak de neiging om de capaciteiten van de sites die ze hosten te verbergen, en als je niet weet hoeveel PHP threads je hebt, weet je ook niet zeker hoeveel gelijktijdige checkouts je site aankan tijdens een campagne.
De onbekende factor van ROI
ROI is de verhouding tussen netto-inkomen (of winst) en investering en is een maatstaf voor de winstgevendheid van een investering. Het is het resultaat van een eenvoudige formule:
ROI = (Eindwaarde van investering – Kosten van investering) / Kosten van investering
Om de uiteindelijke waarde van je investering te berekenen, moet je de productiecapaciteit ervan kennen. Als je $2.000 uitgeeft aan infrastructuur, maar de grenzen ervan niet kent, weet je niet of je het juiste bedrag uitgeeft, middelen verspilt of te weinig inkoopt.
Maar het gaat niet alleen om infrastructuurkosten. Als je $20.000 hebt geïnvesteerd in een reclamecampagne die genoeg verkeer zou opleveren om 100 transacties per seconde te vereisen, maar de infrastructuur waarop je site draait kan maar een fractie daarvan aan, dan keldert de uiteindelijke waarde van je investering. Onder deze omstandigheden is het onmogelijk om de ROI in te schatten en dus datagestuurde beslissingen te nemen.
Aan de andere kant, als de hostinginfrastructuur transparant is, weet je hoeveel PHP threads per seconde beschikbaar zijn, hoe lang het afrekenproces duurt en hoeveel transacties per seconde je site kan verwerken. Je kunt de uiteindelijke waarde van je investering berekenen en je management voorzien van door gegevens ondersteunde ROI-schattingen.
Op deze manier wordt je hosting meer dan een terugkerende kostenpost: het is een controleerbaar, optimaliseerbaar bedrijfsmiddel, waardoor je met vertrouwen kunt plannen en investeren, zonder overprovisioning of giswerk over je capaciteit.
Met Kinsta is het kiezen van het optimale pakket eenvoudiger. Je hoeft je niet aan te melden voor een te duur pakket alleen omdat je bang bent voor het onbekende. Je kunt het juiste pakket kiezen voor je site en bedrijfscapaciteit en alleen opschalen als dat nodig is. Lees verder om te ontdekken hoe Kinsta operationele onzekerheid wegneemt.
Van gokken naar datagestuurde beslissingen: Hoe Kinsta onzekerheid elimineert
Om onzekerheid te elimineren heb je geen leverancier nodig die je het onmogelijke belooft. Je hebt iemand nodig die je een stappenplan kan geven om te volgen.
Bij Kinsta vind je geen zwarte doos, maar een transparante architectuur en duidelijke technische specificaties waarmee je kunt stoppen met gokken en kunt beginnen met het berekenen van de winstgevendheid van je investeringen.
PHP threads: Je echte capaciteit
Een PHP thread is een specifiek proces dat een niet-gecachet verzoek naar je site afhandelt. PHP threads genereren niet alleen de HTML voor de ongecachete pagina’s van je site, maar voeren ook alle achtergrondbewerkingen van je site uit. Dus:
- Elke keer dat een klant een product toevoegt aan zijn winkelwagentje of zijn profiel bijwerkt, verwerkt een PHP thread de bewerking en werkt de database bij.
- Elke keer dat WordPress een achtergrondbewerking uitvoert, zoals het publiceren van een gepland artikel, het verzenden van transactiemails of het synchroniseren van de voorraad met je magazijn, verbruikt het een PHP thread.
- Elke keer dat je site interactie heeft met een externe service, zoals het verwerken van een betaling met Stripe, het versturen van gegevens naar je CRM of het bevragen van een API van een derde partij, moet er een PHP thread open blijven om de externe handshake af te handelen.
- Elke keer dat er een query wordt uitgevoerd op de database van je site omdat de gevraagde gegevens niet in de cache zijn opgeslagen, wordt er een PHP thread geactiveerd om de database te bevragen en de resultaten terug te sturen.
Als je niet genoeg PHP threads hebt, kan een eenvoudige bewerking op de achtergrond, zoals een automatische update, ze uitputten, waardoor je klanten in hun winkelwagentje blijven hangen. Als je niet weet hoeveel PHP threads je beschikbaar hebt, kun je je investeringen niet plannen.
Bij Kinsta weet je precies hoeveel PHP threads je WordPress site container bevat.
Geen verborgen limieten: De architectuur van Kinsta is transparant
In plaats van vage of overdreven beloften, weet je bij Kinsta precies wat de containercapaciteit van je site is. Je weet precies hoeveel PHP threads zijn toegewezen aan de container van je site, en je weet ook hoeveel CPU’s en hoeveel RAM je site heeft, welke datacenters voor jou beschikbaar zijn en elk ander detail over je plan.
Bij Kinsta streven we ernaar om al onze bronnen voortdurend bij te werken, van onze blog tot onze documentatie, changelog en nieuwsbrief, om onze klanten te voorzien van de informatie die ze nodig hebben om hun sitehosting optimaal te beheren en hun bedrijfsstrategieën nauwkeurig te plannen.
De tabel hieronder toont bijvoorbeeld de standaard PHP pool, het aantal threads en het geheugen per thread in elk Kinsta pakket:
| Plan | Poolgrootte | Aantal threads | Geheugen per thread |
|---|---|---|---|
| Single 35k bezoeken
Single 20GB bandbreedte |
512MB | 2 | 256MB |
| Single 65k bezoeken
Single 40GB bandbreedte |
1GB | 4 | 256MB |
| Single 125k bezoeken
Single bandbreedte 65GB |
1.5GB | 6 | 256MB |
| Single 315k bezoeken
Single 125GB bandbreedte |
1.5GB | 6 | 256MB |
| Single 500k bezoeken
Single 250GB bandbreedte |
2GB | 8 | 256MB |
| Single 750k bezoeken
Single 500GB bandbreedte |
2GB | 8 | 256MB |
| Single 1.25M bezoeken
Single bandbreedte 750GB |
5GB | 10 | 512MB |
| Single 1.9M bezoeken
Single 1125GB bandbreedte |
6GB | 12 | 512MB |
| Single 2.5M bezoeken
Single 1500GB bandbreedte |
7GB | 14 | 512MB |
| Single 3.15M bezoeken
Single 1875GB bandbreedte |
8GB | 16 | 512MB |
| WP 2 | 512MB | 2 | 256MB |
| WP 5 | 1GB | 4 | 256MB |
| WP 10 | 1GB | 4 | 256MB |
| WP 20 | 1.5GB | 6 | 256MB |
| WP 40 | 1.5GB | 6 | 256MB |
| WP 60 | 4GB | 8 | 512MB |
| WP 80 | 5GB | 10 | 512 MB |
| WP 120 | 6GB | 12 | 512 MB |
| WP 150 | 7GB | 14 | 512 MB |
| Agency 20 | 3GB | 6 | 512 MB |
| Agency 40 | 3GB | 6 | 512MB |
| Agency 60 | 4GB | 8 | 512MB |
Het aantal PHP threads en het aan elke thread toegewezen geheugen liggen echter niet vast. Als je specifieke eisen hebt, kun je het aantal PHP threads voor elke site in MyKinsta aanpassen met de PHP Performance add-on onder Sites > sitenaam > Info > PHP performance > Wijzigen.
Zelfs degenen met een dedicated server kunnen het aantal PHP threads en/of de geheugenpool die aan elke thread wordt toegewezen aanpassen door deze specifieke instructies te volgen.
Hoe de procestijd te meten met Kinsta APM
Om je te helpen begrijpen hoe lang je afrekenproces duurt, biedt Kinsta een ingebouwde Application Performance Monitoring (APM) tool waarmee je PHP prestatie knelpunten kunt identificeren op je WordPress site en de tijd kunt berekenen die individuele processen in beslag nemen, zonder je te abonneren op monitoring diensten van derden zoals New Relic.
Onze APM tool is beschikbaar zonder extra kosten voor alle plannen en biedt gedetailleerde informatie over de PHP processen van je WordPress site, MySQL database queries, externe HTTP aanroepen en meer.

Zodra je site monitoring inschakelt, krijg je toegang tot de gegevens die het systeem heeft verzameld en verdeeld over vier tabbladen:
- Transacties: Hier vind je informatie over de totale transactietijd en de langzaamste transacties.
- WordPress: Dit tabblad geeft WordPress-specifieke informatie, waaronder de uitvoeringstijden van plugins en hooks.
- Database: Dit tabblad bevat details over de uitvoeringstijden van databasequery’s.
- Extern: Hier vind je details over externe HTTP-verzoeken.
Zodra je de gemiddelde uitvoeringstijden voor processen zoals het winkelwagentje hebt bevestigd, kun je precies berekenen hoeveel PHP threads je nodig hebt om je klanten een optimale kassa-ervaring te bieden. Zoals we al eerder zeiden, heeft een site die snel laadt minder PHP threads nodig, wat zich vertaalt in lagere kosten voor jou en een betere winkelervaring voor de gebruiker.
Dit is nog een reden waarom het cruciaal is om een hostingprovider te kiezen die topprestaties garandeert en je site optimaliseert. Daarom biedt Kinsta je niet alleen een extreem snelle cloudarchitectuur, maar ook gratis Cloudflare-integratie op alle pakketten, waardoor al onze klanten een krachtig CDN krijgen om de statische resources van je site te serveren vanaf de locatie die het dichtst bij je bezoekers is. Naast het CDN profiteren onze klanten van Cloudflare’s Edge Caching, waarmee hele HTML-pagina’s in de cache worden geplaatst en het grootste deel van de belasting van de origin server naar Cloudflare’s edge servers wordt verplaatst.
Kortom, Kinsta biedt je de infrastructuur en tools om sites te bouwen die supersnel laden, met een lagere serverbelasting, minder PHP-threadvereisten en een lager serverbandbreedteverbruik.
Hoe bereken je het aantal PHP threads dat je nodig hebt
Als je het aantal PHP threads weet dat is toegewezen aan de container van je site en de gemiddelde tijd die het kost om je winkelwagentje te verwerken, dan weet je hoeveel transacties per seconde je site aankan:
PHP threads / Gemiddelde verwerkingstijd = Max dynamische verzoeken per seconde
Om te begrijpen hoe je deze eenvoudige formule kunt toepassen, kun je twee verschillende scenario’s bekijken.
Eerste scenario: Trage hosting en ongeoptimaliseerde website
Je hebt 10 PHP threads en je checkout duurt 2 seconden:
Berekeningen: 10 / 2 = 5 verzoeken per seconde
Tweede scenario: Snelle hosting en geoptimaliseerde website
Je hebt 10 PHP threads en je checkout duurt 0,5 seconden:
Berekeningen: 10 / 0,5 = 20 aanvragen per seconde
Ongeacht de beschikbare bandbreedte zal je kassa in het eerste scenario vastlopen bij de zesde gelijktijdige klant, terwijl hij in het tweede scenario tot 20 gelijktijdige aanvragen per seconde zal ondersteunen. Dit is het verschil tussen een snelle, prestatie-geoptimaliseerde site en een website die draait op een hosting die niet is afgestemd op jouw bedrijf.
Geïsoleerde resources: Elimineer het risico van “noisy neighbors”
Bij traditionele gedeelde hosting en zelfs bij sommige VPS-configuraties worden resources gedeeld tussen sites die op dezelfde server worden gehost. Dit betekent dat onzekerheid over de capaciteit van je site wordt verergerd door onzekerheid die voortkomt uit de activiteit van andere sites op dezelfde server. Dit is het risico dat inherent is aan het noisy neighbor effect.
Elke door Kinsta gehoste website draait in een geïsoleerde softwarecontainer die alle software-resources bevat die nodig zijn om de site te draaien (Linux, NGINX, PHP, MySQL), wat betekent dat de software waarop elke site draait 100% privé is en niet wordt gedeeld, zelfs niet tussen je eigen sites.

Op Kinsta heeft elke container standaard 12 CPU’s en 8 GB RAM, en elke testomgeving heeft 1 CPU en 8 GB RAM.
Je kunt kiezen uit 27 datacenters verspreid over 5 continenten en je site wordt beveiligd door onze gratis Cloudflare integratie.
- Johannesburg, South Africa (af-johannesburg-1)
- Batam, Indonesia (ap-batam-1)
- Melbourne, Australia (ap-melbourne-1)
- Mumbai, India (ap-mumbai-1)
- Osaka, Japan (ap-osaka-1)
- Seoul, South Korea (ap-seoul-1)
- Singapore,Singapore (ap-singapore-1)
- Sydney, Australia (ap-sydney-1)
- Tokyo, Japan (ap-tokyo-1)
- Montreal, Canada (ca-montreal-1)
- Toronto, Canada (ca-toronto-1)
- Amsterdam, Netherlands (eu-amsterdam-1)
- Frankfurt, Germany (eu-frankfurt-1)
- Madrid, Spain (eu-madrid-1)
- Milan, Italy (eu-milan-1)
- Paris, France (eu-paris-1)
- Stockholm, Sweden (eu-stockholm-1)
- Zurich, Switzerland (eu-zurich-1)
- Jerusalem, Israel (il-jerusalem-1)
- Riyadh, Saudi Arabia (me-riyadh-1)
- Santiago, Chile (sa-santiago-1)
- Sao Paulo, Brazil (sa-saopaulo-1)
- London, United Kingdom (uk-london-1)
- Ashburn, VA (us-ashburn-1)
- Chicago, IL (us-chicago-1)
- Phoenix, AZ (us-phoenix-1)
- San Jose, CA (us-sanjose-1)
Dit is transparantie van Kinsta.
Kies zekerheid boven vage beloften
Bij het runnen van een online bedrijf wordt de betrouwbaarheid van een hostingpartner niet afgemeten aan het aantal negens dat ze in hun uptime-garantie noemen, maar aan hun transparantie over de werkelijke capaciteit van je site en de architectuur die deze ondersteunt.
Operationele onzekerheid is een sluipmoordenaar voor je budget. Het verhindert je om te schalen, brengt je marketinginspanningen in gevaar en houdt je IT-team voortdurend alert.
Het tegengif tegen onzekerheid is een hostingpartner die zekerheid biedt over de capaciteit van je site, duidelijk je PHP thread count definieert, volledig geïsoleerde omgevingen biedt en je real-time alles laat tracken met een prestatiemonitoringstool.
Met Kinsta kun je de capaciteit van je website controleren met dezelfde precisie die je toepast op alle andere onderdelen van je bedrijf, van inventaris tot financiën.
Vertrouw niet op beloften van onbeperkte resources. Wees praktisch en kies een hostingpartner die een stappenplan biedt om je bedrijf te begeleiden terwijl het groeit.
Klaar om de sprong te wagen? Bekijk onze pakketten!