Opcache: codice PHP vecchio può comparire quando il bytecode compilato non viene invalidato dopo una modifica.
Indice dei contenuti
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 dell’ambiente PHP in cui viene eseguita 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
Ambienti PHP distinti possono avere cache separate. Non presumere che ogni pool abbia una cache isolata: dipende da come sono avviati i processi PHP.
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
Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Verifica il contenuto dal server. Confronta hash e timestamp del file.
- Escludi page cache. Controlla una risposta dinamica o aggiungi un marcatore temporaneo sicuro.
- Leggi configurazione OPcache. Controlla validate_timestamps, revalidate_freq e file_cache.
- Confronta CLI e web. Possono usare processi e ini differenti.
- Identifica il pool PHP. Verifica versione e handler del dominio.
- Invalida un singolo file. Quando disponibile usa `opcache_invalidate` nel contesto corretto.
- Monitora il carico. Prima di un reset globale valuta il traffico.
Procedura di risoluzione
Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Usa il restart previsto da LiteSpeed. Il marker di riavvio ricarica i processi PHP in modo controllato.
- Invalida il file modificato. Riduce l’impatto rispetto al reset completo.
- Esegui opcache_reset nel contesto web corretto. Non assumere che la CLI resetti il pool web.
- Configura timestamp coerenti. Scegli valori adatti al metodo di deploy.
- Correggi il deploy atomico. Prevedi invalidazione o restart dopo il cambio release.
- Pulisci le altre cache. LiteSpeed e CDN possono servire HTML precedente.
- Rimuovi script di reset temporanei. Non lasciare endpoint pubblici che eseguono opcache_reset.
Domande frequenti
Perché OPcache può mostrare ancora codice PHP precedente?
La documentazione PHP precisa che non elimina la file cache. In pratica, `opcache_reset()` azzera la cache opcode in memoria dell’ambiente PHP in cui viene eseguita e gli script vengono ricompilati alle richieste successive.
Come verificare se OPcache sta servendo codice PHP non aggiornato?
Verifica il contenuto dal server. Confronta hash e timestamp del file.
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