# JIT e desempenho no PHP 8

> PHP JIT e desempenho no PHP 8: como o compilador JIT trabalha com o OPcache, que definições se aplicam e por que as atualizações contam para velocidade e segurança.

Fonte: https://phpsos.de/pt/php/jit-und-performance/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**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](https://phpsos.de/pt/php/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](https://phpsos.de/pt/php/opcache/).

## 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.

```ini
; 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:

```bash
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:

1. **Versão atual do PHP:** as versões novas trazem otimizações e, sobretudo, correções de segurança.
2. **Dimensionar bem o OPcache:** memória suficiente e espaço para todos os ficheiros da aplicação.
3. **Ajustar bem o PHP-FPM:** adaptar o `pm.max_children` à memória disponível, em vez de o aumentar às cegas.
4. **Verificar a base de dados:** encontrar consultas lentas, criar índices.
5. **Cache ao nível da aplicação:** cache de páginas ou de objetos, onde o sistema o suporte.
6. **Medir em vez de adivinhar:** o `request_slowlog_timeout` no 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](https://phpsos.de/pt/leistungen/server-haertung/).

## 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.

## Fontes

- [Manual do PHP: definições do OPcache e do JIT](https://www.php.net/manual/en/opcache.configuration.php)
- [PHP RFC: JIT (PHP 8.0)](https://wiki.php.net/rfc/jit)
- [PHP RFC: OPcache como componente fixo (PHP 8.5)](https://wiki.php.net/rfc/make_opcache_required)
- [php.net: lançamento do PHP 8.4](https://www.php.net/releases/8.4/en.php)