Error solucionado en producción: ticket cerrado. Los usuarios aún ven el error. ¿Caché CDN? Vacío. ¿Código de operación? opcache.validate_timestamps=0 desde una configuración de “rendimiento”: los archivos PHP se actualizan en el disco, pero el antiguo código de bytes permanece servido cuarenta minutos hasta el reinicio en pánico de PHP-FPM.
OPcache es una aceleración: mal administrada en producción, es un caché de código que ignora sus implementaciones. El problema no es “borrar el caché”; está sincronizando la versión en el disco y los trabajadores PHP sin causar una cascada 502.
Ciclo de implementación saludable
Una implementación PHP confiable sigue una secuencia documentada:
- Lanzamiento atómico:
/releases/20260719/más enlace simbólicoactual. - Instalación de redacción, migraciones, precalentamiento de caché de aplicaciones.
php articulado optimizaro caché de Symfony si corresponde.- Recarga PHP-FPM:
systemctl recarga php8.2-fpm(elegante). - Prueba de humo en el control sanitario.
- Retroceso = revertir enlace simbólico más recargar.
La "recarga" recicla a los trabajadores gradualmente: las solicitudes actuales finalizan; Los nuevos trabajadores cargan un OPcache nuevo. Un "reinicio" repentino provoca un apagado; "recargar" es la opción preferida para una implementación ininterrumpida.
reiniciar brutal versus recargar elegante: el primero interrumpe el servicio; el segundo conserva las conexiones actuales.
validar_timestamps: el compromiso para entender
| Configuración | Comportamiento | Uso |
|---|---|---|
validate_timestamps=1 | stat() en el archivo, se vuelve a compilar si mtime cambia | Desarrollo, preproducción |
validate_timestamps=0 | nunca vuelva a revisar el disco | Producción más recarga en cada despliegue |
Con revalidate_freq=0 y validate=1, cada solicitud verifica el disco: una carga de E/S innecesaria en producción. El par validate_timestamps=0 más la recarga de FPM programada es el estándar para los equipos que implementan varias veces por semana.
Estrategias de invalidación
A — Recarga de FPM (recomendado) Paso posterior a la implementación en el script: systemctl reload php-fpm. Sencillo, predecible, sin mayores interrupciones.
B — opcache_reset() en la línea de comando posterior a la implementación A través de SSH de una sola vez: aceptable si solo hay un grupo PHP-FPM. Nunca en una solicitud HTTP.
C: Implementación gradual en N servidores Equilibrador de carga en drenaje → implementación → recarga → reactivación. Cero tiempo de inactividad en un clúster.
D — opcache.file_cache Segundo nivel en disco: preste atención a la sincronización entre nodos durante la implementación.
Trampas y contenedores multiversión
- Azul-verde con dos versiones: trabajadores mixtos si se recarga parcialmente: complete la recarga en todos los nodos antes de cambiar el tráfico.
- Precarga de PHP 7.4+: un cambio de archivo de precarga requiere un reinicio completo, no una simple recarga.
- Docker: nueva imagen = nuevo contenedor, OPcache nuevo. Montaje de volumen para código = mismo problema de
validate_timestamps.
En hosting compartido, no hay recarga de FPM de autoservicio: implementación de FTP con validate_timestamps=1 impuesto o ticket de soporte. Razón de más para un VPS o PaaS si lo implementa con frecuencia.
La cumbre: OPcache sin procedimiento de implementación es una prueba A/B no intencionada
Esto es lo que la configuración de "rendimiento" olvida documentar.
Lista de verificación de implementación de PHP: enlace simbólico más recarga de FPM documentado, no “cargamos y esperamos”.
Decide y avanza sin puntos ciegos
Durante medio día, podrás proteger tus implementaciones PHP:
- Aprobar
validate_timestamps=0en producción con recarga de FPM programada. - Configurar una implementación atómica mediante un enlace simbólico.
- Hacer obligatoria una prueba de humo posterior a la recarga.
- No permitir
opcache_reset()en puntos finales web. - Planifique una implementación por fases si tiene varios servidores.
Documente la secuencia completa en su runbook de implementación: quién inicia la recarga, cómo verificar que todos los trabajadores se hayan reciclado y qué prueba confirma que el nuevo código se entrega correctamente. Referencia cruzada con PHP Profiling para medir el impacto de una implementación deficiente y implementación azul-verde para arquitecturas de múltiples instancias.
Preguntas frecuentes
¿Por qué se ejecuta el código antiguo después de la implementación?
OPcache mantiene el código de bytes compilado en la memoria. Con validate_timestamps=0, los archivos modificados en el disco no activan una recarga hasta que un trabajador se recicla mediante una recarga de FPM.
¿opcache_reset() es seguro en prod?
No en la solicitud web: es un reinicio global brutal. Prefiere una recarga elegante de PHP-FPM o un restablecimiento de la línea de comando posterior a la implementación, excluyendo el tráfico de usuarios.
validar_timestamps=1 en producción?
Posible en preproducción. En producción, esto agrega llamadas stat() a cada inclusión. El compromiso común sigue siendo validate_timestamps=0 más la recarga de FPM en cada implementación.
¿Ayuda el despliegue atómico?
Sí. El cambio de enlace simbólico más la recarga de FPM sincroniza a todos los trabajadores en el mismo árbol de archivos, sin mezclar versiones nuevas y antiguas.
Después de una implementación, si OPcache no ha sido invitado a la fiesta, usted mantiene dos versiones del sitio: una en git y otra en RAM.