Server-CPU-benchmarking voor PHP: tests voor reële webhosting-workloads

Wat een PHP-benchmark moet uitwijzen

Een PHP-CPU-benchmark kan in de eerste plaats laten zien hoeveel tijd een systeem nodig heeft voor een bepaalde rekenopdracht. Dit is vooral nuttig wanneer een afzonderlijk verzoek veel tijd kwijt is aan PHP-berekeningen. Een hogere Prestaties van een enkele kern kan de verwerkingstijd van dergelijke taken verkorten; uit één CPU-waarde alleen kan echter niet de responstijd van een hele website worden afgeleid.

Een tweede vraag betreft het gedrag van de applicatie bij gelijktijdige toegangen: hoeveel correcte antwoorden levert deze per seconde, en hoe lang moeten gebruikers daarbij wachten? Hiervoor is een Webhosting-benchmark via HTTP zinvol. Het brengt het traject in kaart via webservers en PHP, en eventueel ook via de database, de cache en het netwerk. Juist deze combinatie maakt het praktijkgericht, maar maakt het onmogelijk om een geïsoleerde uitspraak over de CPU te doen.

De derde vraag betreft het knelpunt. Als een verzoek bijvoorbeeld wacht op een databasequery, zegt een snellere rekenopdracht weinig over de totale doorlooptijd. Ook een cache beïnvloedt het resultaat: als een pagina al vóór PHP volledig wordt geleverd, meet de aanroep niet de uitvoering van de dynamische toepassing.

Bij parallelle belasting kan de PHP-FPM-pool bovendien beperken hoeveel verzoeken tegelijkertijd worden verwerkt. De statuspagina geeft onder andere informatie over bezette processen en verzoeken in de wachtrij. Een groeiende wachtrij is daarom een aanleiding om een diagnose te stellen, en geen direct bewijs dat de CPU te traag is.

Bij het kiezen van een hostingpakket helpt het om deze vragen afzonderlijk te bekijken: eerst de vergelijkbare werkeenheid, vervolgens het gebruik bij een lage en hogere belasting en ten slotte de resources die het resultaat beperken. Hoe CPU, werkgeheugen en opslag in principe op elkaar inwerken, wordt uitgelegd in het artikel over Hardware voor hoogwaardige webhosting.

CPU-scores en applicatietests van elkaar onderscheiden

A Microbenchmark herhaalt een kleine, nauwkeurig gedefinieerde taak. Met PHPBench kan bijvoorbeeld een functie voor gegevensverwerking onder vastgestelde voorwaarden worden onderzocht. Het resultaat helpt bij het vergelijken van deze functie en de uitvoeringsomgeving ervan; het geeft automatisch geen beeld van een volledige aanvraag, noch van de prestaties van een CMS of webwinkel.

Een HTTP-applicatietest geeft antwoord op een andere vraag: hoe reageert de gekozen applicatie via de daadwerkelijk gebruikte webstack? De test houdt bijvoorbeeld rekening met PHP-FPM, de database en caches, voor zover deze betrokken zijn bij de geteste aanroep. Daardoor is deze test geschikt voor het beoordelen van een hostingaanbod, maar kan hij op zichzelf niet aantonen welke component verantwoordelijk is voor een verschil.

SPEC CPU vult dergelijke tests aan met gestandaardiseerde, rekenintensieve workloads. SPEC CPU 2026 bevat integer- en floating-point-suites, evenals ‘Speed’- en ‘Rate’-resultaten. ‘Speed’ verwijst naar de tijd die nodig is voor taken, ‘Rate’ naar de doorvoersnelheid. Een Speed-waarde is niet automatisch een zuivere single-core-waarde: SPEC wijst bij de integer Speed-tests van de 2026-suite op extra parallelliteit.

Voor een betrouwbare SPEC-vergelijking moeten de testsuite, de metriek en het type resultaat basis of piek overeenkomen. Ook het volledig geteste systeem speelt een rol: naast de processor beïnvloeden onder andere het geheugen, de compiler en de configuratie het resultaat. Gepubliceerde waarden zijn daarom geen op zichzelf staande eigenschap van het CPU-model en vormen geen vervanging voor een PHP-test.

SPEC CPU 2017 en CPU 2026 maken gebruik van verschillende testsuites; hun cijfers zijn niet op dezelfde schaal weergegeven. Wie een voorselectie maakt, doet er daarom goed aan het volledige resultatenrapport te vergelijken in plaats van een verkorte ranglijst. Of een kandidaat geschikt is voor de eigen toepassing, blijkt pas uit een goed opgezette toepassingstest.

Vergelijkbare testomstandigheden vaststellen

Een eerlijke vergelijking begint met dezelfde versie van de applicatie en een vergelijkbare dataset. Ook de gekozen route en het verwachte antwoord moeten overeenkomen: een productpagina met veel databasetoegangen beantwoordt een andere vraag dan een eenvoudige API-functie. Controleer daarom niet alleen of er een antwoord binnenkomt, maar ook of de inhoud ervan aansluit bij de beoogde taak.

Noteer zowel de PHP-versie en -uitbreidingen als de webserver, de PHP-FPM-configuratie en de database. Ook het netwerkpad tussen de belastinggenerator en de applicatie moet in het rapport worden opgenomen. Verschillende paden of databaselocaties kunnen de gemeten responstijd beïnvloeden, zelfs als de PHP-uitvoering op beide systemen even snel zou zijn.

Het is vooral belangrijk om een onderscheid te maken tussen CLI en PHP-FPM: Een test via de opdrachtregel controleert niet automatisch dezelfde runtime-configuratie als een HTTP-verzoek. Documenteer voor beide contexten de daadwerkelijk gebruikte OPcache- en JIT-instellingen. Het effect en de standaardinstellingen hiervan zijn onder andere afhankelijk van de PHP-versie; een algemene aanname volstaat niet voor de vergelijking.

De Cache-status moet vergelijkbaar zijn. Een koude cache en een reeds opgewarmde cache geven antwoord op verschillende vragen; beide kunnen relevant zijn, maar moeten afzonderlijk worden geëvalueerd. Hetzelfde geldt voor de hoeveelheid gegevens en testgegevens: als de omvang van het werk verandert, kan een tijdsverschil niet meer eenduidig aan het systeem worden toegeschreven.

Noteer bovendien het CPU-model, de toegewezen vCPU’s en de zichtbare resource-limieten, evenals de gekozen belasting en het aantal herhalingen. Als er bewust twee verschillende hostingpakketten worden vergeleken, geeft het resultaat een beeld van hun respectievelijke totale configuratie. Verschillen op het gebied van processor, limieten, database of caching mogen dan niet zonder verdere diagnose louter als een CPU-voordeel worden geïnterpreteerd.

Geschikte workloads en meetgrootheden kiezen

De keuze van de test hangt af van de vraag die je wilt beantwoorden. Een Microbenchmark onderzoekt een beperkte rekenopgave; een HTTP-test houdt rekening met het traject door de webstack. SPEC-resultaten vullen de vergelijking aan met gestandaardiseerde, CPU-intensieve systeemtests, maar zijn geen vervanging voor het testen van de eigen PHP-toepassing.

Voor een enkele dynamische verzoek kies je een representatieve pagina of API-route en begin je met een lage mate van parallelliteit. De route moet daadwerkelijk PHP uitvoeren: een antwoord dat volledig uit een upstream paginacache wordt geleverd, zou weliswaar een geldige cachetest zijn, maar zegt weinig over de PHP-verwerking.

Voor gelijktijdige bezoekers test je hetzelfde eindpunt bij verschillende vastgestelde belastingniveaus. Zo kun je vaststellen of de responstijden en de succesvolle doorvoer veranderen naarmate de parallelliteit toeneemt. Bij een database-intensieve route moeten de gegevensset, de locatie van de database en de cachetoestand tussen de vergelijkende tests hetzelfde blijven.

Een CPU-intensieve functie uit de applicatie kun je aanvullend geïsoleerd onderzoeken met PHPBench, bijvoorbeeld een gegevensverwerking zonder netwerktoegang. Een beter resultaat wijst in eerste instantie alleen op een voordeel voor deze functie onder de gekozen uitvoeringsomstandigheden. Of dit een merkbaar voordeel oplevert voor een volledige pagina, moet uit de applicatietest blijken.

Een staging-test uitvoeren met wrk

Test alleen met uitdrukkelijke toestemming in een geïsoleerde testomgeving. Stel een veilige, representatieve leesroute in en gebruik geschikte testgegevens. Bepaal vóór de start een maximale belasting en afbrekingscriteria, zoals optredende fouten, time-outs of verstoring van andere diensten.

De volgende opdracht is bedoeld voor een terminal op een lokale staging-instantie die speciaal voor dit doel is opgezet. De voorbereide route moet bereikbaar zijn op poort 8080; de opdracht zorgt namelijk voor werkelijke belasting en is niet bedoeld voor een onbekend of productief systeem.

wrk -t2 -c4 -d30s --latency http://127.0.0.1:8080/

De aanroep maakt gebruik van twee threads voor het genereren van belasting, vier open verbindingen en een looptijd van 30 seconden. De optie --latency vraagt om een gedetailleerde weergave van de latentie. Vier verbindingen vormen in dit geval een gekozen uitgangspunt voor dit voorbeeld; het is geen algemeen geldende aanbeveling voor het aantal bezoekers of de capaciteit van een server.

De standaard percentieluitvoer van wrk bevat echter geen p95. Voor een reproduceerbare p95-analyse moet je het volgende Lua-script op de belastinggenerator opslaan als percentiles.lua. De p50- en p95-waarden uit de latentie-statistiek worden weergegeven in microseconden; als je deze door 1.000 deelt, krijg je milliseconden.

function done(summary, latency, requests)
  io.write(string.format("p50: %.0f us\n", latency:percentile(50.0)))
  io.write(string.format("p95: %.0f us\n", latency:percentile(95.0)))
end

Start voor de daadwerkelijke meting dezelfde lokale staging-test met het script. Het bestandspad geldt voor een terminal in de map waar het scriptbestand zich bevindt. Ook deze uitvoering zorgt voor belasting; documenteer de twee weergegeven percentielen, samen met fouten en de afzonderlijk gecontroleerde kwaliteit van de antwoorden.

wrk -t2 -c4 -d30s --latency -s percentiles.lua http://127.0.0.1:8080/

Plan een aparte Opwarmfase voordat je de eigenlijke meetruns vastlegt. Herhaal vervolgens elk vastgestelde belastingsniveau en varieer indien mogelijk de volgorde van de vergelijkingssystemen. Noteer hoe lang het opwarmen heeft geduurd en of de cache zich aan het begin van de meting in de gewenste toestand bevond.

Verhoog het aantal verbindingen alleen binnen de afgesproken grenzen en controleer na elke stap de afbrekingscriteria. Houd ook de belastinggenerator in de gaten: als deze zelf volledig bezet is, kan dit het resultaat beperken. Controleer daarnaast de statuscodes en de inhoud van de antwoorden; een snel weergegeven foutpagina of een onjuist antwoord telt niet als een succesvol applicatieverzoek.

Belastingsniveaus en resultaten vastleggen

Een meetrapport koppelt de cijfers aan de omstandigheden waaronder ze zijn verkregen. Noteer voor elke run de omgeving, het eindpunt, de cache-status en het belastingsniveau, samen met de resultaten. Het onderstaande schema maakt onder andere gebruik van gegevens die door wrk of de FPM-statuspagina worden verstrekt; de inhoudelijke controle van de antwoorden moet je zelf aanvullen.

De mediaan geeft het midden van de waargenomen responstijden weer. De p95 is de waarde die 95 procent van de gemeten antwoorden niet overschrijdt. Samen geven beide grootheden aan of naast een typisch verzoek ook het langzamere deel van de verdeling verandert. Interpreteer ze altijd in combinatie met fouten en time-outs.

Maak onderscheid tussen een vast aantal verbindingen en een vooraf vastgestelde verzoekfrequentie. Bij een verbindingsgebaseerde test, zoals in het voorbeeld, kunnen trage antwoorden ertoe leiden dat er via dezelfde verbindingen minder nieuwe verzoeken per seconde worden gegenereerd. De gemeten latentie geeft dan niet zonder meer het gedrag weer bij een onveranderd hoge aankomstsnelheid.

Vergelijk daarom alleen voldoende vergelijkbare belastingpunten: dezelfde route en responscontrole, vergelijkbare cache-toestanden, evenals hetzelfde belastingsmodel en hetzelfde belastingsniveau. Een lage p95 bij geringe parallelliteit is niet direct vergelijkbaar met een p95 bij overbelasting. Rapporteer meerdere runs en de spreiding daarvan, in plaats van één enkele gunstige waarde als resultaat te presenteren.

FPM en hulpbronnenlimieten onderzoeken

Als bij een toenemende belasting zowel de wachtrij als de p95-responstijd toenemen, is het de moeite waard om de PHP-FPM-pool eens te bekijken. Vergelijk de huidige waarden voor active processes, idle processes en listen queue met de ingestelde bovengrens pm.max_children. Als alle toegestane processen actief zijn, er geen vrije processen zijn en er verzoeken in de wachtrij staan, duidt dat op een Zwembadgrens of werknemers die al lang in dienst zijn, maar niet automatisch op een te trage CPU.

De advertentie max children reached Dit geeft daarentegen aan dat de proceslimiet al eerder is bereikt sinds de start van de pool. Dit feit op zich wijst noch op een huidige wachtrij, noch op het feit dat alle bestaande processen op dit moment bezig zijn. Evenmin betekent het maximale aantal bestaande processen dat ze allemaal actief zijn.

Workers kunnen ook wachten op databasequery’s of andere externe diensten. Vergelijk daarom de poolstatus en het CPU-gebruik met de waargenomen responstijden: een volle wachtrij bij een laag CPU-gebruik wijst erop dat je eerst de wachttijden en de bezetting van de workers moet onderzoeken. Een groter aantal workers is niet automatisch de oplossing, omdat extra processen ook resources nodig hebben.

De FPM-statuswaarden gelden voor de betreffende pool; tellers worden bij een herstart gereset. Noteer daarom de pool en het tijdstip van de herstart in het meetlogboek en vergelijk de tellerstanden alleen binnen een relevante periode. Beveilig een geactiveerde statuspagina tegen ongeoorloofde toegang, aangezien deze bedrijfsinformatie over de pool openbaar maakt.

Bij VPS en shared hosting staat een toegewezen vCPU niet automatisch gelijk aan een exclusieve fysieke kern. Waar cgroup-v2-gegevens beschikbaar zijn, laat cpu.max de geconfigureerde CPU-bandbreedtebeperking; cpu.stat kan onder andere tellers voor Smoren bevat. Wijzigingen in deze tellers tijdens een run helpen bij het vaststellen of er sprake is van een effectieve begrenzing.

Controleer indien mogelijk ook de bovenliggende cgroups: een daar ingestelde limiet kan de beschikbare rekentijd beïnvloeden, zelfs als de direct zichtbare configuratie ruim lijkt. Niet elke teller geeft de overgenomen limieten volledig weer. Als deze informatie in het hostingpakket ontbreekt, behoort de beperkte zichtbaarheid uitdrukkelijk tot de beperkingen van de evaluatie.

Verschillen en meetfouten herkennen

Een enkele testrun kan een toevallig gunstig of ongunstig beeld opleveren. Herhaal dezelfde belastingsniveaus op vastgelegde tijdstippen en varieer waar mogelijk de volgorde van de vergelijkingssystemen. Juist bij gedeelde bronnen kan het beschikbare vermogen schommelen; rapporteer daarom naast een typisch resultaat ook de waargenomen verspreiding en het aantal runs.

Zorg ervoor dat de herhalingen dezelfde cache-status en dezelfde dataset gebruiken. Een run met een 'warme' paginacache of databasecache is niet direct vergelijkbaar met een 'koude' run. Als een ogenschijnlijk sneller antwoord volledig afkomstig is uit een paginacache, zegt dit weinig over hoe snel PHP het dynamische werk uitvoert.

Een CLI-microbenchmark is evenmin een FPM-resultaat: deze draait in een andere uitvoeringscontext en kan andere OPcache- of JIT-instellingen gebruiken. Documenteer de daadwerkelijk actieve instellingen van beide runtimes afzonderlijk, in plaats van ze af te leiden uit de PHP-versie. Een voordeel in de microtest hoeft zich niet in dezelfde mate te manifesteren in de HTTP-test van de applicatie.

Tel alleen inhoudelijk correcte, succesvolle antwoorden mee bij de succesvolle doorvoer. Snelle foutpagina’s of time-outs kunnen een vergelijking anders aanzienlijk vertekenen. Controleer bij opvallende afwijkingen ook de wachttijden in de database, wijzigingen in de cache en zichtbare limieten voor bronnen, voordat je het verschil uitsluitend aan de CPU toeschrijft.

De Taktgedrag kan eveneens bijdragen aan de spreiding. Welke frequentie-instelling zinvol is, hangt af van het platform en de belasting; een algemene instelling is geen vervanging voor een vergelijking onder dezelfde omstandigheden. De bijdrage aan de CPU-regelaar op hostingservers legt de verbanden uit met het oog op een grondiger analyse.

Resultaten gebruiken bij het kiezen van een hostingprovider

Voor verzoeken die voornamelijk de CPU zwaar belasten, is de Tijd per werkeenheid een belangrijk selectiecriterium. Vergelijk hiervoor een representatieve PHP-functie met de gedocumenteerde uitvoeringstijd en controleer vervolgens of het voordeel ook bij de dynamische HTTP-route zichtbaar is. Een microbenchmark beschrijft in eerste instantie alleen de geteste code, niet het volledige hostingaanbod.

Als je veel gelijktijdige bezoekers verwacht, is een snelle afzonderlijke verzoekverwerking niet voldoende. Daarnaast is het van cruciaal belang hoeveel correcte antwoorden het systeem per seconde levert bij een bepaald belastingsniveau en hoe de p95-latentie zich binnen het aanvaarde foutbereik gedraagt. Een systeem met een hogere doorvoercapaciteit is niet automatisch beter voor je project als de trage reactietijden de vereisten overschrijden.

Bij database- of cacheafhankelijke toepassingen moet je de Gebruikstest belangrijker dan een CPU-score. Een typische route met vergelijkbare gegevens laat zien hoe de interactie binnen de stack onder de gekozen omstandigheden werkt. Een SPEC-resultaat kan de voorselectie aanvullen, maar beschrijft een getest systeem en is geen vervanging voor een PHP-webhostingtest.

Bepaal vóór de selectie welke responstijden, foutpercentages en belastingniveaus voor de toepassing aanvaardbaar zijn. Vergelijk vervolgens alleen resultaten met een passend belastingsmodel en een vergelijkbare cachetoestand. Beoordeel verschillende hostingpakketten als totale configuraties; uit het verschil tussen deze configuraties kan het aandeel van de CPU niet zonder verdere diagnose worden afgeleid.

De beslissing geldt voor de gemeten situatie, niet voor elke latere versie van de applicatie of piek in het aantal bezoekers. Herhaal de relevante tests na ingrijpende wijzigingen aan PHP, de applicatie, de database, de cache of de limieten voor systeembronnen. Zo kun je nagaan of de reserves die voorheen voldoende waren, onder de nieuwe omstandigheden nog steeds aanwezig zijn.