Benchmark della CPU del server per PHP: test su carichi di lavoro reali di web hosting

Cosa dovrebbe chiarire un benchmark PHP

Un benchmark della CPU in PHP può innanzitutto mostrare quanto tempo impiega un sistema a eseguire un determinato compito di calcolo. Ciò è particolarmente utile quando una singola richiesta richiede molto tempo per i calcoli in PHP. Un valore più elevato Prestazioni del singolo core può ridurre i tempi di elaborazione di questo tipo di lavoro; tuttavia, dal solo valore della CPU non è possibile dedurre il tempo di risposta di un intero sito web.

Una seconda domanda riguarda il comportamento dell'applicazione in caso di accessi simultanei: quante risposte corrette fornisce al secondo e quanto tempo devono attendere gli utenti? A tal fine è necessario un Benchmark di web hosting è utile tramite HTTP. Esso rileva il percorso attraverso i server web e PHP, nonché, se del caso, il database, la cache e la rete. È proprio questa combinazione a renderlo orientato alla pratica, ma impedisce di trarre conclusioni isolate riguardo alla CPU.

La terza questione riguarda il collo di bottiglia. Se, ad esempio, una richiesta è in attesa di una query al database, un’operazione di calcolo più veloce non è indicativa del tempo totale richiesto. Anche la cache influisce sul risultato: se una pagina viene fornita completamente prima ancora che PHP entri in azione, la chiamata non misura l’esecuzione dell’applicazione dinamica.

In caso di carico parallelo, inoltre, il pool PHP-FPM può limitare il numero di richieste elaborate contemporaneamente. La sua pagina di stato fornisce, tra le altre cose, informazioni sui processi in esecuzione e sulle richieste in attesa. Una coda in crescita è quindi un motivo per effettuare una diagnosi, non una prova diretta di una CPU troppo lenta.

Per scegliere il servizio di hosting, è utile considerare queste domande separatamente: prima l’unità di lavoro comparabile, poi l’applicazione in condizioni di carico basso e elevato e, infine, le risorse che limitano il risultato. Il contributo su spiega come CPU, memoria RAM e spazio di archiviazione interagiscono tra loro in linea di principio: Hardware per l'hosting web ad alte prestazioni.

Distinguere i punteggi della CPU dai test applicativi

A Microbenchmark ripete un compito piccolo e ben definito. Con PHPBench è possibile, ad esempio, analizzare una funzione di elaborazione dei dati in condizioni prestabilite. Il risultato aiuta a confrontare tale funzione e il suo ambiente di esecuzione; non descrive automaticamente né una richiesta completa né le prestazioni di un CMS o di un negozio online.

Un test dell'applicazione HTTP risponde a un'altra domanda: come reagisce l'applicazione scelta attraverso lo stack web effettivamente utilizzato? Esso tiene conto, ad esempio, di PHP-FPM, del database e delle cache, nella misura in cui questi sono coinvolti nella chiamata sottoposta a test. È quindi adatto alla valutazione di un'offerta di hosting, ma non può dimostrare da solo quale componente sia responsabile di una determinata differenza.

SPEC CPU integra tali test con carichi di lavoro standardizzati e ad alta intensità di calcolo. SPEC CPU 2026 comprende suite per operazioni intere e in virgola mobile, oltre a risultati relativi a “Speed” e “Rate”. “Speed” si riferisce al tempo impiegato per eseguire le operazioni, mentre “Rate” indica la produttività. Un valore di velocità non è automaticamente un valore puramente single-core: SPEC indica un parallelismo aggiuntivo nei test di velocità con numeri interi della suite 2026.

Per un confronto SPEC attendibile, è necessario che la suite, la metrica e il tipo di risultato base o picco corrispondono. Anche il sistema sottoposto a test completi è importante: oltre al processore, anche la memoria, il compilatore e la configurazione, tra le altre cose, influenzano il risultato. I valori pubblicati non rappresentano quindi una caratteristica isolata del modello di CPU e non sostituiscono un test PHP.

SPEC CPU 2017 e CPU 2026 utilizzano suite di test diverse; i loro valori non sono rapportabili sulla stessa scala. Chi effettua una preselezione dovrebbe quindi confrontare il rapporto completo dei risultati anziché una classifica abbreviata. Solo un test applicativo adeguatamente strutturato potrà poi dimostrare se un candidato è adatto alla propria applicazione.

Definire condizioni di prova comparabili

Un confronto equo presuppone l’utilizzo della stessa versione dell’applicazione e di un set di dati comparabile. Anche il percorso scelto e la risposta prevista devono coincidere: una pagina di prodotto con numerosi accessi al database risponde a una domanda diversa rispetto a una semplice funzione API. Verifica quindi non solo se arriva una risposta, ma anche se il suo contenuto corrisponde all’attività prevista.

Annota la versione di PHP e le estensioni, così come il server web, la configurazione di PHP-FPM e il database. Anche il percorso di rete tra il generatore di carico e l'applicazione deve essere riportato nel protocollo. Percorsi diversi o posizioni diverse del database possono alterare il tempo di risposta misurato, anche se l'esecuzione di PHP fosse altrettanto veloce su entrambi i sistemi.

È particolarmente importante separare CLI e PHP-FPM: Un test da riga di comando non utilizza automaticamente la stessa configurazione di esecuzione di una richiesta HTTP. Documentare le impostazioni di OPcache e JIT effettivamente utilizzate in entrambi i contesti. Il loro effetto e le impostazioni predefinite dipendono, tra l’altro, dalla versione di PHP; un’ipotesi generica non è sufficiente ai fini del confronto.

Il Stato della cache deve essere comparabile. Una cache fredda e una cache già riscaldata rispondono a domande diverse; entrambe possono essere rilevanti, ma dovrebbero essere valutate separatamente. Lo stesso vale per il volume dei dati e i dati di test: se il carico di lavoro cambia, una differenza di tempo non può più essere attribuita con precisione al sistema.

Annotare inoltre il modello della CPU, le vCPU assegnate e i limiti delle risorse visibili, nonché il carico selezionato e il numero di ripetizioni. Se si confrontano intenzionalmente due pacchetti di hosting diversi, il risultato fornisce un’indicazione sulla rispettiva configurazione complessiva. Le differenze relative al processore, ai limiti, al database o alla cache non devono quindi essere interpretate, senza un’ulteriore analisi, come un vantaggio esclusivo della CPU.

Scegliere i carichi di lavoro e gli indicatori adeguati

La scelta del test dipende dalla domanda a cui vuoi rispondere. Un Microbenchmark analizza un'operazione di calcolo limitata; un test HTTP tiene conto del percorso attraverso lo stack web. I risultati SPEC completano il confronto con test di sistema standardizzati ad alta intensità di CPU, ma non sostituiscono un test della propria applicazione PHP.

Per una singola richiesta dinamica, scegli una pagina o un percorso API rappresentativo e inizia con un basso livello di parallelismo. Il percorso deve effettivamente eseguire il codice PHP: una risposta fornita interamente da una cache di pagina a monte sarebbe sì un test valido della cache, ma non dice molto sull’elaborazione PHP.

Per i visitatori simultanei, devi testare lo stesso endpoint a diversi livelli di carico prestabiliti. In questo modo è possibile verificare se i tempi di risposta e il throughput effettivo variano all’aumentare del parallelismo. Nel caso di un percorso che fa un uso intensivo del database, il volume dei dati, la posizione del database e lo stato della cache devono rimanere invariati tra una sessione di confronto e l’altra.

È possibile analizzare in modo isolato, con PHPBench, una funzione dell'applicazione che richiede un elevato carico della CPU, ad esempio un'operazione di elaborazione dati senza accesso alla rete. Un risultato migliore indica inizialmente solo un vantaggio per quella specifica funzione nelle condizioni di esecuzione selezionate. Spetterà al test dell'applicazione dimostrare se ciò si traduca in un vantaggio tangibile per una pagina completa.

Eseguire il test di staging con wrk

Esegui i test solo previa espressa autorizzazione in un ambiente di staging isolato. Configura un percorso di lettura rappresentativo e privo di rischi e utilizza dati di test adeguati. Prima di iniziare, definisci un carico massimo e dei criteri di interruzione, quali errori, timeout o un impatto negativo su altri servizi.

Il comando seguente è destinato a un terminale su un'istanza di staging locale appositamente configurata. La route preparata deve essere raggiungibile sulla porta 8080; il comando genera infatti un carico di traffico e non è destinato a un sistema sconosciuto o in produzione.

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

La chiamata utilizza due thread del generatore di carico, quattro connessioni aperte e una durata di 30 secondi. L'opzione --latency richiede un output dettagliato sulla latenza. In questo caso, quattro connessioni rappresentano un punto di partenza scelto per questo esempio, non una raccomandazione generale relativa al numero di visitatori o alla capacità di un server.

L'output standard dei percentili di wrk, tuttavia, non include il p95. Per ottenere un'analisi riproducibile del p95, salva il seguente script Lua sul generatore di carico come percentiles.lua. I valori p50 e p95 ricavati dalle statistiche di latenza sono espressi in microsecondi; dividendo per 1.000 si ottengono i millisecondi.

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

Per eseguire la misurazione vera e propria, avvia lo stesso test di staging locale utilizzando lo script. Il percorso del file si riferisce a un terminale nella directory in cui si trova il file dello script. Anche questa esecuzione genera un carico; documenta i due percentili visualizzati insieme agli errori e alla qualità della risposta verificata separatamente.

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

Organizza una separata Fase di riscaldamento prima di registrare le misurazioni vere e proprie. Ripeti quindi ogni livello di carico specificato, variando, se possibile, l'ordine dei sistemi di confronto. Annota la durata del riscaldamento e se, all'inizio della misurazione, la cache si trovava nello stato desiderato.

Aumenta il numero di connessioni solo entro i limiti concordati e verifica i criteri di interruzione dopo ogni fase. Tieni d’occhio anche il generatore di carico: se è esso stesso a pieno carico, può limitare il risultato. Verifica inoltre i codici di stato e il contenuto delle risposte; una pagina di errore visualizzata rapidamente o una risposta errata non vengono considerate come una richiesta all’applicazione andata a buon fine.

Documentare i livelli di carico e i risultati

Un protocollo di misurazione collega i dati alle condizioni in cui sono stati rilevati. Per ogni esecuzione, annota l'ambiente, il punto finale, lo stato della cache e il livello di carico insieme ai risultati. La tabella seguente utilizza, tra l'altro, i valori forniti da wrk o dalla pagina di stato FPM; dovrai integrare la verifica del contenuto della risposta.

La mediana indica il valore centrale dei tempi di risposta osservati. Il p95 è il valore che il 95% delle risposte misurate non supera. Insieme, questi due parametri indicano se, oltre alle richieste tipiche, sta cambiando anche la parte più lenta della distribuzione. Interpretali sempre tenendo conto degli errori e dei timeout.

Distinguere tra un numero fisso di connessioni e una frequenza di richiesta prestabilita. In un test basato sulle connessioni come quello dell’esempio, le risposte lente possono comportare una riduzione del numero di nuove richieste al secondo generate sulle stesse connessioni. La latenza misurata non descrive quindi automaticamente il comportamento in presenza di una frequenza di arrivo elevata e costante.

Confronta quindi solo punti di carico sufficientemente simili: stesso percorso e stessa verifica della risposta, stati della cache comparabili, nonché stesso modello di carico e stesso livello di carico. Un p95 basso con un basso livello di parallelismo non è direttamente comparabile a un p95 in condizioni di sovraccarico. Riporta i risultati di più esecuzioni e la loro dispersione, anziché fornire come risultato un singolo valore favorevole.

Analizzare l'FPM e i limiti delle risorse

Se, con l'aumentare del carico, aumentano sia la coda che il tempo di risposta p95, vale la pena dare un'occhiata al pool PHP-FPM. Confronta i valori attuali per active processes, idle processes e listen queue con il limite massimo configurato pm.max_children. Se tutti i processi consentiti sono attivi, non ce ne sono di liberi e le richieste sono in coda, ciò indica una Limite della piscina o a lavoratori che hanno lavorato a lungo, ma non necessariamente a una CPU troppo lenta.

L'annuncio max children reached documenta invece il raggiungimento anticipato del limite di processi sin dall'avvio del pool. Di per sé, ciò non dimostra né l'esistenza di una coda attuale né che tutti i processi presenti siano attualmente occupati. Allo stesso modo, il numero massimo di processi presenti non significa che siano tutti attivi.

I worker possono anche trovarsi in attesa di query al database o di altri servizi esterni. È quindi opportuno confrontare lo stato del pool e il carico della CPU con i tempi di risposta osservati: una coda piena a fronte di un carico della CPU ridotto suggerisce di esaminare innanzitutto i tempi di attesa e l’occupazione dei worker. Aumentare il numero di pool non è automaticamente la soluzione, poiché anche i processi aggiuntivi richiedono risorse.

I valori di stato FPM si applicano al rispettivo pool; i contatori vengono azzerati al riavvio. Si raccomanda pertanto di annotare nel protocollo di misurazione il pool e l'ora del riavvio e di confrontare i valori dei contatori solo all'interno di un intervallo di tempo adeguato. Proteggere una pagina di stato attivata da accessi non autorizzati, poiché essa rivela informazioni operative relative al pool.

Nel caso dei VPS e dell'hosting condiviso, una vCPU assegnata non corrisponde necessariamente a un core fisico esclusivo. Laddove sono disponibili i dati di cgroup-v2, si può verificare cpu.max il limite di larghezza di banda della CPU configurato; cpu.stat può includere, tra l'altro, contatori per Strozzatura contenuti. Le variazioni di questi contatori durante un ciclo aiutano a individuare un limite effettivo.

Se possibile, controlla anche i cgroup di livello superiore: un limite impostato a quel livello può influire sul tempo di calcolo disponibile, anche se la configurazione immediatamente visibile sembra generosa. Non tutti i contatori riflettono completamente i limiti ereditati. Se queste informazioni non sono presenti nel pacchetto di hosting, la visibilità limitata rientra espressamente tra i limiti dell’analisi.

Rilevare la dispersione e gli errori di misurazione

Una singola esecuzione può fornire un quadro casualmente favorevole o sfavorevole. Ripeti gli stessi livelli di carico in momenti prestabiliti e, se possibile, varia l’ordine dei sistemi di confronto. Soprattutto in caso di risorse condivise, le prestazioni disponibili possono variare; pertanto, oltre a riportare un risultato tipico, indica anche il valore osservato dispersione e il numero di corse.

Assicurati che le esecuzioni utilizzino lo stesso stato della cache e lo stesso insieme di dati. Un'esecuzione con la cache delle pagine o del database "calda" non è direttamente paragonabile a un'esecuzione "fredda". Se una risposta apparentemente più veloce proviene interamente dalla cache delle pagine, ciò dice ben poco sulla velocità con cui PHP esegue il lavoro dinamico.

Anche un microbenchmark CLI non è un risultato FPM: viene eseguito in un contesto di esecuzione diverso e può utilizzare impostazioni OPcache o JIT diverse. Documenta separatamente le impostazioni effettivamente attive di entrambi i runtime, invece di dedurle dalla versione di PHP. Un vantaggio riscontrato nel microbenchmark non deve necessariamente manifestarsi nella stessa misura nel test HTTP dell’applicazione.

Conta solo le risposte corrette dal punto di vista del contenuto e andate a buon fine ai fini del throughput effettivo. Altrimenti, le pagine di errore che si caricano rapidamente o i timeout possono distorcere notevolmente il confronto. In caso di scostamenti evidenti, verifica anche i tempi di attesa del database, le modifiche nella cache e i limiti visibili delle risorse, prima di attribuire la differenza esclusivamente alla CPU.

Il sito Comportamento di sincronizzazione può anch’essa contribuire alla dispersione. La regolazione della frequenza più appropriata dipende dalla piattaforma e dal carico; un’impostazione generica non sostituisce un confronto effettuato nelle stesse condizioni. Il contributo alla Governor della CPU sui server di hosting illustra i nessi per un’analisi approfondita.

Utilizzare i risultati per scegliere il servizio di hosting

Per le richieste che comportano prevalentemente un carico elevato sulla CPU, la Tempo per unità di lavoro un criterio di selezione importante. A tal fine, confronta una funzione PHP rappresentativa con i tempi di esecuzione documentati e verifica poi se il vantaggio si riscontra anche nel percorso HTTP dinamico. Un microbenchmark descrive inizialmente solo il codice testato, non l'intera offerta di hosting.

Se prevedi un numero elevato di visitatori simultanei, la velocità di risposta a una singola richiesta non è sufficiente. È fondamentale anche verificare quante risposte corrette al secondo il sistema fornisce a un determinato livello di carico e come si comporta la latenza p95 all’interno del margine di errore accettabile. Un sistema con una maggiore capacità di elaborazione non è automaticamente migliore per il tuo progetto se le sue risposte lente superano i requisiti.

Nel caso di applicazioni che dipendono da database o dalla cache, attribuisci un peso al Test di funzionamento più significativo di un punteggio CPU. Un percorso tipico con un set di dati comparabile mostra come funziona l'interazione dello stack nelle condizioni selezionate. Un risultato SPEC può integrare la preselezione, ma descrive un sistema testato e non sostituisce un test di web hosting PHP.

Prima di effettuare la selezione, stabilisci quali tempi di risposta, tassi di errore e livelli di carico siano accettabili per l’applicazione. Confronta quindi solo i risultati con un modello di carico adeguato e uno stato della cache comparabile. Valuta i diversi pacchetti di hosting come configurazioni complessive; dalla loro differenza non è possibile isolare la quota della CPU senza un'ulteriore analisi.

La decisione si applica allo stato attuale, non a eventuali versioni successive dell'applicazione o a picchi di accesso. Ripeti i test pertinenti dopo modifiche significative a PHP, all'applicazione, al database, alla cache o ai limiti delle risorse. In questo modo potrai verificare se le riserve, che in precedenza erano sufficienti, continuano a esserlo anche nelle nuove condizioni.