Hosting condiviso: quando le CPU veloci sono utili nonostante il numero ridotto di core

Distinguere tra core, thread e tempo CPU

Un core fisico è un'unità di calcolo del processore. Il sistema operativo, invece, vede processori logici come unità eseguibili: in caso di multithreading simultaneo, più di queste unità possono condividere le risorse di un singolo core fisico. Il loro numero non permette quindi di capire immediatamente quanti core indipendenti l’uno dall’altro siano disponibili per un account di hosting.

Nell'hosting condiviso, più account condividono l'hardware di un server. Un piano tariffario può limitare la quantità di tempo di CPU che i processi di un account possono consumare in un determinato periodo. Questo Budget di tempo della CPU è qualcosa di diverso dall'impegno a utilizzare in modo esclusivo un kernel fisico. I cgroups di Linux rappresentano una possibile base tecnica per tali limiti, ma non l'unica implementazione possibile.

Se nel piano tariffario è indicato, ad esempio, „un vCore“ o „100% della CPU“, è opportuno verificare la definizione fornita dal provider. Tale indicazione può riferirsi a un budget di tempo di calcolo, senza che venga riservato in modo permanente un determinato core. Inoltre, dal numero totale di core del server host non è possibile dedurre quanta potenza un singolo account possa effettivamente utilizzare contemporaneamente.

In questo contesto, il termine "concorrenza" indica il numero di richieste o processi che possono essere elaborati in parallelo. Dipende, tra l'altro, dai limiti di processo, dalla memoria e dalla potenza di calcolo disponibile. CloudLinux può applicare limiti di risorse specifici a questo scopo; per sapere se un piano tariffario utilizza questa tecnologia e come è configurata, devi rivolgerti al fornitore.

La limitazione delle risorse e l'isolamento di sicurezza svolgono funzioni diverse: un limite regola il consumo, mentre l'isolamento ha lo scopo di limitare l'accesso tra gli ambienti. La Classificazione di CloudLinux Site Isolation e CageFS spiega i relativi meccanismi di sicurezza; ciò non comporta di per sé una specifica assegnazione della CPU.

Perché i GHz da soli non bastano

La frequenza di clock indica il numero di cicli di clock che un processore esegue al secondo. Una frequenza di clock più elevata può accelerare le operazioni che dipendono dalla CPU, ma da sola non è sufficiente a determinare in che misura un sito web ne tragga vantaggio. Le diverse architetture di processore svolgono una quantità di lavoro diversa per ogni ciclo di clock; anche il codice di programma specifico influisce sul risultato.

A Prestazioni del single-core Inoltre, anche la cache e il comportamento della memoria incidono sulle prestazioni. Se un processo deve attendere spesso i dati, una frequenza più elevata può avere un effetto minore rispetto a un calcolo in cui i dati sono già rapidamente disponibili. Un confronto basato esclusivamente sui GHz non tiene conto di queste differenze e non sostituisce un benchmark specifico per l'applicazione.

Un esempio di scheda tecnica sintetica è l'AMD EPYC 4564P: per questo modello, AMD indica 16 core, 32 thread, una frequenza di base di 4,5 GHz e una frequenza massima in modalità Boost fino a 5,7 GHz. Questi dati descrivono il processore, non le prestazioni di un determinato piano di hosting.

Il sito Potenza massima non è né un valore garantito nel tempo né la frequenza presente in ogni momento su tutti i core. Allo stesso modo, i dati del prodotto non indicano la velocità con cui un determinato piano di hosting condiviso elabora una richiesta WordPress o PHP. Oltre all’hardware, infatti, anche la configurazione, il carico di lavoro e i limiti del piano giocano un ruolo importante.

Quando i fornitori con hosting con CPU ad alta frequenza Se si tratta di una pubblicità, chiedi quindi informazioni sul modello specifico del processore e sul budget di risorse disponibile. Per effettuare confronti significativi delle prestazioni sono necessarie anche informazioni sulla versione del software, sulla configurazione del server, sul carico di lavoro e sulle condizioni di test. Senza queste informazioni, non è possibile tradurre in modo affidabile un valore in GHz pubblicizzato in un tempo di risposta più breve.

Richieste PHP ed elaborazione parallela

In una tipica richiesta sincrona, un worker PHP elabora le singole fasi del proprio lavoro PHP prevalentemente in sequenza. Una CPU più veloce può ridurre questa fase, se effettivamente richiede un'elevata potenza di calcolo. Se invece il worker rimane in attesa soprattutto di una risposta dal database o da un servizio esterno, il vantaggio derivante da una maggiore potenza di calcolo del processore per questo tempo di attesa rimane limitato.

La formula di ricerca php single core Ciò non significa, quindi, che un intero sito web possa utilizzare un solo core. Diverse richieste possono essere elaborate in parallelo da più worker; anche il server web e il database possono funzionare contemporaneamente. Ciò che conta è la quantità di lavoro in parallelo consentita dalle risorse disponibili e dalla configurazione specifica.

Limitazione di PHP-FPM pm.max_children il numero di richieste gestite contemporaneamente da un pool. Una volta raggiunto il limite, le richieste aggiuntive non possono essere elaborate immediatamente da un altro worker di quel pool. Tuttavia, il limite non indica il numero totale di visitatori che possono utilizzare un sito web.

Il sito Gestione dei processi PHP-FPM prevede tre modalità operative: static mantiene un numero fisso di worker. dynamic adegua il numero in base alla configurazione e alla domanda; ondemand avvia i worker quando necessario. La modalità operativa selezionata determina quindi anche quando i processi sono disponibili o vengono riavviati.

Un numero maggiore di worker non garantisce automaticamente più tempo di CPU. Inoltre, richiedono memoria di lavoro e, se eseguiti in parallelo, possono raggiungere insieme il limite dell’account. Per valutare una hosting condiviso CPU Il numero di worker e il budget delle risorse vanno quindi di pari passo. Non tutti i piani tariffari utilizzano PHP-FPM o consentono ai clienti di modificarne autonomamente le impostazioni.

Quota CPU in caso di carico parallelo

A Quota CPU definisce la quantità di tempo di calcolo che un gruppo di processi può consumare in un determinato intervallo di tempo. In Linux, cgroup v2 descrive cpu.max questo budget e il periodo corrispondente. La quota, quindi, non riserva automaticamente un nucleo fisico esclusivo: limita il tempo di CPU complessivamente disponibile per il gruppo.

Esempio di calcolo illustrativo, non si tratta di una misurazione: un gruppo riceve 100 millisecondi di tempo CPU per ogni periodo di 100 millisecondi. Ciò corrisponde in media al tempo di calcolo di un processore logico utilizzato al massimo della sua capacità. Se due processi eseguono calcoli contemporaneamente su due processori logici disponibili, in teoria possono esaurire il budget comune dopo circa 50 millisecondi di tempo di parete.

Una volta esaurito il budget, i processi possono essere rallentati fino al periodo successivo. I due worker non dispongono quindi ciascuno di un proprio budget di 100 millisecondi. Se e quando funzionino effettivamente in parallelo dipende, tra l’altro, dallo scheduler, dalle CPU disponibili e dal loro comportamento; l’esempio non fornisce alcuna previsione concreta sui tempi di risposta.

Ai fini dell'analisi, cgroup v2 in cpu.stat tra cui contatori per Strozzatura pronti. Se aumentano durante una fase di carico rappresentativa, ciò indica che la quota è stata esaurita. Tuttavia, una singola lettura del contatore non basta a spiegare quale richiesta sia stata interessata o se esistano altri colli di bottiglia.

Per sapere se questi file sono accessibili nell'ambito del piano tariffario e se sono rilevanti per il sito web, devi chiarirlo con il provider. L'hosting condiviso può utilizzare meccanismi diversi: CloudLinux, ad esempio, documenta i propri limiti LVE per la CPU e altre risorse. Dall'esempio di Linux non è quindi possibile dedurre né la configurazione concreta né il comportamento di ogni singolo account di hosting.

CMS, negozio online e processi in background

Nel caso di una pagina CMS non memorizzata nella cache, il server esegue la logica applicativa per la richiesta e recupera i dati necessari. Se gran parte dell'elaborazione ricade su Funzionamento della CPU, una maggiore potenza per core può ridurre la durata di questa fase. Ciò vale, ad esempio, per i calcoli complessi nel codice PHP, ma non necessariamente per l'intero tempo necessario alla generazione della pagina.

Se, al contrario, la stessa richiesta dipende prevalentemente da un’interrogazione del database o da un’API esterna, il processo PHP può trarre solo un beneficio limitato da una CPU più veloce durante quel lasso di tempo. Per prendere una decisione è quindi determinante la ripartizione del tempo di risposta lato server: quanto tempo viene dedicato al calcolo e quanto all’attesa di altri servizi?

Un negozio online mostra perché questa domanda può avere risposte diverse a seconda delle pagine. Le pagine pubbliche dei prodotti possono essere salvate temporaneamente come risposta pronta, a determinate condizioni. Un Cache hit può evitare una nuova elaborazione completa da parte di PHP; il carrello e la procedura di pagamento, invece, devono spesso tenere conto di dati specifici e rimangono dinamici.

Numerose richieste di checkout simultanee possono quindi gravare sui worker o sulla disponibilità di CPU in misura maggiore rispetto a un numero equivalente di accessi a pagine memorizzate nella cache. Il numero di visitatori da solo non è sufficiente a descrivere questo carico: ciò che conta è quali endpoint vengono richiesti contemporaneamente e con quale frequenza viene utilizzata la cache. In PHP-FPM, inoltre, l’impostazione del pool limita pm.max_children il numero di richieste gestite contemporaneamente.

Un’importazione che richiede un’elevata potenza di calcolo nel backend può a sua volta trarre vantaggio da un’elaborazione singola più veloce. Se viene eseguita in parallelo alle richieste dei visitatori, i processi potrebbero competere per lo stesso budget di tempo della CPU. Il fatto che un cronjob o un’importazione siano effettivamente assegnati allo stesso gruppo limitato dipende dal piano tariffario e dalla sua configurazione; prima di prendere una decisione in merito alla capacità, verifica con il fornitore.

Per un confronto significativo, dovresti considerare separatamente questi carichi di lavoro: una tipica richiesta dinamica, una fase con più richieste simultanee e, se del caso, l’importazione durante il funzionamento del sistema. In questo modo potrai capire più facilmente se sia la velocità di una singola fase di elaborazione o la capacità complessiva disponibile a costituire il fattore più determinante.

Confrontare osservazioni e colli di bottiglia

Una risposta lenta non indica necessariamente una causa. La seguente panoramica mette in relazione le osservazioni tipiche con le possibili cause verificabili. Tiene conto in particolare dei limiti di tempo della CPU, del numero limitato di worker in PHP-FPM e della differenza tra il codice PHP memorizzato e una risposta già generata.

Ogni riga della tabella è una Ipotesi, non una diagnosi definitiva. Le risposte lente in condizioni di parallelismo possono, ad esempio, coincidere con una limitazione della CPU, ma possono anche essere causate da worker occupati o da un database in attesa. Verifica quindi, se possibile, più segnali contemporaneamente e per lo stesso carico di lavoro, invece di dedurre il cambio di tariffa da un singolo sintomo.

Durante l'analisi, separa i Tempo di risposta Una richiesta in termini di throughput: una risposta singola più veloce non implica automaticamente che, in caso di elevata concorrenza, venga elaborato un numero corrispondentemente maggiore di richieste al secondo. Al contrario, un sistema può raggiungere un buon throughput e tuttavia far attendere più a lungo le singole richieste.

Anche il tempo di caricamento percepito della pagina non è da equiparare al tempo di risposta lato server. Dopo la risposta, ad esempio, possono essere caricate ulteriori risorse ed elaborate dal browser. Un potenziamento della CPU nell’hosting riguarda solo la parte interessata sul lato server; per un confronto equo, lo stato della cache, la pagina richiesta e il parallelismo dovrebbero rimanere invariati.

Per quanto riguarda la cache, vale inoltre la pena fare una distinzione concettuale: OPcache memorizza il codice PHP compilato e consente così di evitare una nuova compilazione. Una cache di pagina, invece, conserva una risposta già generata. Un rapido accesso alla cache non dimostra quindi né che le richieste dinamiche dispongano di risorse CPU sufficienti, né che OPcache sostituisca la logica dell’applicazione.

Rilevare le limitazioni e i tempi di attesa

Inizia la diagnosi con le richieste tipiche del tuo sito web: ad esempio una pagina pubblica del CMS, una ricerca e, nel caso di un negozio online, la procedura di checkout. Verifica se la rispettiva risposta proviene dalla cache della pagina. Confronta quindi le singole visite e un numero di richieste simultanee rappresentativo del tuo progetto, anziché considerare esclusivamente il numero totale di visitatori.

Se possibile, separa i tempo di CPU dall'applicazione, dal tempo di risposta complessivo e dai tempi di attesa per il database o i servizi esterni. Se la quota di CPU è ridotta, un processore più veloce può abbreviare solo una parte limitata della chiamata. Se non disponi di valori di misurazione adeguati, chiedi al fornitore se sono disponibili log, metriche o un'analisi adeguata.

In caso di carico parallelo, verifica se i worker disponibili sono a pieno carico e se i contatori di limite stanno aumentando. In PHP-FPM, limita pm.max_children le richieste gestite contemporaneamente da un pool; la possibilità di visualizzare questo valore o il carico dipende dal piano tariffario. I sistemi Linux cgroup v2 possono essere configurati in cpu.stat tra cui, tra l’altro, i contatori di throttling. Un aumento del valore del contatore costituisce un motivo per esaminare più attentamente il budget della CPU e il periodo di misurazione.

Se SSH e il file in questione sono accessibili, viene visualizzato cat /proc/self/cgroup l'assegnazione al cgroup del processo chiamante. Ciò non implica che le richieste web vengano eseguite nello stesso gruppo. Verifica i percorsi, i diritti e l'interpretazione con il provider; inoltre, i codici di errore non possono essere attribuiti in modo generalizzato a un determinato limite di ogni sistema di hosting condiviso.

Verifica la cache e confronta le tariffe

Verifica innanzitutto quali pagine pubbliche possono essere salvate in modo sicuro come risposta completa. Una Cache delle pagine può evitare l'elaborazione dinamica ripetuta in caso di corrispondenza. I contenuti personalizzati, il carrello e la procedura di pagamento richiedono invece una strategia di cache adeguata, affinché i visitatori non ricevano dati estranei o obsoleti.

Un altro approccio consiste nel ridurre il carico di lavoro in caso di cache miss: analizza le query lente al database ed elimina l’elaborazione dinamica superflua. Nel caso di un servizio esterno, il suo tempo di risposta può essere determinante; in tal caso, dovresti innanzitutto esaminare tale chiamata, anziché dare per scontato che la causa sia la CPU. La modifica più efficace dipende dal percorso effettivamente lento.

Da ciò va distinto OPcache: Memorizza il codice PHP compilato, ma non sostituisce né la cache completa della pagina né l'esecuzione della logica dell'applicazione. Verifica la disponibilità e le impostazioni nell'ambiente di runtime web. La CLI dispone di una propria impostazione OPcache; pertanto, un semplice controllo della riga di comando non è sufficiente a verificare la configurazione per le richieste web.

Per un confronto delle prestazioni, dovresti mettere a confronto le stesse richieste con le stesse versioni del software, un set di dati comparabile e lo stato della cache registrato. Ripeti il confronto con lo stesso livello di parallelismo e tieni conto delle risorse disponibili in termini di CPU, worker e memoria. In caso contrario, le condizioni di test potrebbero determinare una differenza senza fornire indicazioni affidabili sulle prestazioni del processore.

Tieni inoltre traccia separatamente della durata delle singole risposte e del numero di richieste elaborate in un determinato periodo. Una tariffa può sembrare conveniente per una singola richiesta, ma raggiungere comunque i propri limiti in caso di carico simultaneo. I valori emersi da un confronto valgono inizialmente solo per l’applicazione esaminata e le sue condizioni.

Una CPU più veloce o un budget maggiore?

Se una richiesta dinamica rappresentativa richiede prevalentemente risorse della CPU e non è limitata né dal numero di worker né dalla memoria né dal tempo a disposizione, è preferibile una maggiore Potenza pro-nucleo un'opzione tariffaria plausibile. Può ridurre la parte di calcolo della singola richiesta. Tuttavia, l'entità dell'impatto sulla risposta complessiva dipende comunque dall'applicazione e dai relativi tempi di attesa.

Se invece i dati indicano un rallentamento o l’esaurimento dei worker in presenza di più richieste simultanee, verifica se è necessario un Bilancio delle risorse. Aumentare il tempo di CPU può essere d’aiuto quando si raggiunge il limite della quota; al contempo, i worker aggiuntivi richiedono memoria e tempo di elaborazione sufficienti. Se il collo di bottiglia è rappresentato dal database o da servizi esterni, un aumento del budget di CPU da solo non costituisce una soluzione affidabile.

Prima di effettuare un cambiamento, vale la pena valutare se sia possibile ottimizzare l'installazione esistente. Una cache delle pagine adeguata o una query migliorata possono ridurre il carico dinamico senza che sia immediatamente necessario passare a un piano tariffario superiore. Ripeti la diagnosi dopo aver apportato una modifica in condizioni simili, in modo da poter distinguere il suo effetto da altre variabili.

A Il VPS come alternativa all'hosting condiviso Offre solitamente un maggiore controllo sul software e sulla configurazione, ma comporta anche maggiori responsabilità in materia di sicurezza, aggiornamenti e pianificazione della capacità. Le CPU virtuali non sono nuclei fisici esclusivi, salvo espressa dichiarazione del fornitore. Verifica quindi anche in questo caso l’effettiva assegnazione delle risorse e le condizioni contrattuali.

Prima di prendere una decisione, chiedi al fornitore informazioni sul modello di processore, sulla definizione del budget di tempo della CPU e sulla gestione dei picchi di carico. Chiarisci inoltre quali sono i limiti relativi ai worker e alla memoria, se i processi in background condividono lo stesso budget e quali contatori di limite puoi visualizzare. Solo queste informazioni consentono di valutare correttamente le prestazioni della CPU pubblicizzate in relazione al tuo piano tariffario specifico.