Em resumo: O PHP JIT (compilador just-in-time) traduz para código máquina, durante a execução, o código PHP executado com frequência. Surgiu com o PHP 8.0, faz parte do OPcache e, desde o PHP 8.4, está desativado por predefinição. As tarefas de cálculo intensivo ficam assim claramente mais rápidas, os sites típicos como o WordPress quase nada. O maior ganho vem do OPcache, de uma versão atual do PHP e de uma gestão de processos bem ajustada, e cada versão atual traz ao mesmo tempo as correções de segurança necessárias.
O que é o compilador JIT no PHP?
O PHP é uma linguagem interpretada: o código-fonte é primeiro traduzido para bytecode, os chamados opcodes, e a Zend Engine executa-os. Um JIT vai um passo mais longe. Observa que secções de código correm com frequência e traduz precisamente essas para código máquina do processador. A partir daí, correm sem o desvio pelo interpretador.
O RFC da introdução descreve o JIT como uma parte quase autónoma do OPcache. O código máquina gerado fica numa área adicional da memória partilhada do OPcache. Com o PHP 8.4, o projeto reconstruiu o JIT; segundo a página de lançamento, a nova implementação baseia-se na framework IR, uma representação intermédia comum para a geração de código. Como funciona o motor por baixo explica-o a Zend Engine.
Primeiro o OPcache: a verdadeira base de desempenho
Sem OPcache, o PHP traduz cada ficheiro de novo em cada pedido. O OPcache guarda o bytecode na memória partilhada, para que todos os workers o reutilizem. Para um site com sistema de gestão de conteúdos, é de longe a alavanca mais importante. Desde o PHP 8.5, o OPcache está, segundo o RFC aprovado, compilado de forma fixa no PHP; as conhecidas definições ini continuam a controlar se a cache está ativa.
Valores predefinidos importantes, segundo o manual: opcache.enable=1, opcache.enable_cli=0, opcache.validate_timestamps=1 e opcache.revalidate_freq=2. Com a última definição, o OPcache verifica no máximo de dois em dois segundos se os ficheiros mudaram. Quem desativa o validate_timestamps tem de esvaziar a cache ou reiniciar o PHP após cada deployment. Mais sobre isto em OPcache explicado.
Configurar o PHP JIT: modos e definições
O JIT é controlado por duas diretivas:
| Diretiva | Predefinição desde o 8.4 | Predefinição antes do 8.4 | Significado |
|---|---|---|---|
opcache.jit |
disable |
tracing |
Modo do JIT |
opcache.jit_buffer_size |
64M |
0 |
Memória para o código máquina gerado, 0 desativa o JIT |
Para opcache.jit, o manual conhece estes valores: disable (totalmente desligado, não ativável em tempo de execução), off (desligado, mas ativável em tempo de execução), tracing ou on (recomendado para a maioria dos utilizadores) e function. Existe ainda uma notação numérica de quatro dígitos para ajustes finos.
; ativar o JIT de forma dirigida, p. ex. para workers de cálculo intensivo
opcache.enable=1
opcache.jit=tracing
opcache.jit_buffer_size=64M
Se o JIT está a correr, mostra-o o estado do OPcache:
php -i | grep -i "opcache.jit" # definições da CLI
php --ri "Zend OPcache" # configuração da extensão OPcache
Tenha em conta que a linha de comandos pode usar definições diferentes das do PHP-FPM. Para a operação web conta a saída do phpinfo() no contexto do FPM, idealmente consultada apenas internamente e removida depois.
O que traz o JIT na prática?
Os autores do RFC fizeram medições: o script sintético bench.php correu com JIT mais de duas vezes mais depressa. Nas aplicações reais, o ganho foi pequeno; o WordPress passou para 326 em vez de 315 pedidos por segundo, e o analisador do PHP correu cerca de 1,3 vezes mais depressa. O RFC diz abertamente que o JIT não acelera de forma significativa aplicações reais como o WordPress.
A razão está no perfil das aplicações web típicas. Passam a maior parte do tempo à espera da base de dados, do sistema de ficheiros ou de serviços externos. Um caminho de processador mais rápido ajuda pouco aí. Podem, em contrapartida, beneficiar o processamento de imagens em PHP, cálculos matemáticos, analisadores ou workers de longa duração.
Desempenho sem JIT: as alavancas mais eficazes
Para sites empresariais e lojas, compensa esta ordem:
- Versão atual do PHP: as versões novas trazem otimizações e, sobretudo, correções de segurança.
- Dimensionar bem o OPcache: memória suficiente e espaço para todos os ficheiros da aplicação.
- Ajustar bem o PHP-FPM: adaptar o
pm.max_childrenà memória disponível, em vez de o aumentar às cegas. - Verificar a base de dados: encontrar consultas lentas, criar índices.
- Cache ao nível da aplicação: cache de páginas ou de objetos, onde o sistema o suporte.
- Medir em vez de adivinhar: o
request_slowlog_timeoutno PHP-FPM escreve um backtrace no slowlog para os pedidos lentos.
JIT, desempenho e segurança
O desempenho e a segurança estão mais ligados do que parece. Primeiro: cada componente adicional é código adicional. O próprio RFC da introdução refere o risco de erros no JIT, na geração de código e na atribuição de registos, bem como a maior dificuldade na deteção de falhas. Quem não precisa do JIT de forma mensurável, deixa-o na predefinição disable.
Segundo: o OPcache e os workers mantêm código na memória. Após uma atualização de segurança como a do PHP2Shell, os processos antigos continuam a correr com código antigo até serem reiniciados. Esvaziar a cache, por si só, não substitui este reinício, pois as vulnerabilidades CVE-2026-109618 e CVE-2026-109619 estão no próprio binário do PHP.
Terceiro: o melhor ganho de desempenho, uma versão atual, é ao mesmo tempo a medida de proteção mais importante. O PHP 8.2 atinge o fim do suporte a 31/12/2026; quem mudar agora para o 8.4 ou 8.5 ganha ambos. Como mantemos os sistemas rápidos e protegidos a longo prazo descreve-o o hardening de servidores web PHP.
Como ajuda concretamente a PHP SOS?
- Análise do estado atual: lemos as definições de OPcache, JIT e FPM e comparamo-las com a carga e a memória.
- Medir os estrangulamentos: com o slowlog e os indicadores do servidor, encontramos onde o tempo realmente se perde.
- Configurar em segurança: JIT só onde ajuda comprovadamente; OPcache de modo a que deployments e atualizações funcionem sem problemas.
- Planear as atualizações: mudanças de versão com teste e reinício documentado, para que a velocidade e o nível de patches estejam corretos.
Perguntas frequentes
O JIT está ativo por predefinição no PHP?
Desde o PHP 8.4, já não: o valor predefinido de opcache.jit é disable. Antes, a predefinição era tracing, mas o buffer opcache.jit_buffer_size estava a 0, pelo que o JIT também não corria.
O JIT torna o WordPress mais rápido?
Quase nada. Já no RFC da introdução, os autores escrevem que o JIT não acelera de forma significativa aplicações reais como o WordPress. O valor medido passou de 315 para 326 pedidos por segundo.
Preciso do OPcache se não usar o JIT?
Sim. O OPcache guarda o bytecode traduzido na memória partilhada e poupa a recompilação a cada pedido. É a alavanca de desempenho mais importante para quase qualquer site PHP. Desde o PHP 8.5, o OPcache está integrado de forma fixa no PHP.
O JIT é um risco de segurança?
Mais código significa mais erros possíveis. O próprio RFC da introdução refere o risco de erros no JIT e a maior dificuldade na deteção de falhas. Quem não precisa dele, deixa-o desligado; quem o usa deve aplicar as atualizações com especial rapidez.