Shared hosting: wanneer snelle CPU's ondanks een laag aantal kernen van pas komen

Het verschil tussen kernen, threads en CPU-tijd

Een fysieke kern is een rekenunit van de processor. Het besturingssysteem ziet daarentegen logische processors als uitvoerbare eenheden: bij gelijktijdige multithreading kunnen meerdere daarvan de bronnen van een fysieke kern delen. Aan de hand van het aantal is daarom niet direct te zien hoeveel onderling onafhankelijke kernen er voor een hostingaccount beschikbaar zijn.

Bij shared hosting delen meerdere accounts de hardware van een server. Een tarief kan beperken hoeveel CPU-tijd de processen van een account binnen een bepaalde periode mogen verbruiken. Dit CPU-tijdbudget is iets anders dan de toezegging om exclusief gebruik te maken van een fysieke kern. Linux-cgroups vormen een mogelijke technische basis voor dergelijke beperkingen, maar zijn niet de enige mogelijke manier om dit te realiseren.

Als er in het tarief bijvoorbeeld „een vCore“ of „100 procent CPU“ staat, moet je de definitie van de aanbieder controleren. Deze vermelding kan verwijzen naar een reken tijdbudget, zonder dat er permanent een bepaalde kern wordt gereserveerd. Ook uit het totale aantal kernen van de hostserver kan niet worden afgeleid hoeveel rekenkracht een afzonderlijk account daadwerkelijk tegelijkertijd mag gebruiken.

Met ‘gelijktijdigheid’ wordt hier bedoeld hoeveel verzoeken of processen tegelijkertijd kunnen worden verwerkt. Dit hangt onder andere af van proceslimieten, opslagruimte en het beschikbare CPU-budget. CloudLinux kan hiervoor eigen resource-limieten hanteren; of een abonnement deze techniek gebruikt en hoe deze is geconfigureerd, moet je bij de provider navragen.

Beperking van bronnen en beveiligingsisolatie vervullen verschillende taken: een limiet regelt het verbruik, terwijl isolatie bedoeld is om de toegang tussen omgevingen te beperken. De Overzicht van CloudLinux Site Isolation en CageFS legt de bijbehorende beveiligingsmechanismen uit; hieruit volgt op zich geen specifieke CPU-toewijzing.

Waarom GHz alleen niet doorslaggevend is

De kloksnelheid geeft aan hoeveel klokcycli een processor per seconde uitvoert. Een hogere kloksnelheid kan CPU-afhankelijke taken versnellen, maar zegt op zichzelf nog niet hoeveel een website daar baat bij heeft. Verschillende processorarchitecturen verrichten per klokcyclus een verschillende hoeveelheid werk; ook de specifieke programmacode beïnvloedt het resultaat.

Naar Single-core-prestaties Daarnaast spelen ook de cache en het geheugengedrag een rol. Als een proces vaak op gegevens moet wachten, heeft een hogere frequentie mogelijk minder effect dan bij een berekening waarbij de gegevens al snel beschikbaar zijn. Een vergelijking op basis van alleen GHz laat deze verschillen buiten beschouwing en is geen vervanging voor een toepassingsgerichte benchmark.

Een voorbeeld van een beperkt gegevensblad is de AMD EPYC 4564P: voor dit model vermeldt AMD 16 kernen, 32 threads, een basiskloksnelheid van 4,5 GHz en een maximale boost van maximaal 5,7 GHz. Deze gegevens hebben betrekking op de processor, niet op de prestaties van een bepaald hostingpakket.

De Maximale boost is noch een gegarandeerde constante waarde, noch de frequentie die te allen tijde op alle kernen aanwezig is. Evenmin geven de productgegevens aan hoe snel een bepaald shared-hostingpakket een WordPress- of PHP-verzoek verwerkt. Hierbij spelen naast de hardware ook de configuratie, de belasting en de limieten van het pakket een rol.

Wanneer aanbieders met high-frequency CPU-hosting adverteren, vraag daarom naar het specifieke processormodel en het beschikbare budget aan middelen. Voor zinvolle prestatievergelijkingen zijn bovendien gegevens nodig over de softwareversie, de serverconfiguratie, de werklast en de testomstandigheden. Zonder deze gegevens kan een geadverteerde GHz-waarde niet op betrouwbare wijze worden vertaald naar een kortere responstijd.

PHP-verzoeken en parallelle verwerking

Bij een typisch synchroon verzoek verwerkt een PHP-worker de afzonderlijke stappen van zijn PHP-taak grotendeels achter elkaar. Een snellere CPU kan dit deel verkorten als het daadwerkelijk rekenintensief is. Als de worker daarentegen vooral wacht op een database of een externe dienst, blijft het voordeel van een hogere processorkracht voor deze wachttijd beperkt.

De zoekopdracht php single core Dit betekent daarom niet dat een gehele website slechts één kern kan gebruiken. Meerdere verzoeken kunnen door meerdere workers tegelijkertijd worden verwerkt; ook de webserver en de database kunnen tegelijkertijd werken. Bepalend is hoeveel van dit parallelle werk de beschikbare middelen en de betreffende configuratie toelaten.

Bij PHP-FPM is er een limiet pm.max_children het aantal verzoeken dat tegelijkertijd door een pool wordt verwerkt. Als de limiet is bereikt, kunnen extra verzoeken niet onmiddellijk door een andere worker van deze pool worden verwerkt. De limiet zegt echter niets over het totale aantal bezoekers dat een website kan gebruiken.

De Procesbeheer PHP-FPM kent drie bedrijfsmodi: static houdt een vast aantal workers beschikbaar. dynamic past het aantal aan de vraag aan op basis van de configuratie; ondemand start de worker indien nodig. De gekozen bedrijfsmodus bepaalt dus ook wanneer processen beschikbaar zijn of opnieuw worden gestart.

Meer workers leveren niet automatisch meer CPU-tijd op. Ze hebben bovendien werkgeheugen nodig en kunnen bij parallelle uitvoering gezamenlijk tegen een accountlimiet aanlopen. Voor de beoordeling van een shared hosting cpu Het aantal workers en het budget voor resources horen daarom bij elkaar. Niet elk tarief maakt gebruik van PHP-FPM of staat klanten toe om de instellingen daarvan zelf te wijzigen.

CPU-quota bij parallelle belasting

A CPU-quotum bepaalt hoeveel rekentijd een procesgroep binnen een bepaalde periode mag verbruiken. Onder Linux beschrijft cgroup v2 cpu.max dit budget en de bijbehorende periode. Het quotum reserveert dus niet automatisch een exclusieve fysieke kern: het beperkt de in totaal beschikbare CPU-tijd van de groep.

Illustratief rekenvoorbeeld, geen meting: een groep krijgt 100 milliseconden CPU-tijd per periode van 100 milliseconden. Dit komt gemiddeld overeen met de rekentijd van een volledig benutte logische processor. Als twee processen tegelijkertijd op twee beschikbare logische processors rekenen, kunnen ze het gezamenlijke budget theoretisch na ongeveer 50 milliseconden wandtijd opgebruiken.

Als het budget op is, kunnen de processen tot de volgende periode worden afgeremd. De twee workers beschikken dus niet elk over een eigen budget van 100 milliseconden. Of en wanneer ze daadwerkelijk parallel draaien, hangt onder andere af van de scheduler, de beschikbare CPU’s en hun gedrag; het voorbeeld geeft geen concrete responstijd aan.

Voor het onderzoek stelt cgroup v2 in cpu.stat onder andere tellers voor Smoren klaar. Als deze tijdens een representatieve belastingsfase stijgen, wijst dat erop dat de quota is opgebruikt. Een enkele meterstand geeft echter nog geen uitsluitsel over welke aanvraag hierdoor werd beïnvloed of of er daarnaast nog andere knelpunten zijn.

Of deze bestanden binnen het pakket toegankelijk zijn en relevant zijn voor de website, moet je met de provider afstemmen. Bij shared hosting kunnen andere mechanismen worden gebruikt: CloudLinux documenteert bijvoorbeeld eigen LVE-limieten voor de CPU en andere bronnen. Uit het Linux-voorbeeld kan daarom noch de concrete configuratie, noch het gedrag van elk hostingaccount worden afgeleid.

CMS, webshop en achtergrondtaken

Bij een niet-gecachete CMS-pagina voert de server bij het opvragen de applicatielogica uit en haalt hij de benodigde gegevens op. Als een groot deel van de verwerking neerkomt op CPU-belasting, kan een hogere prestatie per kern deze fase verkorten. Dit geldt bijvoorbeeld voor rekenintensieve bewerkingen in de PHP-code, maar niet automatisch voor de totale tijd die nodig is om de pagina te laden.

Als diezelfde verzoek daarentegen voornamelijk afhankelijk is van een databasequery of een externe API, kan het PHP-proces in die tijd slechts in beperkte mate profiteren van een snellere CPU. Voor de beslissing is daarom de verdeling van de responstijd aan de serverzijde van belang: hoeveel tijd wordt besteed aan berekeningen en hoeveel aan het wachten op andere diensten?

Een webwinkel laat zien waarom het antwoord op deze vraag per pagina kan verschillen. Openbare productpagina’s kunnen onder de juiste omstandigheden als kant-en-klaar antwoord worden opgeslagen. Een cachehit kan voorkomen dat PHP de gegevens opnieuw volledig moet verwerken; het winkelmandje en het afrekenproces moeten daarentegen vaak rekening houden met individuele gegevens en blijven dynamisch.

Veel gelijktijdige checkout-verzoeken kunnen daarom meer druk leggen op de workers of het CPU-budget dan evenveel verzoeken voor pagina’s uit de cache. Het aantal bezoekers alleen geeft geen goed beeld van deze belasting: het is van cruciaal belang welke eindpunten tegelijkertijd worden opgevraagd en hoe vaak de cache wordt gebruikt. Bij PHP-FPM beperkt bovendien de pool-instelling pm.max_children het aantal gelijktijdig verwerkte verzoeken.

Een rekenintensieve import in de backend kan op zijn beurt profiteren van snelle individuele verwerking. Als deze parallel aan bezoekersverzoeken wordt uitgevoerd, kunnen de processen mogelijk strijden om hetzelfde CPU-tijdbudget. Of een cronjob of import daadwerkelijk aan dezelfde beperkte groep is toegewezen, hangt af van het tarief en de instellingen daarvan; neem contact op met de provider voordat je een beslissing neemt over de capaciteit.

Voor een zinvolle vergelijking moet je deze werklasten afzonderlijk bekijken: een typische dynamische aanvraag, een fase met meerdere gelijktijdige aanvragen en, indien van toepassing, de import tijdens de lopende bedrijfsvoering. Zo kun je beter vaststellen of de snelheid van een afzonderlijke werkstap of de beschikbare totale capaciteit de belangrijkste factor is.

Waarnemingen en knelpunten vergelijken

Een traag antwoord wijst nog niet op een oorzaak. Het volgende overzicht koppelt typische waarnemingen aan controleerbare mogelijkheden. Het houdt met name rekening met CPU-tijdlimieten, het beperkte aantal workers bij PHP-FPM en het verschil tussen opgeslagen PHP-code en een reeds gegenereerd antwoord.

Elke rij in de tabel is een Hypothese, geen definitieve diagnose. Trage reacties bij parallelle verwerking kunnen bijvoorbeeld samenvallen met een CPU-beperking, maar ook het gevolg zijn van bezette workers of een wachtende database. Controleer daarom indien mogelijk meerdere signalen tegelijkertijd en voor dezelfde werklast, in plaats van op basis van één enkel symptoom te concluderen dat er een tariefwijziging nodig is.

Scheid bij de evaluatie de Reactietijd een verzoek vanuit het doorvoervermogen: een sneller afzonderlijk antwoord betekent niet automatisch dat er bij een hoge gelijktijdigheid ook meer verzoeken per seconde worden verwerkt. Omgekeerd kan een systeem een goed doorvoervermogen behalen en toch afzonderlijke verzoeken langer laten wachten.

Ook de waargenomen laadtijd van de pagina is niet hetzelfde als de responstijd aan de serverzijde. Na het antwoord kunnen bijvoorbeeld nog meer bronnen worden geladen en in de browser worden verwerkt. Een CPU-upgrade bij de hostingprovider heeft alleen betrekking op het betreffende deel aan de serverzijde; voor een eerlijke vergelijking moeten de cachetoestand, de opgevraagde pagina en de mate van parallelliteit gelijk blijven.

Wat de cache betreft, is het bovendien de moeite waard om een onderscheid te maken tussen de begrippen: OPcache slaat gecompileerde PHP-code op en kan zo hercompilatie voorkomen. Een paginacache daarentegen houdt een gegenereerd antwoord bij. Een snelle cachehit bewijst daarom noch dat dynamische verzoeken over voldoende CPU-capaciteit beschikken, noch dat OPcache de applicatielogica vervangt.

Vertragingen en wachttijden herkennen

Begin de diagnose met verzoeken die typisch zijn voor jouw website: bijvoorbeeld een openbare CMS-pagina, een zoekopdracht en, in het geval van een webwinkel, het afrekenen. Noteer of het betreffende antwoord afkomstig is uit de paginacache. Vergelijk vervolgens afzonderlijke verzoeken en een voor jouw project representatief aantal gelijktijdige verzoeken, in plaats van alleen naar het totale aantal bezoekers te kijken.

Scheid indien mogelijk de CPU-tijd de applicatie hangt af van de totale responstijd en de wachttijden bij de database of externe diensten. Als het aandeel van de CPU klein is, kan een snellere processor slechts een overeenkomstig beperkt deel van de aanroep verkorten. Als je geen geschikte meetwaarden hebt, vraag dan de leverancier om beschikbare logbestanden, statistieken of een geschikte analyse.

Controleer bij parallelle belasting of de beschikbare workers volledig worden benut en of de limietmeters stijgen. Bij PHP-FPM is er een limiet pm.max_children het aantal gelijktijdig verwerkte verzoeken van een pool; of je deze waarde of de bezettingsgraad kunt zien, hangt af van het tarief. Linux-cgroup-v2-systemen kunnen in cpu.stat onder andere throttling-tellers weergeven. Een stijgende teller is een reden om het CPU-budget en de meetperiode nader te bekijken.

Als SSH en het betreffende bestand toegankelijk zijn, geeft cat /proc/self/cgroup de cgroup-toewijzing van het aanroepende proces. Hieruit volgt niet dat webverzoeken in dezelfde groep worden uitgevoerd. Overleg met de provider over paden, rechten en interpretatie; ook foutcodes kunnen niet zonder meer worden toegewezen aan een bepaalde limiet van elk shared-hostingsysteem.

Cache controleren en tarieven vergelijken

Controleer eerst welke openbare pagina’s veilig als volledig antwoord kunnen worden opgeslagen. Een Paginacache kan herhaalde dynamische verwerking bij een treffer voorkomen. Gepersonaliseerde inhoud, het winkelmandje en het afrekenen vereisen daarentegen een passende cachestrategie, zodat bezoekers geen vreemde of verouderde gegevens te zien krijgen.

Een andere aanpak is om de werklast bij cache-misses te verminderen: onderzoek trage databasequery’s en verwijder onnodige dynamische verwerking. Bij een externe dienst kan de responstijd ervan doorslaggevend zijn; bekijk dan eerst deze aanroep, in plaats van er zomaar vanuit te gaan dat de CPU de oorzaak is. Welke wijziging helpt, hangt af van het daadwerkelijk trage pad.

Dit moet worden onderscheiden van OPcache: Het slaat gecompileerde PHP-code op, maar vervangt noch een volledige paginacache, noch de uitvoering van de applicatielogica. Controleer de beschikbaarheid en instellingen in de web-runtime-omgeving. De CLI heeft een eigen OPcache-instelling; een blik op de opdrachtregel alleen is daarom geen bewijs voor de configuratie voor webverzoeken.

Voor een tariefvergelijking moet je dezelfde verzoeken met dezelfde softwareversies, een vergelijkbare dataset en een vastgelegde cachetoestand met elkaar vergelijken. Herhaal de vergelijking met dezelfde parallelliteit en houd rekening met de respectievelijk beschikbare CPU-, worker- en geheugenbudgetten. Anders kan er een verschil ontstaan door de testomstandigheden, zonder dat dit iets betrouwbaars zegt over de processorprestaties.

Noteer bovendien apart hoe lang afzonderlijke antwoorden duren en hoeveel verzoeken er in een bepaalde periode worden verwerkt. Een tarief kan voor een enkele aanvraag voordelig lijken, maar bij gelijktijdige belasting toch tegen zijn grenzen aanlopen. Cijfers uit een vergelijking gelden in eerste instantie alleen voor de onderzochte toepassing en de bijbehorende omstandigheden.

Een snellere CPU of een groter budget?

Als een representatieve dynamische aanvraag voornamelijk CPU-werk verricht en noch het aantal workers, noch het geheugen, noch het tijdsbudget een beperking vormen, is een hogere Pro-Kern-prestaties een plausibele tariefoptie. Deze kan het rekenintensieve deel van de afzonderlijke aanvraag verkorten. In hoeverre dit van invloed is op het totale antwoord, hangt echter nog steeds af van de toepassing en de bijbehorende wachttijden.

Als uit de gegevens daarentegen blijkt dat er sprake is van beperking of dat de workers overbelast raken bij meerdere gelijktijdige verzoeken, controleer dan of een grotere Budget. Meer CPU-tijd kan uitkomst bieden wanneer de quota-limiet is bereikt; extra workers hebben tegelijkertijd voldoende geheugen en rekentijd nodig. Als de database of externe diensten het knelpunt vormen, is een hoger CPU-budget op zich geen betrouwbare oplossing.

Voordat je overstapt, loont het de moeite om te vergelijken met het optimaliseren van de bestaande installatie. Een geschikte paginacache of een verbeterde query kan het dynamische werk verminderen, zonder dat je meteen een duurder tarief nodig hebt. Herhaal de diagnose na een wijziging onder vergelijkbare omstandigheden, zodat je het effect ervan kunt onderscheiden van andere invloeden.

A VPS als alternatief voor shared hosting biedt doorgaans meer invloed op de software en configuratie, maar brengt ook meer verantwoordelijkheid met zich mee op het gebied van beveiliging, updates en capaciteitsplanning. Virtuele CPU’s zijn, tenzij de aanbieder dit uitdrukkelijk toezegt, geen exclusieve fysieke kernen. Controleer daarom ook daar de concrete toewijzing van middelen en de contractvoorwaarden.

Vraag de aanbieder, voordat je een beslissing neemt, naar het processormodel, de definitie van het CPU-tijdbudget en hoe er met piekbelastingen wordt omgegaan. Ga ook na welke limieten voor workers en opslag gelden, of achtergrondtaken hetzelfde budget delen en welke limiettellers je kunt inzien. Pas met deze gegevens kun je de geadverteerde CPU-prestaties voor jouw specifieke tarief goed inschatten.