OPcache e JIT em produção PHP 8.3 — o que de fato mexe o ponteiro

O OPcache do PHP 8.3 é uma das mudanças de configuração de maior ROI em toda a stack. A config padrão é amigável para dev (revalidação frequente, memória modesta). A config correta para produção é uma mudança pequena que rotineiramente corta o uso de CPU em 30-40 % em cargas Laravel e WordPress. JIT é o irmão mais turvo — às vezes uma vitória clara, às vezes neutro, ocasionalmente uma regressão.

Isto é o que entregamos e por quê.

A config de produção

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

A flag de maior impacto é validate_timestamps=0. Diz ao OPcache para nunca checar se um arquivo mudou — ele simplesmente confia no que tem em cache. Trade-off: deploys exigem um opcache_reset() explícito ou reload do PHP-FPM, que seu pipeline de deploy deveria estar fazendo de qualquer forma.

O artigo completo cobre:

• Por que validate_timestamps=0 pertence a toda config de produção
• Dimensionar memory_consumption e max_accelerated_files para sua codebase
• Modos JIT (function, tracing) — e as cargas onde cada um ajuda
• Quando JIT realmente atrapalha (PHP-como-templating, cargas majoritariamente I/O)
• Ler a saída de opcache_get_status() para verificar se está fazendo seu trabalho
• Estratégias de cold-start para containers efêmeros (preloading vs lazy)

Entregamos esta configuração em cada instalação PHP gerenciada.