{"id":741,"date":"2026-02-20T09:00:00","date_gmt":"2026-02-20T08:00:00","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/ottimizzare-php-fpm-opcache-plesk\/"},"modified":"2026-02-18T18:04:18","modified_gmt":"2026-02-18T17:04:18","slug":"ottimizzare-php-fpm-opcache-plesk","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/ottimizzare-php-fpm-opcache-plesk\/","title":{"rendered":"Come Ottimizzo PHP-FPM e OPcache su Plesk per Velocizzare i Siti"},"content":{"rendered":"

Se gestisci siti WordPress o applicazioni PHP su un server con Plesk<\/strong>, c’\u00e8 una probabilit\u00e0 molto alta che tu stia lasciando sul tavolo una quantit\u00e0 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<\/strong> e OPcache<\/strong> \u00e8 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.<\/p>\n

In questa guida ti mostro esattamente come ottimizzo PHP-FPM e OPcache su Plesk<\/strong>, 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<\/strong>, 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\u00f2 anche i benchmark prima e dopo, misurati con strumenti professionali come GTmetrix, Apache Bench e curl<\/strong>. Preparati a vedere i tuoi siti volare.<\/p>\n

1. PHP-FPM vs mod_php: Perch\u00e9 PHP-FPM \u00e8 Fondamentale<\/h2>\n

Prima di entrare nella configurazione, \u00e8 importante capire cosa sia PHP-FPM<\/strong> e perch\u00e9 \u00e8 superiore all’alternativa tradizionale. Questa comprensione ti aiuter\u00e0 a capire il senso di ogni parametro che andremo a configurare.<\/p>\n

mod_php<\/strong> \u00e8 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<\/strong>, anche quando PHP non serve affatto. Su un server con molte connessioni contemporanee, questo spreco di memoria diventa enorme.<\/p>\n

PHP-FPM<\/strong> (FastCGI Process Manager) \u00e8 un’architettura completamente diversa: PHP gira come un servizio separato e indipendente<\/strong> 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<\/strong> pronti a gestire le richieste PHP, riducendo drasticamente il tempo di inizializzazione. I vantaggi sono molteplici:<\/p>\n

    \n
  • Migliore gestione della memoria:<\/strong> Solo i processi PHP-FPM consumano la memoria necessaria per PHP. Il web server resta leggero per servire i file statici.<\/li>\n
  • Isolamento tra siti:<\/strong> Su Plesk, ogni dominio pu\u00f2 avere il proprio pool PHP-FPM con le proprie risorse dedicate. Un sito sovraccarico non influenza gli altri.<\/li>\n
  • Gestione avanzata dei processi:<\/strong> PHP-FPM offre modalit\u00e0 di gestione dei processi (static, dynamic, ondemand) che permettono di ottimizzare l’uso delle risorse in base al traffico effettivo.<\/li>\n
  • Compatibilit\u00e0 con Nginx:<\/strong> 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 \u00e8 essenziale per ottenere il massimo delle prestazioni.<\/li>\n
  • Status page:<\/strong> 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.<\/li>\n<\/ul>\n

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

    2. Configurare il Pool PHP-FPM su Plesk: I Parametri Chiave<\/h2>\n

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

    I parametri fondamentali sono quattro, e sono tutti legati tra loro:<\/p>\n

      \n
    1. pm (Process Manager):<\/strong> La modalit\u00e0 di gestione dei processi. Le opzioni sono:\n
        \n
      • static:<\/strong> Mantiene sempre un numero fisso di processi. Usa pi\u00f9 memoria ma offre le migliori prestazioni perch\u00e9 non c’\u00e8 overhead di creazione\/distruzione dei processi. Consigliato per server dedicati con traffico costante.<\/strong><\/li>\n
      • dynamic:<\/strong> Adatta il numero di processi in base al traffico. \u00c8 la scelta pi\u00f9 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.<\/li>\n
      • ondemand:<\/strong> Crea i processi solo quando arriva una richiesta e li distrugge dopo un timeout di inattivit\u00e0. Usa meno memoria ma ha un leggero ritardo sulla prima richiesta. Consigliato per VPS con poca RAM o siti a basso traffico.<\/strong><\/li>\n<\/ul>\n<\/li>\n
      • pm.max_children:<\/strong> Il numero massimo di processi PHP che possono essere attivi contemporaneamente. Questo \u00e8 il parametro pi\u00f9 critico. Se il valore \u00e8 troppo basso, le richieste vengono messe in coda e il sito rallenta. Se \u00e8 troppo alto, il server esaurisce la RAM e inizia a usare lo swap, peggiorando le prestazioni di tutto.<\/li>\n
      • pm.start_servers:<\/strong> 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.<\/li>\n
      • pm.min_spare_servers:<\/strong> Il numero minimo di processi inattivi (in standby) sempre pronti. Se scende sotto questo valore, PHP-FPM ne crea di nuovi.<\/li>\n
      • pm.max_spare_servers:<\/strong> Il numero massimo di processi inattivi. Se ce ne sono troppi in standby, PHP-FPM ne termina alcuni per risparmiare memoria.<\/li>\n<\/ol>\n

        Come calcolare pm.max_children in base alla RAM:<\/strong><\/p>\n

        Questa \u00e8 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<\/strong> (puoi verificare il valore esatto sul tuo server con il comando ps aux –sort=-rss | grep php-fpm | head -20<\/strong> e guardando la colonna RSS).<\/p>\n

        La formula \u00e8: pm.max_children = (RAM disponibile per PHP) \/ (Memoria media per processo)<\/strong><\/p>\n

        Dove “RAM disponibile per PHP” \u00e8 la RAM totale del server meno quella usata dal sistema operativo, dal web server, dal database e da altri servizi. In pratica:<\/p>\n

          \n
        • Server con 2 GB di RAM:<\/strong> circa 1 GB disponibile per PHP \u2192 pm.max_children = 20-25<\/strong><\/li>\n
        • Server con 4 GB di RAM:<\/strong> circa 2,5 GB disponibili per PHP \u2192 pm.max_children = 50-60<\/strong><\/li>\n
        • Server con 8 GB di RAM:<\/strong> circa 5-6 GB disponibili per PHP \u2192 pm.max_children = 100-150<\/strong><\/li>\n
        • Server con 16 GB di RAM:<\/strong> circa 10-12 GB disponibili per PHP \u2192 pm.max_children = 200-300<\/strong><\/li>\n<\/ul>\n

          Come configurare questi valori su Plesk:<\/strong><\/p>\n

            \n
          1. Accedi a Plesk \u2192 Strumenti e Impostazioni \u2192 Impostazioni PHP<\/strong> per la configurazione a livello server (globale).<\/li>\n
          2. Oppure vai in Plesk \u2192 Dominio specifico \u2192 Impostazioni PHP \u2192 Impostazioni PHP-FPM<\/strong> per la configurazione per singolo dominio.<\/li>\n
          3. Nella sezione “Parametri aggiuntivi di PHP-FPM”<\/strong>, inserisci i valori. Per un server da 4 GB con configurazione dynamic, la mia configurazione tipica \u00e8:<\/li>\n<\/ol>\n

            Esempio per server 4 GB RAM, WordPress con traffico medio:<\/strong><\/p>\n

            \npm = dynamic\npm.max_children = 50\npm.start_servers = 10\npm.min_spare_servers = 5\npm.max_spare_servers = 20\npm.max_requests = 500\npm.process_idle_timeout = 10s\n<\/pre>\n
            Esempio per VPS 2 GB RAM, pochi siti a basso traffico:<\/strong><\/p>\n
            \npm = ondemand\npm.max_children = 20\npm.process_idle_timeout = 10s\npm.max_requests = 500\n<\/pre>\n
            Esempio per server dedicato 16 GB RAM, siti ad alto traffico:<\/strong><\/p>\n
            \npm = dynamic\npm.max_children = 250\npm.start_servers = 30\npm.min_spare_servers = 15\npm.max_spare_servers = 50\npm.max_requests = 1000\n<\/pre>\n
            Il parametro pm.max_requests<\/strong> \u00e8 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 \u00e8 il mio standard. Non mettere 0 (infinito) a meno che tu non sia certo che non ci siano leak \u2014 con WordPress e i suoi plugin, i leak sono sempre dietro l’angolo.<\/p>\n
            3. Abilitare e Ottimizzare OPcache: Il Turbo per PHP<\/h2>\n
            OPcache<\/strong> \u00e8 forse l’ottimizzazione singola pi\u00f9 impattante che puoi fare su un server PHP. Per capire perch\u00e9, 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<\/strong>. OPcache elimina i primi due passaggi memorizzando il bytecode compilato nella memoria condivisa (shared memory)<\/strong>, cos\u00ec che alle richieste successive PHP trovi il bytecode gi\u00e0 pronto per l’esecuzione. Il risultato \u00e8 una riduzione del tempo di esecuzione di PHP del 50-70%<\/strong> in scenari reali.<\/p>\n
            Su Plesk, OPcache \u00e8 generalmente abilitato di default, ma con valori troppo bassi. Ecco i parametri fondamentali e i valori che uso io:<\/p>\n
              \n
            1. opcache.enable = 1<\/strong> \u2014 Abilita OPcache. Dovrebbe essere gi\u00e0 attivo, ma verifica.<\/li>\n
            2. opcache.memory_consumption = 256<\/strong> \u2014 La quantit\u00e0 di memoria (in MB) dedicata alla cache del bytecode. Il valore predefinito \u00e8 spesso 64 o 128 MB, che \u00e8 insufficiente per server con molti siti o siti WordPress con molti plugin. Per un server con 5-10 siti WordPress, 256 MB \u00e8 il minimo consigliato. Per server con 20+ siti, considera 512 MB.<\/li>\n
            3. opcache.max_accelerated_files = 30000<\/strong> \u2014 Il numero massimo di file PHP che possono essere memorizzati nella cache. Il valore predefinito (2000-4000) \u00e8 ridicolmente basso: un singolo sito WordPress con WooCommerce e una decina di plugin pu\u00f2 avere oltre 10.000 file PHP. Il valore massimo \u00e8 1000000, ma 30000 \u00e8 un buon compromesso per la maggior parte dei server. Per server con molti siti, usa 50000 o 100000<\/strong>.<\/li>\n
            4. opcache.revalidate_freq = 60<\/strong> \u2014 Ogni quanti secondi PHP controlla se i file sorgente sono cambiati. Il valore predefinito \u00e8 2 secondi, che \u00e8 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<\/strong>. Se stai sviluppando attivamente, metti 0 per controllare ad ogni richiesta.<\/li>\n
            5. opcache.validate_timestamps = 1<\/strong> \u2014 Se impostato a 0, PHP non controller\u00e0 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<\/strong> in ambienti Plesk dove gli utenti aggiornano WordPress e i plugin tramite la dashboard.<\/li>\n
            6. opcache.interned_strings_buffer = 16<\/strong> \u2014 Memoria dedicata alle stringhe internate (stringhe ripetute nel codice PHP). Il valore predefinito (4 o 8 MB) \u00e8 spesso insufficiente. 16 MB \u00e8 il mio standard.<\/li>\n
            7. opcache.save_comments = 1<\/strong> \u2014 Necessario per molti framework PHP (incluso WordPress con alcuni plugin) che usano le annotations nei commenti. Mantienilo attivo.<\/li>\n
            8. opcache.fast_shutdown = 1<\/strong> \u2014 Abilita una sequenza di shutdown pi\u00f9 veloce dei processi. Non ha controindicazioni, attivalo sempre. (Nota: deprecato in PHP 8.x dove \u00e8 sempre attivo.)<\/li>\n<\/ol>\n
              Come configurare OPcache su Plesk:<\/strong><\/p>\n
                \n
              1. Vai in Plesk \u2192 Strumenti e Impostazioni \u2192 Impostazioni PHP<\/strong> (per la configurazione globale del server).<\/li>\n
              2. Seleziona la versione PHP che stai utilizzando (consiglio PHP 8.2 o 8.3<\/strong> nel 2026).<\/li>\n
              3. Cerca la sezione “Impostazioni di OPcache”<\/strong> o modifica direttamente i valori in “Direttive PHP aggiuntive”<\/strong>.<\/li>\n
              4. Inserisci i seguenti valori nella casella delle direttive aggiuntive:<\/li>\n<\/ol>\n
                \nopcache.enable=1\nopcache.memory_consumption=256\nopcache.max_accelerated_files=30000\nopcache.revalidate_freq=60\nopcache.validate_timestamps=1\nopcache.interned_strings_buffer=16\nopcache.save_comments=1\n<\/pre>\n
                  \n
                1. Salva e riavvia PHP-FPM con il comando: systemctl restart plesk-php82-fpm<\/strong> (adatta il numero di versione alla tua installazione, ad esempio plesk-php83-fpm<\/strong> per PHP 8.3).<\/li>\n<\/ol>\n
                  Puoi anche configurare OPcache per singolo dominio<\/strong> andando in Plesk \u2192 Dominio \u2192 Impostazioni PHP \u2192 Direttive PHP aggiuntive. Questo \u00e8 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.<\/p>\n
                  4. Monitorare PHP-FPM: La Status Page e i Comandi Essenziali<\/h2>\n
                  Ottimizzare senza monitorare \u00e8 come guidare bendati. Dopo aver configurato PHP-FPM e OPcache, \u00e8 fondamentale verificare che la configurazione funzioni<\/strong> e che non ci siano colli di bottiglia. PHP-FPM offre una status page integrata che \u00e8 uno strumento diagnostico preziosissimo.<\/p>\n
                  Abilitare la status page di PHP-FPM su Plesk:<\/strong><\/p>\n
                    \n
                  1. Modifica il file di configurazione del pool PHP-FPM. Su Plesk, lo trovi in: \/opt\/plesk\/php\/8.2\/etc\/php-fpm.d\/<\/strong> (adatta il percorso alla tua versione PHP). I file dei pool per dominio sono generati automaticamente da Plesk.<\/li>\n
                  2. Aggiungi (o verifica che ci sia) la direttiva: pm.status_path = \/fpm-status<\/strong><\/li>\n
                  3. Per accedere alla status page dall’esterno, puoi configurare una location in Nginx. In alternativa, accedi via CLI direttamente sul server con il comando:
                    \n    SCRIPT_NAME=\/fpm-status SCRIPT_FILENAME=\/fpm-status REQUEST_METHOD=GET cgi-fcgi -bind -connect \/run\/plesk-php82-fpm.sock<\/strong><\/li>\n
                  4. Un metodo pi\u00f9 pratico \u00e8 usare curl puntando al socket Unix:
                    \n    curl –unix-socket \/run\/plesk-php82-fpm.sock http:\/\/localhost\/fpm-status?full<\/strong><\/li>\n<\/ol>\n
                    Cosa guardare nella status page:<\/strong><\/p>\n
                      \n
                    • active processes:<\/strong> Quanti processi stanno gestendo richieste in questo momento. Se questo numero \u00e8 costantemente vicino a max_children, hai bisogno di pi\u00f9 processi.<\/li>\n
                    • idle processes:<\/strong> Processi in standby pronti a gestire nuove richieste. Se \u00e8 sempre 0, il server \u00e8 saturo.<\/li>\n
                    • listen queue:<\/strong> Richieste in attesa di un processo libero. Se questo numero \u00e8 maggiore di 0 frequentemente, devi aumentare pm.max_children<\/strong>. \u00c8 il segnale di allarme pi\u00f9 importante.<\/li>\n
                    • max listen queue:<\/strong> Il valore massimo raggiunto dalla coda. Se \u00e8 alto, indica che ci sono stati picchi di traffico non gestiti.<\/li>\n
                    • max children reached:<\/strong> Il numero di volte in cui il limite pm.max_children \u00e8 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).<\/li>\n<\/ul>\n
                      Comandi utili per il monitoraggio dalla CLI:<\/strong><\/p>\n
                        \n
                      • Verificare quanti processi PHP-FPM sono attivi e quanta memoria consumano:
                        \n    ps aux –sort=-rss | grep php-fpm | head -20<\/strong><\/li>\n
                      • Calcolare la memoria media per processo PHP-FPM:
                        \n    ps –no-headers -o rss -C php-fpm | awk ‘{ total += $1; count++ } END { print total\/count\/1024 ” MB per processo, ” count ” processi totali” }’<\/strong><\/li>\n
                      • Monitorare in tempo reale i processi PHP-FPM:
                        \n    watch -n 1 “ps aux | grep php-fpm | grep -v grep | wc -l”<\/strong><\/li>\n
                      • Controllare i log di PHP-FPM per errori:
                        \n    tail -f \/var\/log\/plesk-php82-fpm\/error.log<\/strong><\/li>\n
                      • Verificare lo stato del servizio PHP-FPM:
                        \n    systemctl status plesk-php82-fpm<\/strong><\/li>\n<\/ul>\n
                        Ti consiglio di controllare questi parametri almeno una volta a settimana<\/strong>, 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<\/strong> che pu\u00f2 raccogliere queste metriche in modo continuo e avvisarti quando qualcosa va fuori norma.<\/p>\n
                        5. Verificare il Hit Rate di OPcache e Diagnosticare Problemi<\/h2>\n
                        Una volta configurato OPcache, devi verificare che stia effettivamente funzionando e che la cache sia dimensionata correttamente. Il parametro chiave da monitorare \u00e8 l’hit rate<\/strong>: la percentuale di richieste servite dalla cache bytecode anzich\u00e9 richiedere la ricompilazione del file PHP. Un hit rate sano deve essere superiore al 99%<\/strong>. Se \u00e8 inferiore al 95%, c’\u00e8 un problema di configurazione.<\/p>\n
                        Metodo 1 \u2014 Dalla riga di comando:<\/strong><\/p>\n
                          \n
                        1. Crea un file PHP temporaneo (ricorda di eliminarlo dopo!) in una directory accessibile dal web:
                          \n    echo ‘<?php phpinfo(); ?>’ > \/var\/www\/vhosts\/tuodominio.it\/httpdocs\/opcache-test.php<\/strong><\/li>\n
                        2. Accedi al file dal browser. Cerca la sezione “Zend OPcache”<\/strong>. Verifica che sia abilitato e controlla i valori di “Cached scripts”, “Cached keys”, “Memory used” e “Hit rate”.<\/li>\n
                        3. Elimina il file immediatamente dopo il test:<\/strong> lasciare un phpinfo() accessibile pubblicamente \u00e8 un rischio di sicurezza grave.<\/li>\n<\/ol>\n
                          Metodo 2 \u2014 Script di diagnostica pi\u00f9 completo:<\/strong><\/p>\n
                          Crea un file PHP temporaneo con il seguente contenuto per avere un report dettagliato:<\/p>\n
                          \n<?php\n$status = opcache_get_status();\n$config = opcache_get_configuration();\n$hitRate = $status['opcache_statistics']['hits'] \/\n    ($status['opcache_statistics']['hits'] + $status['opcache_statistics']['misses']) * 100;\n\necho \"OPcache Hit Rate: \" . round($hitRate, 2) . \"%n\";\necho \"Memoria usata: \" . round($status['memory_usage']['used_memory']\/1024\/1024, 2) . \" MBn\";\necho \"Memoria libera: \" . round($status['memory_usage']['free_memory']\/1024\/1024, 2) . \" MBn\";\necho \"Script in cache: \" . $status['opcache_statistics']['num_cached_scripts'] . \"n\";\necho \"Max script supportati: \" . $config['directives']['opcache.max_accelerated_files'] . \"n\";\necho \"Restarts (OOM): \" . $status['opcache_statistics']['oom_restarts'] . \"n\";\necho \"Restarts (hash): \" . $status['opcache_statistics']['hash_restarts'] . \"n\";\n?>\n<\/pre>\n
                          Metodo 3 \u2014 Interfaccia grafica con opcache-gui:<\/strong><\/p>\n
                          Esiste un tool open source chiamato opcache-gui<\/strong> (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”.<\/p>\n
                          Problemi comuni e soluzioni:<\/strong><\/p>\n
                            \n
                          • Hit rate basso (sotto 95%):<\/strong> Di solito indica che opcache.max_accelerated_files<\/strong> \u00e8 troppo basso e i file vengono espulsi dalla cache per fare spazio. Aumenta il valore a 50000 o 100000.<\/li>\n
                          • Memoria OPcache esaurita (oom_restarts > 0):<\/strong> Significa che la memoria assegnata a OPcache \u00e8 insufficiente. Aumenta opcache.memory_consumption<\/strong> a 256 o 512 MB.<\/li>\n
                          • OPcache si resetta frequentemente:<\/strong> Controlla se qualche plugin WordPress o cron job sta chiamando opcache_reset()<\/strong>. Alcuni plugin di caching (come WP Super Cache in certe configurazioni) lo fanno inutilmente. Verifica nei log e disattiva il plugin problematico.<\/li>\n
                          • Modifiche al codice non visibili:<\/strong> Se aggiorni un file PHP e le modifiche non appaiono subito, \u00e8 perch\u00e9 OPcache sta servendo la versione in cache. Attendi il tempo impostato in revalidate_freq oppure svuota la cache manualmente con: php -r “opcache_reset();”<\/strong> dalla CLI, oppure riavviando PHP-FPM con systemctl reload plesk-php82-fpm<\/strong>.<\/li>\n<\/ul>\n
                            6. Benchmark Prima e Dopo: I Risultati Reali<\/h2>\n
                            Le ottimizzazioni che ho descritto non sono teoriche: producono miglioramenti misurabili e significativi<\/strong>. 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.<\/p>\n
                            Strumenti di benchmark che utilizzo:<\/strong><\/p>\n