Gli elenchi di funzionalità a livello superficiale raramente includono i dettagli necessari per la valutazione di un hosting WordPress gestito per lo sviluppo. Serve capire come l’allocazione dei thread PHP influisce sulla gestione delle richieste simultanee, come più livelli di cache lavorano insieme per ridurre il carico del database e se la containerizzazione previene effettivamente i problemi in condizioni reali.
Questa guida illustra l’architettura tecnica di Kinsta per la gestione dei thread PHP, la cache multilivello e l’isolamento dei container. Includiamo anche le dichiarazioni di Nikola Djuric, un agente di supporto senior del team di Kinsta, sulle complessità della gestione dei thread PHP.
Cominciamo con il modo in cui PHP gestisce le richieste.
Cosa sono i thread PHP e perché sono importanti per le prestazioni di WordPress
I thread PHP elaborano le richieste in entrata non memorizzate nella cache. Ogni thread gestisce una richiesta alla volta, quindi il numero di thread disponibili influisce direttamente sul numero di visitatori che un sito può servire contemporaneamente.
Quando un visitatore carica una pagina non memorizzata nella cache, invia un modulo o aggiunge un articolo al carrello:
- Il server web riceve la richiesta e la passa a PHP-FPM.
- PHP assegna la richiesta a un thread disponibile.
- Questo thread esegue il codice PHP, recupera i dati del database e genera un output dinamico.
- Una volta completata l’operazione, il thread diventa nuovamente disponibile.
La maggior parte delle persone non sa che una richiesta non memorizzata nella cache utilizza un thread PHP e che la velocità di elaborazione dipende dal tempo di risposta di PHP e MySQL.
Le richieste in cache saltano l’intero processo (non toccano affatto PHP) ed è per questo che il tasso di cache HIT è il fattore più importante per determinare il numero di thread effettivamente necessari.
I siti WooCommerce, le dashboard per gli iscritti, il traffico delle API REST e le configurazioni headless bypassano la cache molto più spesso, il che significa che consumano rapidamente i thread.
Ad esempio, se la risposta media dell’API richiede 250 millisecondi, ogni thread può elaborare quattro richieste al secondo. Con otto thread, il massimo rendimento teorico è di 32 richieste al secondo. Tuttavia, questo vale solo se ogni richiesta viene completata in 250 ms esatti.
Come il traffico simultaneo consuma i thread di PHP
Il numero di thread è più importante durante il traffico simultaneo. Se il tuo sito ha quattro thread e riceve sei richieste simultanee senza cache:
- Quattro richieste iniziano ad essere elaborate immediatamente.
- Due attendono un thread libero.
Se il nuovo traffico arriva più velocemente di quanto i thread possano liberarsi, il backlog cresce.
Le query di database lente peggiorano la situazione. Ad esempio, una query del database che dura 10 secondi blocca un thread per tutta la sua durata. Se ricevi tre richieste contemporanee che attivano ciascuna una query lenta, hai consumato tre thread per un totale di 30 secondi. In questo lasso di tempo, i thread rimanenti gestiscono tutto il resto del traffico.
Se aggiungi filtri WooCommerce, pagine di account o flussi di pagamento, la pressione sui thread sale ulteriormente.
Per quanto riguarda i thread PHP, ai siti semplici ne bastano quattro. Ma per l’e-commerce, qualsiasi numero inferiore a sei è basso a causa dell’elevato rapporto di bypass della cache.
La relazione tra numero di thread e tempo di esecuzione
Un modo approssimativo per stimare il fabbisogno di thread:
Thread necessari ≈ (Richieste non memorizzate al secondo × Tempo medio di esecuzione)
In base a ciò, un sito con 10 richieste non memorizzate al secondo e un tempo medio di esecuzione di 0,5 secondi ha bisogno di circa cinque thread per gestire il carico senza accodamenti.
Questo spiega perché la semplice aggiunta di più thread non garantisce prestazioni migliori. Se le query lente del database fanno passare il tempo medio di esecuzione da 0,5 secondi a due secondi, il fabbisogno di thread quadruplica.
La soluzione è un’esecuzione più rapida del codice. L’ottimizzazione delle query, la riduzione delle chiamate alle API esterne e l’implementazione di una corretta cache degli oggetti possono ridurre drasticamente i tempi di esecuzione e i thread necessari per gestire il traffico.
L’assegnazione dei thread PHP nei piani Kinsta
Kinsta assegna i thread PHP in base alle risorse CPU e RAM disponibili nel container di ogni sito (ogni sito Kinsta viene eseguito nel proprio container LXD, quindi le risorse sono isolate).
Modelli generali tra i piani:
- Livello base: 2-4 thread a 256MB per thread. È l’ideale per i blog e i siti a contenuto statico con alti tassi di utilizzo della cache.
- Livello medio: 6-8 thread con 256 MB per thread, con alcuni piani di agenzia che aumentano la memoria a 512 MB per thread.
- Livello superiore: 10-16 thread con 512MB per thread, adatti a siti ad alto traffico o complessi.
- Multisito: 8-14 thread a seconda del livello.
È possibile regolare l’allocazione dei thread all’interno di MyKinsta > Info > Prestazioni PHP, aumentando il pool di memoria o il numero di thread in base all’andamento del traffico del tuo sito.
Questa flessibilità permette di regolare il PHP in base all’effettivo carico di lavoro, invece di affidarsi ai valori predefiniti.
Stimare i requisiti di thread PHP per il proprio sito
I diversi tipi di sito necessitano di allocazioni di thread personalizzate in base alla quantità di traffico che bypassa la cache:
- Siti a contenuto statico. 2-4 thread sono di solito sufficienti perché le pagine in cache servono quasi tutto il traffico.
- Negozi WooCommerce. Inizia con 8-12 thread a seconda delle dimensioni del catalogo, della complessità dei filtri e del volume di acquisti.
- Applicazioni API o headless. Stima in base al tempo di esecuzione (ad esempio, richieste di 0,25s = circa 4 al secondo per thread).
- Siti a iscrizione e piattaforme LMS. Gli utenti registrati non possono accedere alla cache, quindi si comportano in modo simile all’e-commerce.
Le statistiche di MyKinsta ti aiutano a identificare i pattern di utilizzo dei thread.
Se noti errori di accodamento delle richieste o di timeout durante le finestre ad alto traffico, è probabile che l’allocazione dei thread debba essere modificata.
Cosa succede quando si supera il limite di thread PHP
L’esaurimento dei thread segue uno schema prevedibile:
Non c’è coda per le richieste. Il numero di thread PHP di cui dispone il sito determina il numero di richieste non memorizzate nella cache che possono essere elaborate contemporaneamente. Quando arriva una richiesta e non c’è nessun thread disponibile, si attende che se ne liberi uno. Se ciò non avviene abbastanza velocemente, si verificano gli errori 502 o 503 bad gateway timeout.
Sintomi tipici:
- Le richieste si accodano all’interno di NGINX/PHP-FPM quando tutti i thread sono impegnati nell’elaborazione.
- Gli utenti finali sperimentano per primi ritardi, come ad esempio icone di caricamento che girano, fasi di checkout lente o chiamate AJAX interrotte.
- Compaiono errori 502 o 504 quando la capacità della coda si riempie completamente.
- Il recupero avviene in genere entro 30-120 secondi dopo che le funzioni lente sono terminate e la cache si è “riscaldata”.
Le query del database lente sono la causa più comune.
Le query al database lente richiedono più tempo per essere elaborate dai thread PHP ed è per questo che in genere danneggiano estremamente le prestazioni del sito.
Le chiamate API esterne creano problemi simili. I gateway di pagamento, i servizi di calcolo delle tasse e le API di spedizione bloccano spesso i thread durante il checkout.
Per diagnosticare l’esaurimento dei thread è necessario esaminare più fonti di dati. Lo strumento APM di Kinsta traccia le richieste lente e identifica i colli di bottiglia, mentre i log delle query lente rivelano problemi di prestazioni del database. Le metriche delle code di Nginx mostrano i modelli di arretratezza delle richieste e il rapporto cache HIT/MISS indica se la cache sta funzionando.
La soluzione è ottimizzare il tempo di esecuzione:
- Le query di database lente necessitano di indicizzazione, ottimizzazione delle query o riduzione del numero di query.
- I plugin più pesanti potrebbero richiedere la sostituzione con alternative più leggere.
- Le attività di cron dovrebbero essere spostate nelle ore non di punta.
- Le chiamate API esterne beneficiano della cache, dell’elaborazione in background o di interruttori.
L’ottimizzazione dovrebbe precedere l’aggiunta di altri thread. L’aumento del numero di thread è utile solo se il tempo medio di esecuzione è sotto controllo.
L’architettura di cache multistrato di Kinsta
La cache riduce la frequenza con cui le richieste raggiungono PHP. Kinsta utilizza tre livelli:
- La cache Edge serve contenuti statici da posizioni globali vicine ai visitatori.
- La cache degli oggetti con Redis riduce il carico del database memorizzando i risultati delle query.
- Il CDN di Kinsta fornisce risorse statiche da postazioni edge distribuite.
Questi livelli lavorano insieme per ridurre al minimo le richieste che raggiungono i thread PHP e il database.
Cache Edge attraverso Cloudflare
La rete edge globale di Cloudflare serve pagine HTML memorizzate nella cache in base a chiavi di cache che tengono conto di:
- URL e parametri di query
- Alcuni cookie
- Stato di autenticazione
- Cookie di carrello/sessione di WooCommerce
In questo modo si evita che i contenuti personalizzati vengano serviti agli utenti sbagliati.
Le regole di bypass della cache impediscono anche la memorizzazione nella cache di contenuti dinamici che devono rimanere freschi, come le aree di amministrazione di WordPress o le pagine di checkout di WooCommerce.
La differenza di prestazioni significa che le richieste in edge cache bypassano completamente i thread PHP e non raggiungono mai l’installazione di WordPress. Un sito in cui l’80% delle richieste raggiunge la cache edge ha bisogno di thread PHP solo per il restante 20% del traffico.
Cache degli oggetti con Redis
Kinsta fornisce Redis come componente aggiuntivo invece di richiedere plugin di terze parti, che possono garantire il funzionamento di Redis con il sistema di cache degli oggetti di WordPress.
Redis memorizza i risultati delle query del database, in modo che il server non debba ripetere l’esecuzione di tali query.
Redis è un moltiplicatore di prestazioni per siti ben strutturati, non un cerotto per query pesanti o tabelle non indicizzate.
Redis è utile quando:
- Molti utenti caricano gli stessi dati (post, prodotti, categorie)
- I negozi WooCommerce eseguono ricerche di categorie o controlli di prodotti
- Le API ripetono query identiche
Tuttavia, Redis non velocizza la logica PHP intrinsecamente lenta, il blocco delle chiamate API esterne o i loop mal ottimizzati.
Kinsta CDN per la distribuzione globale delle risorse
Il CDN di Kinsta serve le risorse statiche da più di 260 località globali. Questo approccio riduce la latenza per i visitatori internazionali ed elimina il carico di risorse statiche dal server di origine. Inoltre, converte automaticamente le immagini nel formato WebP quando i browser lo supportano.
Le intestazioni di controllo della cache determinano la durata di conservazione delle risorse da parte del CDN. Puoi configurare la durata della cache per diversi tipi di risorse in base alla loro frequenza di modifica. Il CSS Core, ad esempio, può sopportare un periodo di cache più lungo. L’eliminazione della cache per entrambi i livelli è gestita da MyKinsta, sia singolarmente che per entrambi.
Tra il CDN di Kinsta e la cache Edge, puoi gestire pagine HTML, contenuti dinamici e risorse statiche. Insieme, garantiscono che la maggior parte delle richieste non raggiunga mai il tuo server di origine o consumi thread PHP.
Isolamento dei container: risolvere il problema dei vicini invadenti
Gli ambienti di hosting condiviso spesso soffrono quando un sito consuma troppe risorse. Kinsta evita completamente questo problema grazie all’isolamento dei container LXD, dando a ogni sito:
- CPU dedicata
- RAM dedicata
- File system isolato
- Stack software indipendente
Gli altri siti non possono “rubare” le tue risorse e i problemi di un container non possono avere alcun impatto sugli altri.
I container vengono eseguiti su hardware di calcolo ottimizzato, garantendo prestazioni stabili e prevedibili anche in caso di picchi di traffico.
Scalare in base alle esigenze del sito
Quando il tuo sito ha bisogno di più risorse di quelle previste dal tuo piano attuale, hai la possibilità di scalare verticalmente all’interno del tuo container.
Ad esempio, l’add-on per le prestazioni di PHP fornisce thread e memoria aggiuntivi per i siti che necessitano di maggiore potenza di calcolo.
Puoi anche passare a un piano di livello superiore, aumentando così le risorse allocate del tuo container, il numero di thread e la memoria per thread. Questa opzione è adatta ai siti che potrebbero superare la capacità del loro piano attuale.
La chiave è capire se hai bisogno di ottimizzazione o di capacità aggiuntiva. Se i thread si saturano ma l’utilizzo della CPU rimane basso, il problema è rappresentato dalle query lente o dalle chiamate API esterne, non dal numero di thread. Aggiungere thread senza affrontare il problema dell’esecuzione lenta significa semplicemente far attendere più a lungo le richieste per completare i processi lenti.
Riepilogo
La gestione dei thread in PHP, la cache multilivello e l’isolamento dei container svolgono tutti un ruolo fondamentale per le prestazioni di WordPress su scala. Capire come funzionano i thread e come la cache riduce il carico che gestiscono rende più facile scegliere il piano giusto e ottimizzare il tuo sito in modo efficace.
Se vuoi scoprire come l’infrastruttura di Kinsta gestisce i carichi di lavoro di WordPress, esplora oggi stesso la piattaforma di hosting gestito di Kinsta.
