Benchmarking av server-CPU:er för PHP: Tester för verkliga arbetsbelastningar inom webbhotell

Vad en PHP-prestandatest ska ge svar på

Ett PHP-CPU-benchmark kan till att börja med visa hur lång tid ett system behöver för att utföra en viss beräkningsuppgift. Detta är särskilt användbart när en enskild förfrågan tar mycket tid på grund av PHP-beräkningar. En högre Prestanda för enkärniga processorer kan förkorta bearbetningstiden för sådana uppgifter; man kan dock inte utgå från enbart ett CPU-värde för att beräkna svarstiden för en hel webbplats.

En andra fråga gäller hur applikationen beter sig vid samtidiga åtkomstförsök: Hur många korrekta svar ger den per sekund, och hur länge får användarna vänta? För detta krävs en Jämförelse av webbhotell via HTTP är meningsfullt. Det kartlägger vägen genom webbservern och PHP samt, i förekommande fall, databasen, cachen och nätverket. Just denna kombination gör det praktiskt tillämpligt, men förhindrar samtidigt att man kan dra en isolerad slutsats om CPU:n.

Den tredje frågan gäller flaskhalsen. Om en förfrågan till exempel väntar på ett databassök kan en snabbare beräkning inte säga mycket om dess totala tid. Även en cache påverkar resultatet: om en sida redan levereras i sin helhet innan PHP hinner bearbeta den, mäter anropet inte den dynamiska applikationens körning.

Vid parallell belastning kan dessutom PHP-FPM-poolen begränsa hur många förfrågningar som behandlas samtidigt. Dess statussida visar bland annat information om aktiva processer och väntande förfrågningar. En växande kö är därför ett skäl att utföra en diagnostik, inte ett direkt bevis på att processorn är för långsam.

När man ska välja webbhotell är det bra att betrakta dessa frågor var för sig: först den jämförbara arbetsenheten, sedan användningen vid låg respektive hög belastning och slutligen de resurser som begränsar resultatet. Hur CPU, arbetsminne och lagringsutrymme i grunden samverkar förklaras i artikeln om Hårdvara för högpresterande webbhotell.

Skillnaden mellan CPU-resultat och applikationstester

En Mikrobenchmark upprepar en liten, noggrant definierad uppgift. Med PHPBench kan man till exempel undersöka en funktion för databehandling under fastställda förhållanden. Resultatet hjälper till att jämföra denna funktion och dess körningsmiljö; det beskriver varken automatiskt en fullständig förfrågan eller prestandan hos ett CMS eller en webbutik.

Ett HTTP-applikationstest besvarar en annan fråga: Hur reagerar den valda applikationen via den webbstack som faktiskt används? Det tar hänsyn till exempelvis PHP-FPM, databasen och cacher, i den mån de ingår i det testade anropet. Därmed lämpar det sig för att utvärdera ett webbhotellserbjudande, men kan inte på egen hand påvisa vilken komponent som är ansvarig för en viss skillnad.

SPEC CPU kompletterar sådana tester med standardiserade, beräkningsintensiva arbetsbelastningar. SPEC CPU 2026 innehåller sviterna för heltal och flyttal samt resultat för hastighet och genomströmning. Hastighet avser tiden för uppgifterna, medan genomströmning avser genomströmningen. Ett hastighetsvärde är inte automatiskt ett rent enkelkärnvärde: SPEC påpekar att det förekommer ytterligare parallellitet vid heltalshastighetstesterna i 2026-sviten.

För att en SPEC-jämförelse ska vara tillförlitlig måste testsuiten, mätvärdet och resultattypen bas eller topp överensstämmer. Det fullständigt testade systemet spelar också en viktig roll: Förutom processorn påverkar bland annat minne, kompilator och konfiguration resultatet. Publicerade värden är därför inte en isolerad egenskap hos CPU-modellen och ersätter inte ett PHP-test.

SPEC CPU 2017 och CPU 2026 använder olika testuppsättningar; deras siffror kan inte jämföras på samma skala. Den som gör ett urval bör därför jämföra den fullständiga resultatrapporten istället för en förkortad ranglista. Om en kandidat är lämplig för den egna applikationen visar först ett lämpligt utformat applikationstest.

Fastställa jämförbara testförhållanden

En rättvis jämförelse börjar med samma applikationsversion och en jämförbar datamängd. Även den valda vägen och det förväntade svaret måste stämma överens: En produktsida med många databasåtkomster besvarar en annan fråga än en enkel API-funktion. Kontrollera därför inte bara om ett svar kommer in, utan också om dess innehåll stämmer överens med den avsedda uppgiften.

Notera PHP-versionen och tilläggsmodulerna, liksom webbservern, PHP-FPM-konfigurationen och databasen. Nätverksvägen mellan belastningsgeneratorn och applikationen ska också anges i protokollet. Olika vägar eller databasplatser kan påverka den uppmätta svarstiden, även om PHP-körningen skulle vara lika snabb på båda systemen.

Det är särskilt viktigt att skilja mellan CLI och PHP-FPM: Ett test i kommandoraden undersöker inte automatiskt samma körningskonfiguration som en HTTP-förfrågan. Dokumentera de OPcache- och JIT-inställningar som faktiskt används i båda sammanhangen. Deras effekt och standardinställningar beror bland annat på PHP-versionen; en generell antagande räcker inte för jämförelsen.

Den Cache-status måste vara jämförbar. En kall cache och en redan uppvärmd cache ger svar på olika frågor; båda kan vara relevanta, men bör utvärderas separat. Detsamma gäller datamängd och testdata: om arbetsomfånget förändras kan en tidsskillnad inte längre entydigt tillskrivas systemet.

Notera dessutom CPU-modell, tilldelade vCPU:er och synliga resursbegränsningar samt den valda belastningen och antalet repetitioner. Om man medvetet jämför två olika hostingpaket ger resultatet en bild av deras respektive totala konfiguration. Skillnader i processor, gränser, databas eller caching får då inte tolkas enbart som en CPU-fördel utan ytterligare diagnostik.

Välj lämpliga arbetsbelastningar och mätvärden

Valet av test beror på vilken fråga du vill få svar på. Ett Mikrobenchmark undersöker en begränsad beräkningsuppgift; ett HTTP-test omfattar vägen genom webbstacken. SPEC-resultaten kompletterar jämförelsen med standardiserade CPU-intensiva systemtester, men ersätter inte ett test av den egna PHP-applikationen.

För en enskild dynamisk förfrågan väljer du en representativ sida eller API-rutt och börjar med låg parallellitet. Rutten måste faktiskt köra PHP: ett svar som helt och hållet levereras från en uppströms sidcache skulle visserligen vara ett giltigt cachetest, men säger inte mycket om PHP-bearbetningen.

För samtidiga besökare testar du samma slutpunkt vid flera förutbestämda belastningsnivåer. På så sätt kan du se om svarstiderna och den framgångsrika genomströmningen förändras när parallelliteten ökar. Vid en databasintensiv rutt bör datamängden, databasens placering och cache-statusen förbli oförändrade mellan jämförelsekörningarna.

En CPU-krävande funktion i applikationen kan du dessutom undersöka isolerat med PHPBench, till exempel en databehandling utan nätverksåtkomst. Ett bättre resultat visar inledningsvis endast en fördel för just denna funktion under de valda körningsförhållandena. Om detta leder till en märkbar fördel för en hel sida måste applikationstestet visa.

Utföra staging-test med wrk

Testa endast i en isolerad testmiljö med uttryckligt tillstånd. Konfigurera en ofarlig, representativ läsväg och använd lämpliga testdata. Fastställ en maximal belastning samt avbrottskriterier innan du startar, till exempel fel som uppstår, tidsöverskridningar eller påverkan på andra tjänster.

Följande kommando är avsett för en terminal på en lokal staging-instans som uttryckligen har konfigurerats för detta ändamål. Den förberedda rutten måste vara tillgänglig på port 8080; kommandot genererar faktiskt belastning och är inte avsett för ett okänt eller produktivt system.

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

Anropet använder två trådar för belastningsgeneratorn, fyra öppna anslutningar och en körningstid på 30 sekunder. Alternativet --latency begär en detaljerad latensrapport. Fyra anslutningar är en vald utgångspunkt för detta exempel, inte en allmän rekommendation för antalet besökare eller en servers kapacitet.

Den vanliga percentilutmatningen från wrk innehåller dock inget p95-värde. För en reproducerbar p95-utvärdering ska du spara följande Lua-skript på belastningsgeneratorn som percentiles.lua. Latensstatistiken anger p50 och p95 i mikrosekunder; om man delar med 1 000 får man millisekunder.

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

För den egentliga mätningen, kör samma lokala staging-test med skriptet. Filvägen gäller för en terminal i skriptfilens katalog. Även detta körning genererar belastning; dokumentera de två procentilerna som visas tillsammans med fel och den separat kontrollerade svarskvaliteten.

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

Planera en separat Uppvärmningsfas innan du dokumenterar själva mätningarna. Upprepa därefter varje fastställd belastningsnivå och variera om möjligt ordningen på jämförelsesystemen. Notera hur länge uppvärmningen pågick och om cachen befann sig i önskat tillstånd vid mätningens början.

Öka antalet anslutningar endast inom de överenskomna gränserna och kontrollera avbrottskriterierna efter varje steg. Håll även koll på belastningsgeneratorn: om den själv är fullt utnyttjad kan den begränsa resultatet. Kontrollera dessutom statuskoder och svarens innehåll; en snabbt levererad felsida eller ett felaktigt svar räknas inte som en lyckad applikationsförfrågan.

Dokumentera belastningsnivåer och resultat

Ett mätprotokoll kopplar samman siffrorna med de förhållanden under vilka de uppkom. Notera för varje körning omgivningen, slutpunkten, cache-statusen och belastningsnivån tillsammans med resultaten. Följande tabell använder bland annat värden som tillhandahålls av wrk respektive FPM-statussidan; du måste själv komplettera med en innehållsmässig kontroll av svaren.

Medianvärdet beskriver mitten av de observerade svarstiderna. Det p95 är det värde som 95 procent av de uppmätta svaren inte överskrider. Tillsammans visar dessa två storheter om även den långsammare delen av fördelningen förändras, utöver en typisk förfrågan. Tolka dem alltid tillsammans med fel och timeouts.

Skillnaden mellan ett fast antal anslutningar och en förutbestämd förfrågningsfrekvens. Vid ett anslutningsbaserat test, som i exemplet, kan långsamma svar leda till att färre nya förfrågningar per sekund genereras via samma anslutningar. Den uppmätta latensen beskriver då inte utan vidare beteendet vid en oförändrat hög ankomstfrekvens.

Jämför därför endast tillräckligt likartade belastningspunkter: samma rutt och svarskontroll, jämförbara cache-tillstånd samt samma belastningsmodell och samma belastningsnivå. Ett lågt p95-värde vid låg parallellitet är inte direkt jämförbart med ett p95-värde under överbelastning. Rapportera flera körningar och deras spridning, istället för att ange ett enda gynnsamt värde som resultat.

Undersöka FPM och resursbegränsningar

Om både köet och p95-svarstiden ökar när belastningen ökar, är det värt att titta på PHP-FPM-poolen. Jämför de aktuella värdena för active processes, idle processes och listen queue med den konfigurerade övre gränsen pm.max_children. Om alla tillåtna processer är aktiva, inga är lediga och förfrågningar står i kö, tyder det på en Poolgräns eller arbetare som varit sysselsatta under lång tid, men inte automatiskt på en för långsam processor.

Annonsen max children reached Däremot visar detta att processgränsen nåtts tidigare sedan poolen startades. Detta i sig bevisar varken att det för närvarande finns en kö eller att alla befintliga processer just nu är upptagna. På samma sätt innebär det maximala antalet befintliga processer inte att alla är aktiva.

Arbetare kan också vänta på databasfrågor eller andra externa tjänster. Jämför därför poolstatus och CPU-utnyttjande med de observerade svarstiderna: En full kö vid lågt CPU-utnyttjande tyder på att man först bör undersöka väntetiderna och arbetarnas beläggning. Ett större antal pooler är inte automatiskt lösningen, eftersom ytterligare processer också kräver resurser.

FPM-statusvärdena gäller för respektive pool; räknarna nollställs vid en omstart. Notera därför poolen och tidpunkten för omstarten i mätprotokollet och jämför räknarställningarna endast inom en lämplig tidsperiod. Skydda en aktiverad statussida mot obehörig åtkomst, eftersom den avslöjar driftsinformation om poolen.

När det gäller VPS och delad hosting innebär en tilldelad vCPU inte nödvändigtvis en exklusiv fysisk kärna. Där cgroup-v2-data är tillgängliga visar cpu.max den konfigurerade begränsningen av CPU-bandbredden; cpu.stat kan bland annat användas som räknare för Strypning ingår. Ändringar av dessa räknare under en körning underlättar diagnostiseringen av en effektiv begränsning.

Kontrollera om möjligt även överordnade cgroups: En gräns som har ställts in där kan påverka den tillgängliga beräkningstiden, även om den direkt synliga konfigurationen verkar generös. Inte alla räknare återspeglar ärvda begränsningar fullt ut. Om denna information saknas i webbhotellspaketet ingår den begränsade synligheten uttryckligen i utvärderingens begränsningar.

Upptäcka spridning och felmätningar

Ett enskilt test kan ge en slumpmässigt gynnsam eller ogynnsam bild. Upprepa samma belastningsnivåer vid dokumenterade tidpunkter och variera om möjligt ordningen på jämförelsesystemen. Särskilt när det gäller delade resurser kan den tillgängliga prestandan variera; redovisa därför, förutom ett typiskt resultat, även den observerade spridning och antalet lopp.

Se till att körningarna använder samma cache-tillstånd och samma datamängd. En körning med varm sid- eller databascache är inte direkt jämförbar med en kall körning. Om ett till synes snabbare svar helt och hållet härrör från en sidcache säger det inte mycket om hur snabbt PHP utför det dynamiska arbetet.

En CLI-mikrobenchmark är inte heller ett FPM-resultat: den körs i ett annat körningssammanhang och kan använda andra OPcache- eller JIT-inställningar. Dokumentera de faktiskt aktiva inställningarna för båda körmiljöerna separat, istället för att härleda dem från PHP-versionen. En fördel i mikrotestet behöver inte visa sig i samma utsträckning i applikationens HTTP-test.

Räkna endast med innehållsmässigt korrekta, framgångsrika svar i den framgångsrika genomströmningen. Annars kan snabba felsidor eller timeouts snedvrida jämförelsen avsevärt. Vid påfallande avvikelser bör du även kontrollera väntetider i databasen, ändringar i cachen och synliga resursbegränsningar innan du enbart tillskriver skillnaden till CPU:n.

Das Taktsättning kan också bidra till spridningen. Vilken frekvensreglering som är lämplig beror på plattformen och belastningen; en generel inställning ersätter inte en jämförelse under samma förhållanden. Bidraget till CPU-regulator på webbhotellsservrar förklarar sambanden för en fördjupad granskning.

Använda resultaten vid valet av webbhotell

För förfrågningar som huvudsakligen innebär en stor belastning på CPU:n är Tid per arbetsenhet ett viktigt urvalskriterium. Jämför därför en representativ PHP-funktion med dokumenterad körtid och kontrollera sedan om fördelen också visar sig vid den dynamiska HTTP-rutten. En mikrobenchmark beskriver inledningsvis endast den testade koden, inte hela webbhotellstjänsten.

Om du förväntar dig många samtidiga besökare räcker det inte med en snabb enskild förfrågan. Det är dessutom avgörande hur många korrekta svar per sekund systemet levererar vid en fastställd belastningsnivå och hur p95-latensen utvecklas inom det accepterade felintervallet. Ett system med högre genomströmning är inte automatiskt bättre för ditt projekt om dess långsamma svar överskrider kraven.

Vid databas- eller cacheberoende applikationer bör du viktiga Användningstest mer än ett CPU-resultat. En typisk rutt med jämförbara data visar hur samspelet i stacken fungerar under de valda förhållandena. Ett SPEC-resultat kan komplettera urvalet, men beskriver ett testat system och ersätter inte ett PHP-webbhotellstest.

Bestäm innan du gör ditt val vilka svarstider, felfrekvenser och belastningsnivåer som är acceptabla för applikationen. Jämför därefter endast resultat med lämplig belastningsmodell och jämförbart cache-tillstånd. Olika hostingpaket ska du utvärdera som helhetskonfigurationer; utifrån skillnaden mellan dem går det inte att urskilja CPU:ns andel utan ytterligare diagnostik.

Beslutet gäller den uppmätta nivån, inte varje senare version av applikationen eller varje trafiktopp. Upprepa de relevanta testerna efter väsentliga ändringar av PHP, applikationen, databasen, cachen eller resursbegränsningarna. På så sätt kan du se om de reserver som tidigare var tillräckliga fortfarande finns kvar under de nya förhållandena.