OPcache mostra codice PHP vecchio: come intervenire

Opcache: codice PHP vecchio può comparire quando il bytecode compilato non viene invalidato dopo una modifica.

Opcache

Questa guida approfondisce OPcache codice PHP vecchio con controlli progressivi, modifiche reversibili e verifiche finali. Non inviare password, cookie, token, chiavi private o codici 2FA nei ticket.

Che cosa significa

`opcache_reset()` azzera la cache opcode in memoria del processo che esegue la funzione e gli script vengono ricompilati alle richieste successive. La documentazione PHP precisa che non elimina la file cache.

Un reset globale può causare una breve ricompilazione di molti script e aumentare il carico. Prima è preferibile invalidare il file interessato o usare il meccanismo di restart previsto dal server.

Come riconoscere il problema

• Il file sul disco è nuovo ma il sito mostra il comportamento precedente.
• Solo alcuni processi servono il vecchio codice.
• Il problema appare dopo deploy atomico.
• Riavviando PHP la modifica diventa visibile.
• La CLI vede il nuovo file ma il web no.

Cause più frequenti

1. Validate_timestamps disattivato

OPcache non controlla automaticamente le modifiche. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

2. Revalidate_freq elevato

Il controllo avviene dopo un intervallo.

3. Processi multipli

Pool differenti possiedono cache separate.

4. File cache

Il bytecode persistente può avere regole proprie.

5. Deploy con inode o symlink

Il processo mantiene riferimenti al vecchio percorso.

6. Altra cache

Page cache, CDN o browser possono sembrare OPcache.

Diagnosi passo per passo

1. Verifica il contenuto dal server. Confronta hash e timestamp del file. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
2. Escludi page cache. Controlla una risposta dinamica o aggiungi un marcatore temporaneo sicuro. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
3. Leggi configurazione OPcache. Controlla validate_timestamps, revalidate_freq e file_cache. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
4. Confronta CLI e web. Possono usare processi e ini differenti. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
5. Identifica il pool PHP. Verifica versione e handler del dominio. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
6. Invalida un singolo file. Quando disponibile usa `opcache_invalidate` nel contesto corretto. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
7. Monitora il carico. Prima di un reset globale valuta il traffico. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.

Procedura di risoluzione

1. Usa il restart previsto da LiteSpeed. Il marker di riavvio ricarica i processi PHP in modo controllato. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
2. Invalida il file modificato. Riduce l’impatto rispetto al reset completo. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
3. Esegui opcache_reset nel contesto web corretto. Non assumere che la CLI resetti il pool web. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
4. Configura timestamp coerenti. Scegli valori adatti al metodo di deploy. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
5. Correggi il deploy atomico. Prevedi invalidazione o restart dopo il cambio release. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
6. Pulisci le altre cache. LiteSpeed e CDN possono servire HTML precedente. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
7. Rimuovi script di reset temporanei. Non lasciare endpoint pubblici che eseguono opcache_reset. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.

Domande frequenti

Guide Xlogic correlate

• Redis Object Cache su WordPress: guida completa
• Cambiare versione PHP senza bloccare WordPress
• LSCache HIT o MISS: come verificare se la cache funziona

Fonti tecniche

• PHP opcache_reset
• PHP OPcache configuration