Cosa sono i thread PHP e perch\u00e9 sono importanti per le prestazioni di WordPress<\/h2>\n
I thread PHP elaborano le richieste in entrata non memorizzate nella cache. Ogni thread gestisce una richiesta alla volta<\/strong>, quindi il numero di thread disponibili influisce direttamente sul numero di visitatori che un sito pu\u00f2 servire contemporaneamente.<\/p>\n Quando un visitatore carica una pagina non memorizzata nella cache, invia un modulo o aggiunge un articolo al carrello:<\/p>\n La maggior parte delle persone non sa che una richiesta non memorizzata nella cache utilizza un thread PHP e che la velocit\u00e0 di elaborazione dipende dal tempo di risposta di PHP e MySQL.<\/p><\/blockquote>\n Le richieste in cache saltano l’intero processo (non toccano affatto PHP) ed \u00e8 per questo che il tasso di cache I siti WooCommerce, le dashboard per gli iscritti, il traffico delle API REST e le configurazioni headless bypassano la cache molto pi\u00f9 spesso, il che significa che consumano rapidamente i thread.<\/p>\n Ad esempio, se la risposta media dell’API richiede 250 millisecondi, ogni thread pu\u00f2 elaborare quattro richieste al secondo. Con otto thread, il massimo rendimento teorico \u00e8 di 32 richieste al secondo. Tuttavia, questo vale solo se ogni richiesta viene completata in 250 ms esatti.<\/p>\n Il numero di thread \u00e8 pi\u00f9 importante durante il traffico simultaneo. Se il tuo sito ha quattro thread e riceve sei richieste simultanee senza cache:<\/p>\n Se il nuovo traffico arriva pi\u00f9 velocemente di quanto i thread possano liberarsi, il backlog cresce.<\/p>\n 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.<\/p>\n Se aggiungi filtri WooCommerce, pagine di account o flussi di pagamento, la pressione sui thread sale ulteriormente.<\/p>\n Per quanto riguarda i thread PHP, ai siti semplici ne bastano quattro. Ma per l’e-commerce, qualsiasi numero inferiore a sei \u00e8 basso a causa dell’elevato rapporto di bypass della cache.<\/p><\/blockquote>\n Un modo approssimativo per stimare il fabbisogno di thread:<\/p>\n Thread necessari \u2248 (Richieste non memorizzate al secondo \u00d7 Tempo medio di esecuzione)<\/strong><\/p>\n In base a ci\u00f2, 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.<\/p>\n Questo spiega perch\u00e9 la semplice aggiunta di pi\u00f9 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.<\/p>\n La soluzione \u00e8 un’esecuzione pi\u00f9 rapida del codice. L’ottimizzazione delle query<\/a>, 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.<\/p>\n 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<\/a>, quindi le risorse sono isolate).<\/p>\n Modelli generali tra i piani:<\/p>\n \u00c8 possibile regolare l’allocazione dei thread all’interno di MyKinsta<\/strong><\/a> > Info<\/strong> > Prestazioni PHP<\/strong>, aumentando il pool di memoria o il numero di thread in base all’andamento del traffico del tuo sito.<\/p>\n Questa flessibilit\u00e0 permette di regolare il PHP in base all’effettivo carico di lavoro, invece di affidarsi ai valori predefiniti.<\/p>\n I diversi tipi di sito necessitano di allocazioni di thread personalizzate in base alla quantit\u00e0 di traffico che bypassa la cache:<\/p>\n Le statistiche di MyKinsta<\/a> ti aiutano a identificare i pattern di utilizzo dei thread.<\/p>\n Se noti errori di accodamento delle richieste o di timeout durante le finestre ad alto traffico, \u00e8 probabile che l’allocazione dei thread debba essere modificata.<\/p>\n L’esaurimento dei thread segue uno schema prevedibile:<\/p>\n Non c’\u00e8 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’\u00e8 nessun thread disponibile, si attende che se ne liberi uno. Se ci\u00f2 non avviene abbastanza velocemente, si verificano gli errori 502 o 503 bad gateway timeout.<\/p><\/blockquote>\n Sintomi tipici:<\/p>\n Le query del database lente sono la causa pi\u00f9 comune.<\/p>\n Le query al database lente richiedono pi\u00f9 tempo per essere elaborate dai thread PHP ed \u00e8 per questo che in genere danneggiano estremamente le prestazioni del sito.<\/p><\/blockquote>\n 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.<\/p>\n Per diagnosticare l’esaurimento dei thread \u00e8 necessario esaminare pi\u00f9 fonti di dati. Lo strumento APM di Kinsta<\/a> 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 La soluzione \u00e8 ottimizzare il tempo di esecuzione:<\/p>\n L’ottimizzazione dovrebbe precedere l’aggiunta di altri thread. L’aumento del numero di thread \u00e8 utile solo se<\/em> il tempo medio di esecuzione \u00e8 sotto controllo.<\/p>\n La cache riduce la frequenza con cui le richieste raggiungono PHP. Kinsta utilizza tre livelli:<\/p>\n Questi livelli lavorano insieme per ridurre al minimo le richieste che raggiungono i thread PHP e il database.<\/p>\n La rete edge globale di Cloudflare serve pagine HTML memorizzate nella cache in base a chiavi di cache che tengono conto di:<\/p>\n In questo modo si evita che i contenuti personalizzati vengano serviti agli utenti sbagliati.<\/p>\n 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.<\/p>\n 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.<\/p>\n Kinsta fornisce Redis come componente aggiuntivo<\/a> invece di richiedere plugin di terze parti, che possono garantire il funzionamento di Redis con il sistema di cache degli oggetti di WordPress.<\/p>\n Redis memorizza i risultati delle query del database, in modo che il server non debba ripetere l’esecuzione di tali query.<\/p>\n Redis \u00e8 un moltiplicatore di prestazioni per siti ben strutturati, non un cerotto per query pesanti o tabelle non indicizzate.<\/p><\/blockquote>\n Redis \u00e8 utile quando:<\/p>\n Tuttavia, Redis non velocizza la logica PHP intrinsecamente lenta, il blocco delle chiamate API esterne o i loop mal ottimizzati.<\/p>\n Il CDN di Kinsta<\/a> serve le risorse statiche da pi\u00f9 di 260 localit\u00e0 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.<\/p>\n 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\u00f2 sopportare un periodo di cache pi\u00f9 lungo. L’eliminazione della cache per entrambi i livelli \u00e8 gestita da MyKinsta, sia singolarmente che per entrambi.<\/p>\n 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.<\/p>\n Gli ambienti di hosting condiviso<\/a> spesso soffrono quando un sito consuma troppe risorse. Kinsta evita completamente questo problema grazie all’isolamento dei container LXD<\/strong>, dando a ogni sito:<\/p>\n Gli altri siti non possono “rubare” le tue risorse e i problemi di un container non possono avere alcun impatto sugli altri.<\/p>\n I container vengono eseguiti su hardware di calcolo ottimizzato, garantendo prestazioni stabili e prevedibili anche in caso di picchi di traffico.<\/p>\n Quando il tuo sito ha bisogno di pi\u00f9 risorse di quelle previste dal tuo piano attuale, hai la possibilit\u00e0 di scalare verticalmente all’interno del tuo container.<\/p>\n\n
HIT<\/code> \u00e8 il fattore pi\u00f9 importante per determinare il numero di thread effettivamente necessari.<\/p>\nCome il traffico simultaneo consuma i thread di PHP<\/h3>\n
\n
La relazione tra numero di thread e tempo di esecuzione<\/h3>\n
L’assegnazione dei thread PHP nei piani Kinsta<\/h2>\n
\n
![\"La](\"https:\/\/kinsta.com\/wp-content\/uploads\/2025\/12\/php-performance-screen.png\")
Stimare i requisiti di thread PHP per il proprio sito<\/h2>\n
\n
![\"I](\"https:\/\/kinsta.com\/wp-content\/uploads\/2025\/12\/php-threads-table.png\")
Cosa succede quando si supera il limite di thread PHP<\/h2>\n
\n
HIT<\/code>\/MISS<\/code> indica se la cache sta funzionando.<\/p>\n\n
L’architettura di cache multistrato di Kinsta<\/h2>\n
\n
Cache Edge attraverso Cloudflare<\/h3>\n
\n
Cache degli oggetti con Redis<\/h3>\n
\n
Kinsta CDN per la distribuzione globale delle risorse<\/h3>\n
Isolamento dei container: risolvere il problema dei vicini invadenti<\/h2>\n
\n
Scalare in base alle esigenze del sito<\/h3>\n