OPcache y JIT en producción de PHP 8.3 — lo que de verdad mueve la aguja

El OPcache de PHP 8.3 es uno de los cambios de configuración de mayor ROI en toda la stack. La config por defecto es dev-friendly (revalidación frecuente, memoria modesta). La config correcta para producción es un cambio pequeño que recorta rutinariamente el uso de CPU en un 30-40 % en cargas Laravel y WordPress. JIT es el hermano más turbio — a veces una victoria clara, a veces neutro, ocasionalmente una regresión.

Esto es lo que entregamos y por qué.

La config de producción

opcache.enable=1
opcache.memory_consumption=512
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
opcache.revalidate_freq=0
opcache.save_comments=1
opcache.fast_shutdown=1
opcache.jit_buffer_size=128M
opcache.jit=tracing

El flag de mayor impacto es validate_timestamps=0. Le dice a OPcache que nunca compruebe si un fichero ha cambiado — simplemente confía en lo que tiene en caché. Trade-off: los despliegues requieren un opcache_reset() explícito o un reload de PHP-FPM, que tu pipeline de despliegue debería estar haciendo de todas formas.

El artículo completo cubre:

• Por qué validate_timestamps=0 pertenece a cada config de producción
• Dimensionar memory_consumption y max_accelerated_files para tu codebase
• Modos JIT (function, tracing) — y las cargas donde cada uno ayuda
• Cuándo JIT de verdad hace daño (PHP-como-templating, cargas mayormente I/O)
• Leer la salida de opcache_get_status() para verificar que de verdad hace su trabajo
• Estrategias de cold-start para containers efímeros (preloading vs lazy)

Entregamos esta configuración en cada instalación PHP gestionada.