Come Ottimizzo PHP-FPM e OPcache su Plesk per Velocizzare i Siti

Se gestisci siti WordPress o applicazioni PHP su un server con Plesk, c’è una probabilità molto alta che tu stia lasciando sul tavolo una quantità significativa di prestazioni. Lo dico per esperienza diretta: nella mia carriera da sysadmin ho ottimizzato centinaia di server Plesk, e nella stragrande maggioranza dei casi la configurazione di default di PHP-FPM e OPcache è tristemente inadeguata. I valori predefiniti sono pensati per funzionare ovunque senza errori, non per offrire le migliori prestazioni. Il risultato? Siti WordPress che impiegano 3-5 secondi a caricarsi quando potrebbero farlo in meno di 1 secondo, server che vanno in sofferenza con poche decine di visitatori contemporanei, e risorse hardware pagate profumatamente che rimangono largamente inutilizzate.

In questa guida ti mostro esattamente come ottimizzo PHP-FPM e OPcache su Plesk, con i valori precisi che uso in produzione sui miei server. Non si tratta di teoria astratta: ti do le configurazioni reali, calcolate in base alla RAM disponibile, il numero di siti ospitati e il tipo di traffico. Vedremo come capire la differenza tra PHP-FPM e mod_php, come configurare il pool PHP-FPM con i valori corretti di pm.max_children, pm.start_servers, pm.min_spare_servers e pm.max_spare_servers, come abilitare e ottimizzare OPcache con i parametri giusti, come monitorare le prestazioni con la status page di PHP-FPM e come verificare il hit rate di OPcache. Ti mostrerò anche i benchmark prima e dopo, misurati con strumenti professionali come GTmetrix, Apache Bench e curl. Preparati a vedere i tuoi siti volare.

1. PHP-FPM vs mod_php: Perché PHP-FPM è Fondamentale

Prima di entrare nella configurazione, è importante capire cosa sia PHP-FPM e perché è superiore all’alternativa tradizionale. Questa comprensione ti aiuterà a capire il senso di ogni parametro che andremo a configurare.

mod_php è il metodo tradizionale per eseguire PHP: il motore PHP viene caricato direttamente dentro il processo di Apache come un modulo. Ogni processo Apache include l’interprete PHP, anche quando serve file statici come immagini o CSS. Questo significa che ogni processo Apache consuma la memoria necessaria per PHP, anche quando PHP non serve affatto. Su un server con molte connessioni contemporanee, questo spreco di memoria diventa enorme.

PHP-FPM (FastCGI Process Manager) è un’architettura completamente diversa: PHP gira come un servizio separato e indipendente dal web server. Apache (o Nginx) riceve le richieste e, solo quando la richiesta riguarda un file PHP, la inoltra a PHP-FPM tramite il protocollo FastCGI. PHP-FPM mantiene un pool di processi worker pronti a gestire le richieste PHP, riducendo drasticamente il tempo di inizializzazione. I vantaggi sono molteplici:

Migliore gestione della memoria: Solo i processi PHP-FPM consumano la memoria necessaria per PHP. Il web server resta leggero per servire i file statici.
Isolamento tra siti: Su Plesk, ogni dominio può avere il proprio pool PHP-FPM con le proprie risorse dedicate. Un sito sovraccarico non influenza gli altri.
Gestione avanzata dei processi: PHP-FPM offre modalità di gestione dei processi (static, dynamic, ondemand) che permettono di ottimizzare l’uso delle risorse in base al traffico effettivo.
Compatibilità con Nginx: PHP-FPM funziona nativamente sia con Apache che con Nginx, e Plesk supporta entrambi. Se usi Nginx come reverse proxy davanti ad Apache (la configurazione predefinita di Plesk), PHP-FPM è essenziale per ottenere il massimo delle prestazioni.
Status page: PHP-FPM offre una pagina di stato in tempo reale che mostra quanti processi sono attivi, quante richieste sono in coda, e la memoria utilizzata. Uno strumento diagnostico preziosissimo.

Su Plesk, PHP-FPM è la modalità consigliata e predefinita per le installazioni moderne. Se per qualche motivo il tuo server sta ancora usando mod_php o CGI, il primo passo è migrare a PHP-FPM. Per verificarlo, vai in Plesk → Domains → il tuo dominio → Impostazioni PHP e controlla che la voce “Esegui PHP come” sia impostata su “Applicazione FPM gestita dal server web” (oppure “FPM application served by Apache” / “FPM application served by Nginx” a seconda della tua configurazione).

2. Configurare il Pool PHP-FPM su Plesk: I Parametri Chiave

Questa è la parte più importante e quella dove la maggior parte degli amministratori sbaglia. Il pool PHP-FPM è l’insieme di processi worker che gestiscono le richieste PHP. La configurazione di default di Plesk è troppo conservativa: pochi processi attivi, che vanno in sofferenza rapidamente sotto carico. Vediamo come configurarli correttamente.

I parametri fondamentali sono quattro, e sono tutti legati tra loro:

pm (Process Manager): La modalità di gestione dei processi. Le opzioni sono:
- static: Mantiene sempre un numero fisso di processi. Usa più memoria ma offre le migliori prestazioni perché non c’è overhead di creazione/distruzione dei processi. Consigliato per server dedicati con traffico costante.
- dynamic: Adatta il numero di processi in base al traffico. È la scelta più comune e quella che consiglio nella maggior parte dei casi. I processi vengono creati e distrutti in base alla domanda, entro i limiti che configuriamo.
- ondemand: Crea i processi solo quando arriva una richiesta e li distrugge dopo un timeout di inattività. Usa meno memoria ma ha un leggero ritardo sulla prima richiesta. Consigliato per VPS con poca RAM o siti a basso traffico.
pm.max_children: Il numero massimo di processi PHP che possono essere attivi contemporaneamente. Questo è il parametro più critico. Se il valore è troppo basso, le richieste vengono messe in coda e il sito rallenta. Se è troppo alto, il server esaurisce la RAM e inizia a usare lo swap, peggiorando le prestazioni di tutto.
pm.start_servers: Il numero di processi avviati all’avvio del pool (solo con pm = dynamic). Deve essere un valore compreso tra min_spare_servers e max_spare_servers.
pm.min_spare_servers: Il numero minimo di processi inattivi (in standby) sempre pronti. Se scende sotto questo valore, PHP-FPM ne crea di nuovi.
pm.max_spare_servers: Il numero massimo di processi inattivi. Se ce ne sono troppi in standby, PHP-FPM ne termina alcuni per risparmiare memoria.

Come calcolare pm.max_children in base alla RAM:

Questa è la formula che uso io, e funziona in modo affidabile su tutti i server che gestisco. Ogni processo PHP-FPM per un sito WordPress tipico consuma circa 30-50 MB di RAM (puoi verificare il valore esatto sul tuo server con il comando ps aux –sort=-rss | grep php-fpm | head -20 e guardando la colonna RSS).

La formula è: pm.max_children = (RAM disponibile per PHP) / (Memoria media per processo)

Dove “RAM disponibile per PHP” è la RAM totale del server meno quella usata dal sistema operativo, dal web server, dal database e da altri servizi. In pratica:

Server con 2 GB di RAM: circa 1 GB disponibile per PHP → pm.max_children = 20-25
Server con 4 GB di RAM: circa 2,5 GB disponibili per PHP → pm.max_children = 50-60
Server con 8 GB di RAM: circa 5-6 GB disponibili per PHP → pm.max_children = 100-150
Server con 16 GB di RAM: circa 10-12 GB disponibili per PHP → pm.max_children = 200-300

Come configurare questi valori su Plesk:

Accedi a Plesk → Strumenti e Impostazioni → Impostazioni PHP per la configurazione a livello server (globale).
Oppure vai in Plesk → Dominio specifico → Impostazioni PHP → Impostazioni PHP-FPM per la configurazione per singolo dominio.
Nella sezione “Parametri aggiuntivi di PHP-FPM”, inserisci i valori. Per un server da 4 GB con configurazione dynamic, la mia configurazione tipica è:

Esempio per server 4 GB RAM, WordPress con traffico medio:

pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500
pm.process_idle_timeout = 10s

Esempio per VPS 2 GB RAM, pochi siti a basso traffico:

pm = ondemand
pm.max_children = 20
pm.process_idle_timeout = 10s
pm.max_requests = 500

Esempio per server dedicato 16 GB RAM, siti ad alto traffico:

pm = dynamic
pm.max_children = 250
pm.start_servers = 30
pm.min_spare_servers = 15
pm.max_spare_servers = 50
pm.max_requests = 1000

Il parametro pm.max_requests è fondamentale per prevenire memory leak: dopo il numero specificato di richieste, il processo viene terminato e ricreato, liberando eventuale memoria accumulata. Un valore tra 500 e 1000 è il mio standard. Non mettere 0 (infinito) a meno che tu non sia certo che non ci siano leak — con WordPress e i suoi plugin, i leak sono sempre dietro l’angolo.

3. Abilitare e Ottimizzare OPcache: Il Turbo per PHP

OPcache è forse l’ottimizzazione singola più impattante che puoi fare su un server PHP. Per capire perché, devi sapere come funziona PHP: ogni volta che una pagina PHP viene richiesta, il motore PHP deve leggere il file dal disco, compilarlo in bytecode, eseguire il bytecode e restituire il risultato. OPcache elimina i primi due passaggi memorizzando il bytecode compilato nella memoria condivisa (shared memory), così che alle richieste successive PHP trovi il bytecode già pronto per l’esecuzione. Il risultato è una riduzione del tempo di esecuzione di PHP del 50-70% in scenari reali.

Su Plesk, OPcache è generalmente abilitato di default, ma con valori troppo bassi. Ecco i parametri fondamentali e i valori che uso io:

opcache.enable = 1 — Abilita OPcache. Dovrebbe essere già attivo, ma verifica.
opcache.memory_consumption = 256 — La quantità di memoria (in MB) dedicata alla cache del bytecode. Il valore predefinito è spesso 64 o 128 MB, che è insufficiente per server con molti siti o siti WordPress con molti plugin. Per un server con 5-10 siti WordPress, 256 MB è il minimo consigliato. Per server con 20+ siti, considera 512 MB.
opcache.max_accelerated_files = 30000 — Il numero massimo di file PHP che possono essere memorizzati nella cache. Il valore predefinito (2000-4000) è ridicolmente basso: un singolo sito WordPress con WooCommerce e una decina di plugin può avere oltre 10.000 file PHP. Il valore massimo è 1000000, ma 30000 è un buon compromesso per la maggior parte dei server. Per server con molti siti, usa 50000 o 100000.
opcache.revalidate_freq = 60 — Ogni quanti secondi PHP controlla se i file sorgente sono cambiati. Il valore predefinito è 2 secondi, che è troppo frequente per un sito in produzione. Con 60 secondi, il controllo avviene una volta al minuto, riducendo le operazioni di I/O su disco. Su siti stabili in produzione puoi alzarlo anche a 120 o 300. Se stai sviluppando attivamente, metti 0 per controllare ad ogni richiesta.
opcache.validate_timestamps = 1 — Se impostato a 0, PHP non controllerà mai se i file sono cambiati, usando sempre la versione in cache. Massime prestazioni ma devi svuotare la cache manualmente ad ogni aggiornamento del codice. Consiglio di tenerlo a 1 in ambienti Plesk dove gli utenti aggiornano WordPress e i plugin tramite la dashboard.
opcache.interned_strings_buffer = 16 — Memoria dedicata alle stringhe internate (stringhe ripetute nel codice PHP). Il valore predefinito (4 o 8 MB) è spesso insufficiente. 16 MB è il mio standard.
opcache.save_comments = 1 — Necessario per molti framework PHP (incluso WordPress con alcuni plugin) che usano le annotations nei commenti. Mantienilo attivo.
opcache.fast_shutdown = 1 — Abilita una sequenza di shutdown più veloce dei processi. Non ha controindicazioni, attivalo sempre. (Nota: deprecato in PHP 8.x dove è sempre attivo.)

Come configurare OPcache su Plesk:

Vai in Plesk → Strumenti e Impostazioni → Impostazioni PHP (per la configurazione globale del server).
Seleziona la versione PHP che stai utilizzando (consiglio PHP 8.2 o 8.3 nel 2026).
Cerca la sezione “Impostazioni di OPcache” o modifica direttamente i valori in “Direttive PHP aggiuntive”.
Inserisci i seguenti valori nella casella delle direttive aggiuntive:

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=30000
opcache.revalidate_freq=60
opcache.validate_timestamps=1
opcache.interned_strings_buffer=16
opcache.save_comments=1

Salva e riavvia PHP-FPM con il comando: systemctl restart plesk-php82-fpm (adatta il numero di versione alla tua installazione, ad esempio plesk-php83-fpm per PHP 8.3).

Puoi anche configurare OPcache per singolo dominio andando in Plesk → Dominio → Impostazioni PHP → Direttive PHP aggiuntive. Questo è utile se hai siti con esigenze diverse: ad esempio un sito in sviluppo attivo potrebbe avere revalidate_freq=0 mentre i siti in produzione usano 60.

4. Monitorare PHP-FPM: La Status Page e i Comandi Essenziali

Ottimizzare senza monitorare è come guidare bendati. Dopo aver configurato PHP-FPM e OPcache, è fondamentale verificare che la configurazione funzioni e che non ci siano colli di bottiglia. PHP-FPM offre una status page integrata che è uno strumento diagnostico preziosissimo.

Abilitare la status page di PHP-FPM su Plesk:

Modifica il file di configurazione del pool PHP-FPM. Su Plesk, lo trovi in: /opt/plesk/php/8.2/etc/php-fpm.d/ (adatta il percorso alla tua versione PHP). I file dei pool per dominio sono generati automaticamente da Plesk.
Aggiungi (o verifica che ci sia) la direttiva: pm.status_path = /fpm-status
Per accedere alla status page dall’esterno, puoi configurare una location in Nginx. In alternativa, accedi via CLI direttamente sul server con il comando:
SCRIPT_NAME=/fpm-status SCRIPT_FILENAME=/fpm-status REQUEST_METHOD=GET cgi-fcgi -bind -connect /run/plesk-php82-fpm.sock
Un metodo più pratico è usare curl puntando al socket Unix:
curl –unix-socket /run/plesk-php82-fpm.sock http://localhost/fpm-status?full

Cosa guardare nella status page:

active processes: Quanti processi stanno gestendo richieste in questo momento. Se questo numero è costantemente vicino a max_children, hai bisogno di più processi.
idle processes: Processi in standby pronti a gestire nuove richieste. Se è sempre 0, il server è saturo.
listen queue: Richieste in attesa di un processo libero. Se questo numero è maggiore di 0 frequentemente, devi aumentare pm.max_children. È il segnale di allarme più importante.
max listen queue: Il valore massimo raggiunto dalla coda. Se è alto, indica che ci sono stati picchi di traffico non gestiti.
max children reached: Il numero di volte in cui il limite pm.max_children è stato raggiunto. Se questo numero cresce, devi assolutamente aumentare max_children (o ottimizzare le performance del codice PHP per ridurre il tempo di esecuzione di ogni richiesta).

Comandi utili per il monitoraggio dalla CLI:

Verificare quanti processi PHP-FPM sono attivi e quanta memoria consumano:
ps aux –sort=-rss | grep php-fpm | head -20
Calcolare la memoria media per processo PHP-FPM:
ps –no-headers -o rss -C php-fpm | awk ‘{ total += $1; count++ } END { print total/count/1024 ” MB per processo, ” count ” processi totali” }’
Monitorare in tempo reale i processi PHP-FPM:
watch -n 1 “ps aux | grep php-fpm | grep -v grep | wc -l”
Controllare i log di PHP-FPM per errori:
tail -f /var/log/plesk-php82-fpm/error.log
Verificare lo stato del servizio PHP-FPM:
systemctl status plesk-php82-fpm

Ti consiglio di controllare questi parametri almeno una volta a settimana, e ogni volta che fai modifiche alla configurazione. Se gestisci server in produzione con traffico significativo, valuta di configurare un sistema di monitoraggio automatico come Zabbix, Munin o Netdata che può raccogliere queste metriche in modo continuo e avvisarti quando qualcosa va fuori norma.

5. Verificare il Hit Rate di OPcache e Diagnosticare Problemi

Una volta configurato OPcache, devi verificare che stia effettivamente funzionando e che la cache sia dimensionata correttamente. Il parametro chiave da monitorare è l’hit rate: la percentuale di richieste servite dalla cache bytecode anziché richiedere la ricompilazione del file PHP. Un hit rate sano deve essere superiore al 99%. Se è inferiore al 95%, c’è un problema di configurazione.

Metodo 1 — Dalla riga di comando:

Crea un file PHP temporaneo (ricorda di eliminarlo dopo!) in una directory accessibile dal web:
echo ‘<?php phpinfo(); ?>’ > /var/www/vhosts/tuodominio.it/httpdocs/opcache-test.php
Accedi al file dal browser. Cerca la sezione “Zend OPcache”. Verifica che sia abilitato e controlla i valori di “Cached scripts”, “Cached keys”, “Memory used” e “Hit rate”.
Elimina il file immediatamente dopo il test: lasciare un phpinfo() accessibile pubblicamente è un rischio di sicurezza grave.

Metodo 2 — Script di diagnostica più completo:

Crea un file PHP temporaneo con il seguente contenuto per avere un report dettagliato:

<?php
$status = opcache_get_status();
$config = opcache_get_configuration();
$hitRate = $status['opcache_statistics']['hits'] /
    ($status['opcache_statistics']['hits'] + $status['opcache_statistics']['misses']) * 100;

echo "OPcache Hit Rate: " . round($hitRate, 2) . "%n";
echo "Memoria usata: " . round($status['memory_usage']['used_memory']/1024/1024, 2) . " MBn";
echo "Memoria libera: " . round($status['memory_usage']['free_memory']/1024/1024, 2) . " MBn";
echo "Script in cache: " . $status['opcache_statistics']['num_cached_scripts'] . "n";
echo "Max script supportati: " . $config['directives']['opcache.max_accelerated_files'] . "n";
echo "Restarts (OOM): " . $status['opcache_statistics']['oom_restarts'] . "n";
echo "Restarts (hash): " . $status['opcache_statistics']['hash_restarts'] . "n";
?>

Metodo 3 — Interfaccia grafica con opcache-gui:

Esiste un tool open source chiamato opcache-gui (disponibile su GitHub) che offre un’interfaccia web completa per visualizzare lo stato di OPcache con grafici e metriche dettagliate. Scaricalo, mettilo in una directory protetta da password tramite .htaccess e usalo per monitorare OPcache. Il link diretto del progetto su GitHub si trova cercando “amnuts opcache-gui”.

Problemi comuni e soluzioni:

Hit rate basso (sotto 95%): Di solito indica che opcache.max_accelerated_files è troppo basso e i file vengono espulsi dalla cache per fare spazio. Aumenta il valore a 50000 o 100000.
Memoria OPcache esaurita (oom_restarts > 0): Significa che la memoria assegnata a OPcache è insufficiente. Aumenta opcache.memory_consumption a 256 o 512 MB.
OPcache si resetta frequentemente: Controlla se qualche plugin WordPress o cron job sta chiamando opcache_reset(). Alcuni plugin di caching (come WP Super Cache in certe configurazioni) lo fanno inutilmente. Verifica nei log e disattiva il plugin problematico.
Modifiche al codice non visibili: Se aggiorni un file PHP e le modifiche non appaiono subito, è perché OPcache sta servendo la versione in cache. Attendi il tempo impostato in revalidate_freq oppure svuota la cache manualmente con: php -r “opcache_reset();” dalla CLI, oppure riavviando PHP-FPM con systemctl reload plesk-php82-fpm.

6. Benchmark Prima e Dopo: I Risultati Reali

Le ottimizzazioni che ho descritto non sono teoriche: producono miglioramenti misurabili e significativi. Ti mostro i benchmark che eseguo sui server dei miei clienti prima e dopo l’ottimizzazione, usando strumenti professionali. Questi sono risultati tipici che riscontro nella pratica quotidiana.

Strumenti di benchmark che utilizzo:

GTmetrix (gtmetrix.com): Per misurare i tempi di caricamento delle pagine web dal punto di vista dell’utente, inclusi TTFB (Time To First Byte), LCP (Largest Contentful Paint) e Speed Index.
Apache Bench (ab): Per testare le prestazioni del server sotto carico, simulando richieste concorrenti. Il comando tipico che uso è:
ab -n 1000 -c 50 https://tuodominio.it/
(1000 richieste totali, 50 concorrenti).
curl con timing: Per misurare il TTFB con precisione:
curl -o /dev/null -s -w “TTFB: %{time_starttransfer}snTotal: %{time_total}sn” https://tuodominio.it/
siege: Alternativa ad Apache Bench per test di carico più realistici:
siege -c 25 -t 30S https://tuodominio.it/
(25 utenti concorrenti per 30 secondi).

Risultati tipici — Sito WordPress medio (tema standard, 10 plugin, WooCommerce):

Prima dell’ottimizzazione (configurazione Plesk default):

TTFB: 800-1200 ms
Tempo di caricamento pagina completo: 3.5-5.0 secondi
Apache Bench (50 concorrenti): 15-25 richieste/secondo, diversi errori 502/503
GTmetrix Performance Score: 65-75%

Dopo l’ottimizzazione PHP-FPM + OPcache:

TTFB: 150-350 ms
Tempo di caricamento pagina completo: 1.2-2.0 secondi
Apache Bench (50 concorrenti): 80-150 richieste/secondo, zero errori
GTmetrix Performance Score: 88-95%

Stiamo parlando di un miglioramento del 60-75% sul TTFB e di un aumento di 4-6 volte nelle richieste gestite al secondo. E questo è solo con l’ottimizzazione PHP-FPM e OPcache, senza toccare altri aspetti come il caching a livello applicativo (Redis, Memcached), il caching delle pagine (WP Super Cache, WP Rocket) o l’ottimizzazione del database. Combinando tutte queste ottimizzazioni, i risultati sono ancora più impressionanti.

Errori comuni che vedo frequentemente:

pm.max_children troppo basso: È l’errore numero uno. Con il valore di default di Plesk (spesso 5-10), bastano poche richieste concorrenti per saturare il pool. Sotto traffico reale, le richieste vanno in coda e il sito diventa lentissimo o restituisce errori 502/504.
OPcache disabilitato o con memoria troppo bassa: Alcuni provider di hosting disabilitano OPcache o lo configurano con 32-64 MB, insufficienti per siti WordPress complessi. Il risultato è che PHP deve ricompilare il bytecode ad ogni richiesta, uno spreco enorme.
PHP versione troppo vecchia: Ogni nuova versione di PHP porta miglioramenti di prestazioni significativi. PHP 8.3 è circa il 20-30% più veloce di PHP 7.4 in scenari reali. Se stai ancora su PHP 7.x, aggiornare è l’ottimizzazione più grande che puoi fare, e il passaggio si gestisce facilmente da Plesk.
Non riavviare PHP-FPM dopo le modifiche: Le modifiche alla configurazione di PHP-FPM e OPcache richiedono un riavvio del servizio per essere applicate. Usa systemctl restart plesk-php82-fpm dopo ogni modifica. Un semplice reload è sufficiente per la maggior parte dei cambiamenti di configurazione ed è meno invasivo.
Ignorare i log: I log di PHP-FPM (/var/log/plesk-php82-fpm/error.log) contengono informazioni preziose: avvisi di “server reached pm.max_children”, errori di memoria, warning di script lenti. Controllali regolarmente.

Domande Frequenti

L’ottimizzazione PHP-FPM e OPcache funziona anche con Nginx standalone senza Apache?

Sì, assolutamente. PHP-FPM funziona in modo identico sia con Apache + mod_proxy_fcgi, sia con Nginx come reverse proxy di Apache (la configurazione predefinita di Plesk), sia con Nginx standalone. Anzi, la configurazione Nginx standalone + PHP-FPM è la più efficiente perché elimina il passaggio tramite Apache, riducendo l’overhead e il consumo di memoria. Su Plesk puoi scegliere il web server in Strumenti e Impostazioni → Impostazioni del server web. Se i tuoi siti non hanno bisogno di .htaccess, passare a Nginx standalone può darti un ulteriore boost prestazionale del 10-20%.

Devo configurare OPcache diversamente per WooCommerce rispetto a WordPress standard?

WooCommerce ha bisogno di più risorse rispetto a un WordPress semplice. Un sito WooCommerce con molti prodotti ha migliaia di file PHP aggiuntivi (i template dei prodotti, le classi del carrello, i gateway di pagamento, ecc.) e ogni pagina prodotto genera richieste PHP più pesanti. Per WooCommerce consiglio di aumentare opcache.max_accelerated_files almeno a 50000 e opcache.memory_consumption ad almeno 256 MB. Inoltre, pm.max_children dovrebbe essere più alto perché le pagine WooCommerce hanno tempi di esecuzione più lunghi (specialmente checkout e carrello), il che significa che ogni processo resta occupato più a lungo.

Come faccio a svuotare la cache OPcache senza riavviare PHP-FPM?

Ci sono diversi metodi. Il più semplice è creare un piccolo script PHP:
<?php opcache_reset(); echo “OPcache svuotata”; ?>
Chiamalo dal browser, poi eliminalo immediatamente. In alternativa, dalla CLI puoi usare:
php -r “opcache_reset();”
Attenzione: la CLI e PHP-FPM hanno istanze OPcache separate. Lo script dalla CLI svuota solo la cache della CLI. Per svuotare la cache di PHP-FPM, devi usare lo script via browser o fare un reload del servizio: systemctl reload plesk-php82-fpm. Molti plugin WordPress (come WP OPcache o LiteSpeed Cache) offrono un bottone “Purge OPcache” direttamente dalla dashboard di WordPress.

Quanta RAM del server viene consumata da OPcache?

OPcache utilizza memoria condivisa (shared memory), il che significa che la memoria viene allocata una sola volta e condivisa tra tutti i processi PHP-FPM. Se imposti opcache.memory_consumption=256, quei 256 MB vengono allocati una volta sola, indipendentemente dal numero di processi PHP-FPM attivi. Non è come la RAM dei processi PHP-FPM che viene moltiplicata per ogni processo. Questo rende OPcache estremamente efficiente: 256 MB di shared memory possono servire centinaia di processi. L’investimento di memoria è minimo rispetto al ritorno in prestazioni.

Posso usare queste ottimizzazioni anche su un hosting condiviso Plesk?

Dipende dal livello di accesso che il provider ti concede. Sugli hosting condivisi, tipicamente non hai accesso alla configurazione globale di PHP-FPM (pm.max_children e simili) perché questa è gestita dal provider. Tuttavia, molti provider consentono di modificare le direttive PHP per dominio, incluse quelle di OPcache, tramite il pannello Plesk del tuo dominio o tramite un file .user.ini nella root del sito. Puoi sicuramente configurare opcache.revalidate_freq, opcache.validate_timestamps e altre direttive a livello applicativo. Per le ottimizzazioni PHP-FPM a livello server, hai bisogno almeno di un VPS con accesso root.

La Mia Soluzione Definitiva

L’ottimizzazione di PHP-FPM e OPcache su Plesk è una delle attività con il miglior rapporto sforzo/risultato che puoi fare su un server web. Con 15-30 minuti di lavoro ben fatto, puoi trasformare un server lento e instabile in una macchina che serve i siti in modo rapido e affidabile. La chiave è trattare questa ottimizzazione come un processo strutturato: analisi iniziale delle risorse disponibili e del carico di lavoro, configurazione mirata di PHP-FPM in base alla RAM e al traffico, ottimizzazione di OPcache con valori adeguati al numero di file PHP e al tipo di siti, e infine monitoraggio continuo per verificare che tutto funzioni e adattarsi ai cambiamenti nel tempo.

Se gestisci server Plesk con siti WordPress o applicazioni PHP e vuoi ottenere il massimo dalle tue risorse hardware, o se hai bisogno di aiuto per diagnosticare problemi di prestazioni, contattami. Posso analizzare la configurazione del tuo server, identificare i colli di bottiglia specifici e applicare le ottimizzazioni personalizzate per il tuo caso. In oltre vent’anni di amministrazione di sistemi ho ottimizzato server di ogni dimensione — dal piccolo VPS con 2 GB di RAM al server dedicato con 128 GB — e in ogni caso il risultato è stato un miglioramento tangibile e misurabile delle prestazioni.

Contattami per ottimizzare le prestazioni PHP del tuo server Plesk