Confronto tra gestori PHP: impatto sulle prestazioni del web hosting

Questo confronto tra gestori PHP mostra come mod_php, CGI, FastCGI, PHP-FPM e LSAPI Prestazioni influenzano il tuo hosting, dal carico della CPU alle latenze di coda. Spiego in modo concreto quale scelta fare con WordPress, WooCommerce e i picchi di traffico. Tempo di caricamento riduce i costi e allo stesso tempo preserva le risorse.

Punti centrali

• PHP-FPM scalabile in modo più efficiente rispetto a mod_php e FastCGI.
• LSAPI fornisce i valori migliori su LiteSpeed.
• Isolamento per utente aumenta la sicurezza.
• OPcache e Redis riducono le latenze.
• P95/P99 Mostra l'esperienza reale degli utenti.

Come funzionano gli handler PHP

Un gestore PHP collega il server web all'interprete e controlla Processi, memoria e I/O per ogni richiesta. CGI avvia un nuovo processo per ogni richiesta e ricarica le configurazioni, generando overhead e rallentando il Latenza aumentato. Le varianti moderne come FastCGI, PHP-FPM o LSAPI mantengono i worker sempre disponibili, risparmiando così tempo di avvio, cambi di contesto e cicli CPU. OPcache rimane in memoria, quindi il bytecode non deve essere compilato ogni volta e le pagine dinamiche rispondono più rapidamente. Allo stesso tempo, la gestione dei processi decide quante richieste simultanee possono essere eseguite, come vengono impostate le priorità e come possono essere attenuati i picchi di carico.

Confronto diretto dei gestori più diffusi

La scelta dell'handler determina il Scala, il modello di sicurezza e il fabbisogno di RAM di un'applicazione. mod_php integra PHP nel processo Apache e garantisce tempi di risposta brevi, ma soffre di scarsa Isolamento tra account. CGI separa gli utenti in modo pulito, ma richiede molto tempo di CPU per ogni richiesta. FastCGI riduce il sovraccarico, ma rimane meno efficiente di un PHP-FPM ben ottimizzato. LSAPI fa ancora di più quando si utilizza LiteSpeed e stabilizza in particolare le latenze di coda in caso di molte connessioni simultanee.

gestore	Prestazioni	Sicurezza	Requisiti di RAM	Scalabilità	Scenario operativo
mod_php	Alto	Basso	Basso	Medio	Siti piccoli, picchi rari
CGI	Basso	Alto	Alto	Basso	Contenuti statici, test
FastCGI	Medio	Medio	Medio	Medio	soluzione provvisoria
PHP-FPM	Molto alto	Alto	Basso	Alto	Hosting condiviso, CMS
LSAPI	Il più alto	Medio	Molto basso	Molto alto	Traffico intenso, e-commerce

PHP-FPM nella pratica: processi, pool, ottimizzazione

PHP-FPM funziona con pool di worker che prelevano le richieste da una coda e quindi Picchi di carico ammortizzare elegantemente. Imposta un pool separato per ogni sito web, in modo che la configurazione, i limiti e il contesto utente rimangano separati e il Sicurezza aumenta. Nella pratica, le impostazioni adattive come pm = dynamic o ondemand sono vantaggiose perché il numero di processi attivi si adatta alla domanda. È fondamentale dimensionare correttamente pm.max_children e i limiti di tempo, in modo che la coda non cresca e rimangano comunque riserve di RAM. Per iniziare, consiglio di verificare i parametri in modo strutturato; i dettagli sulla messa a punto sono spiegati qui: Gestione dei processi PHP-FPM.

LSAPI e LiteSpeed: prestazioni eccellenti in condizioni di elevata simultaneità

LSAPI mantiene i processi PHP in memoria e riduce i cambi di contesto, consentendo la generazione di contenuti dinamici con HTTP/3 e QUIC ancora più fluidi. A pieno carico, la latenza P95/P99 rimane più stabile rispetto a molte alternative, il che Esperienza dell'utente visibilmente migliorato. Nelle pagine dello shop e dei contenuti vedo regolarmente più richieste al secondo e TTFB più brevi, soprattutto quando OPcache e cache del server lavorano insieme. Il vantaggio non si manifesta solo nei valori medi, ma anche nelle sessioni simultanee, nelle sessioni con cache miss e nei worker PHP „freddi“. Chi vuole capire la differenza nell'architettura può leggere la panoramica su LiteSpeed vs Nginx e poi decide in merito allo stack.

WordPress e WooCommerce: classificare correttamente i valori misurati

Con WordPress ottengo prestazioni elevate con PHP 8.2 su FPM o LSAPI. req/s, mentre WooCommerce gestisce un numero leggermente inferiore di richieste al secondo grazie alle sessioni, alla logica del carrello e a un maggiore accesso al database. Il test diventa significativo solo in condizioni realistiche. Traffico con cache hit e miss misti. Il CSS critico, la cache degli oggetti e le connessioni persistenti spostano il limite oltre il quale si verificano i colli di bottiglia. Particolarmente utili sono i TTL brevi per i contenuti che cambiano frequentemente e le chiavi cache differenziate per lingua, stato dell'utente e tipo di dispositivo. In questo modo la pagina rimane veloce anche se fornisce contenuti personalizzati.

Sicurezza e isolamento: pool, contesto utente, limiti

Per l'hosting multiutente preferisco separati Piscine per account, in modo che diritti, percorsi e limiti rimangano ben separati. mod_php condivide un contesto comune, il che rende il Il rischio aumenta se un progetto presenta delle lacune. FPM o LSAPI con configurazioni per utente riducono notevolmente questa superficie di attacco, poiché i processi vengono eseguiti sotto il rispettivo utente. A ciò si aggiunge la possibilità di impostare diverse opzioni php.ini a livello di progetto senza influenzare altri siti. I limiti di risorse come max_execution_time e memory_limit per pool impediscono che valori anomali rallentino il server.

Consumo delle risorse e pianificazione della RAM

Ogni worker PHP occupa, a seconda del codice, delle estensioni e OPcache-Memoria che varia notevolmente in termini di dimensioni, motivo per cui misuro l'occupazione effettiva invece di fare supposizioni. Strumenti come ps, top o systemd-cgtop mostrano quanta RAM occupano realmente i worker attivi e quando. Scambio minaccia. Successivamente, imposto pm.max_children in modo conservativo, lascio spazio per il database, il server web e i servizi cache e osservo la latenza P95 al di sotto del picco. Se rimangono delle riserve, aumento gradualmente il numero di child e ricontrollo. In questo modo, la capacità totale cresce in modo controllato, senza sovraccaricare il server.

Metodologia di misurazione: da TTFB a P99

Non valuto solo i valori medi, ma soprattutto P95– e latenze P99, perché riflettono l'esperienza reale sotto carico. Uno stack può funzionare con un throughput identico e tuttavia avere prestazioni peggiori con P99 se Code crescere. Per questo motivo provo cache fredde e calde, mescolo richieste di lettura e scrittura e utilizzo valori di concorrenza realistici. Senza il riscaldamento OPcache interpreto i risultati con cautela, poiché molti sistemi diventano notevolmente più veloci dopo poche chiamate di riscaldamento. Solo dopo aver eseguito test rappresentativi decido in merito a gestori, strategia di caching e limiti di processo.

Guida decisionale per la scelta dell'operatore

Per pagine piccole con pochi accessi è sufficiente mod_php o un economico FPM-Configurazione, purché siano stati affrontati gli aspetti relativi alla sicurezza. Se la simultaneità aumenta, passo a PHP-FPM con pool separati per ogni progetto e attivo OPcache in modo coerente. Per negozi fortemente dinamici e con molte sessioni, preferisco LiteSpeed con LSAPI per mantenere bassi i valori P95 e P99. Chi per motivi di prezzo o di architettura rimane con Apache/Nginx, ottiene ottimi risultati con FPM ben ottimizzato. In tutti i casi, la misurazione in condizioni realistiche conta più dei benchmark su un sistema vuoto.

Configurazione pratica: cache, sessioni, limiti di tempo

Punto su OPcache con generosa Memoria-Allocazione, in modo che il bytecode venga rimosso raramente, e spostare le sessioni, se possibile, in Redis, per evitare il blocco dei file. Ciò riduce i tempi di attesa in caso di accessi simultanei e pagine personalizzate. Per i servizi esterni definisco timeout e circuit breaker chiari, in modo che i guasti non blocchino l'intera richiesta. A livello di applicazione, mantengo i TTL della cache abbastanza brevi da garantire l'attualità, ma abbastanza lunghi da garantire un elevato hit ratio. Chi raggiunge regolarmente i limiti dei worker può trovare qui un punto di partenza: Bilanciare correttamente i worker PHP.

Confronto costi-benefici e funzionamento

Valuto il Costi un cambiamento rispetto al guadagno misurabile in termini di latenza, throughput e affidabilità. Il passaggio da FastCGI a PHP-FPM spesso porta più di un cambiamento del numero di versione secondario di PHP, perché Processo-Management e Caching agiscono in modo continuo. LSAPI è particolarmente utile se LiteSpeed è già in uso e sono previsti molti visitatori contemporaneamente. Chi cambia lo stack dovrebbe monitorare attentamente i log e le metriche e preparare percorsi di rollback. Un funzionamento A/B pianificato su più giorni fornisce i risultati più affidabili.

Interazione tra server web: Apache-MPM, Nginx e Keep-Alive

In pratica, non è solo il gestore PHP a decidere, ma anche la modalità del server web. mod_php funziona con Apache in prefork-MPM, ma blocca l'utilizzo dei moderni modelli di eventi. Chi desidera utilizzare in modo efficiente HTTP/2, fasi Keep-Alive più lunghe e migliaia di connessioni, punta su Apache. evento + PHP-FPM o su Nginx/LiteSpeed come frontend. La conseguenza: il numero di worker PHP necessari non dipende dal numero di connessioni TCP, ma dal numero effettivo di allo stesso tempo richieste PHP in corso. Il multiplexing HTTP/2/3 riduce quindi il sovraccarico delle intestazioni sul server web, ma non modifica i pool PHP sottodimensionati.

Nginx inoltra tipicamente le richieste a FPM tramite FastCGI. Faccio attenzione a brevi read_timeout- e send_timeout-Valori sul proxy, altrimenti si verificano errori 502/504 in caso di upstream bloccati, anche se PHP continua a funzionare. Negli ambienti Apache limito Keep-Alive in modo che le connessioni inattive prolungate non occupino il thread pool. LiteSpeed ne astrae gran parte, ma sfrutta appieno i suoi vantaggi solo con LSAPI.

OPcache, JIT e precaricamento: cosa funziona davvero

OPcache è obbligatorio. In pratica, io lo dimensiono opcache.memory_consumption generoso (ad es. 192-512 MB a seconda del codice base) e aumenta opcache.max_accelerated_files, in modo che non si verifichino evictions. Per le build che vengono distribuite raramente, disattivo validare_timestamp oppure imposta un valore più alto riconvalida_freq, per risparmiare syscall. Precarico può accelerare i framework, ma è particolarmente efficace con una struttura di autocaricamento coerente. Il JIT di PHP raramente offre vantaggi nei carichi di lavoro web classici e può persino consumare RAM; lo attivo solo se i benchmark in condizioni reali lo confermano.

Gestione delle code e contropressione

La maggior parte dei colli di bottiglia non si verificano nella CPU, ma nella coda. Se arrivano più richieste di quante i worker possano elaborare, la coda cresce e la latenza P95/P99 aumenta vertiginosamente. Mi assicuro che pm.max_children abbastanza grande da assorbire i picchi tipici, ma abbastanza piccolo da mantenere una riserva di RAM. pm.max_requests Imposta un valore moderato (ad esempio 500-2000) per evitare che le perdite di memoria generino processi di lunga durata. Il listen.backlog deve corrispondere al backlog del server web, altrimenti il kernel interrompe le connessioni sotto carico. Misurando la frequenza di arrivo (richieste al secondo) e il tempo medio di servizio, è possibile valutare con un semplice calcolo della capacità a partire da quale concorrenza la latenza diminuisce.

Timeout, upload e file di grandi dimensioni

I caricamenti lunghi o le chiamate API bloccano i lavoratori. Definisco limiti chiari: tempo_di_esecuzione_max e timeout_richiesta_termine in FPM impediscono che le richieste difettose continuino a funzionare all'infinito. A livello di proxy sincronizzo proxy_read_timeout/fastcgi_read_timeout con i limiti FPM, in modo da evitare un 504 prematuro. Trasmetto in streaming i file di grandi dimensioni, limitando post_max_size e upload_max_filesize rigoroso e pianifica endpoint dedicati, in modo che il resto del traffico non ne risenta. Per i processi cron di lunga durata, sposto il lavoro in Spunti o CLI, invece di bloccare i frontend worker per minuti interi.

Sessioni e blocco in dettaglio

Le sessioni PHP sono impostate di default su bloccante. Una seconda richiesta dello stesso utente attende che la prima liberi la sessione, il che è fatale per WooCommerce se sono in esecuzione chiamate Ajax parallele. Interrompo anticipatamente gli accessi in scrittura alla sessione con session_write_close(), non appena non sono più necessarie modifiche. Con Redis come backend di sessione, la latenza I/O diminuisce, ma le regole di blocco rimangono importanti. Dietro i bilanciatori di carico, scelgo consapevolmente tra sessioni sticky (semplici, meno scalabili) e modelli stateless con cache di oggetti, in modo che la scalabilità orizzontale funzioni correttamente.

Monitoraggio e risoluzione dei problemi

Senza telemetria, l'ottimizzazione è un volo alla cieca. Attivo lo stato FPM e gli slowlog per ogni pool per individuare i colli di bottiglia e identificare le query che destano sospetti.

; per pool pm.status_path = /status ping.path = /ping ping.response = pong request_slowlog_timeout = 3s slowlog = /var/log/php-fpm/www-slow.log pm.max_requests = 1000

Se si verificano errori 502/504, controllo innanzitutto: la coda FPM è piena? C'è CPU steal o swap? Il timeout del server web è compatibile con i limiti FPM? Uno sguardo a smaps per lavoratore mostra l'occupazione RSS reale, mentre netstat/ss Rileva i backlog overflow. Per OPcache osservo la frequenza di accesso e il numero di rivalidazioni per evitare gli eviction.

Contenitori, socket e limiti delle risorse

Nei container utilizzo principalmente TCP anziché socket Unix tra server web e FPM, per evitare limiti di namespace e facilitare il bilanciamento del carico. È importante garantire la coerenza cgroupLimiti: se il contenitore ha solo 1-2 GB di RAM, pm.max_children deve essere corrispondentemente più piccolo, altrimenti interviene l'OOM killer. Le quote CPU influenzano notevolmente il tempo di risposta; pianifico il margine e verifico la latenza P95 al di sotto del limite. Le questioni relative a NUMA e Core Affinity diventano rilevanti in caso di carico molto elevato, mentre LSAPI ottimizza gran parte di esse internamente nelle configurazioni LiteSpeed.

Versioni multi-PHP ed estensioni

Molti host utilizzano più versioni di PHP in parallelo. Io isolo i pool per versione e mantengo Estensioni Snello. Ogni modulo aggiuntivo aumenta la RAM per ogni worker e può prolungare il tempo di avvio. Rimuovo sistematicamente le estensioni inutilizzate; spesso questo porta a un aumento maggiore rispetto a un piccolo aumento di pm.max_children. Durante l'aggiornamento, pianifico brevi fasi di riscaldamento per OPcache, in modo che dopo l'implementazione non tutti gli utenti subiscano contemporaneamente un avvio a freddo.

Ram diet e pianificazione realistica della capacità

Invece di valori forfettari, calcolo il fabbisogno medio e massimo di RAM per ogni worker con traffico live. Da ciò deduco: (RAM disponibile – sistema/DB/cache) / RAM per worker = massima pm.max_children ragionevole. Inoltre, mantengo una riserva di 15-25 % per burst, cache del kernel e picchi imprevisti. Se l'applicazione gonfia sporadicamente la memoria, abbasso il limite o riduco pm.max_requests per riciclare i processi più frequentemente.

Strategia di test: carico riproducibile e modelli reali

Utilizzo profili di test che combinano cache fredde e calde, combinano GET/POST e aumentano gradualmente la concorrenza. Importante: solo con OPcache attivo e tempi di riflessione realistici posso vedere se il sistema rimane stabile durante l'utilizzo. Un ramp-up di diversi minuti impedisce picchi artificiali all'avvio. La valutazione si concentra su TTFB e P95/P99, non solo su RTT medio o req/s puro.

Esempi di errori riscontrati nella pratica

• Molti 504 sotto il picco: coda FPM piena, backlog troppo piccolo, timeout sul proxy più stretti rispetto a FPM.
• Balbuzie durante i deploy: sostituzioni OPcache, mancanza di warmup, opcache.memory_consumption troppo piccolo.
• Buoni valori medi, P99 scadente: troppi processi di lunga durata (I/O, API esterne), mancanza di circuit breaking.
• CPU elevata, req/s basso: blocchi di sessione o query di database non memorizzate nella cache che limitano la serialità.

Sicurezza operativa e rollback

Ogni modifica all'handler o ai parametri del pool viene eseguita con Bandiere caratteristiche o gradualmente. Tengo sotto controllo gli errori e i log di lentezza, il P95 e il tasso di errore e definisco una chiara procedura di ripristino in caso di variazioni delle metriche. Un secondo pool con versione identica ma parametri diversi consente un rapido passaggio da A a B senza tempi di inattività. A pieno carico, è preferibile una breve riduzione automatica della concorrenza (backpressure) piuttosto che l'avvio incontrollato di nuovi worker.

Riassumendo brevemente

Per siti dinamici con molti utenti simultanei, preferisco LSAPI su LiteSpeed, mentre PHP-FPM su Apache o Nginx offre le migliori Tuttofare mod_php rimane un caso speciale per progetti molto semplici senza isolamento rigoroso. Sono fondamentali test realistici con OPcache caldo, limiti di pool ragionevoli e cache pulita. Chi riduce in modo affidabile le latenze misura P95/P99 e reagisce prima ai problemi di coda piuttosto che ai valori medi. In questo modo un'applicazione ottiene risposte notevolmente più veloci e maggiori riserve per il traffico di picco.