In breve: il JIT di PHP (compilatore just-in-time) traduce in codice macchina, durante l'esecuzione, il codice PHP eseguito di frequente. È arrivato con PHP 8.0, fa parte di OPcache e da PHP 8.4 è disattivato per impostazione predefinita. I compiti ad alto carico di calcolo diventano così sensibilmente più veloci, i siti web tipici come WordPress quasi per nulla. Il guadagno maggiore viene da OPcache, da una versione di PHP aggiornata e da una gestione dei processi impostata in modo adeguato, e ogni versione aggiornata porta al tempo stesso le necessarie correzioni di sicurezza.
Che cos'è il compilatore JIT in PHP?
PHP è un linguaggio interpretato: il codice sorgente viene prima tradotto in bytecode, i cosiddetti opcode, e questi vengono eseguiti dalla Zend Engine. Un JIT fa un passo in più. Osserva quali sezioni di codice vengono eseguite spesso e traduce proprio quelle in codice macchina per il processore. Da quel momento girano senza il passaggio attraverso l'interprete.
L'RFC di introduzione descrive il JIT come una parte quasi autonoma di OPcache. Il codice macchina generato si trova in un'area aggiuntiva della memoria condivisa di OPcache. Con PHP 8.4 il progetto ha ricostruito il JIT; secondo la pagina di rilascio, la nuova implementazione si basa sul framework IR, una rappresentazione intermedia comune per la generazione del codice. Come lavora il motore sottostante lo spiega la Zend Engine.
Prima OPcache: la vera base delle prestazioni
Senza OPcache PHP traduce ogni file da capo a ogni richiesta. OPcache conserva il bytecode nella memoria condivisa, così tutti i worker lo riutilizzano. Per un sito con un sistema di gestione dei contenuti è di gran lunga la leva più importante. Da PHP 8.5, secondo l'RFC approvato, OPcache è compilata stabilmente in PHP; le note impostazioni ini continuano a stabilire se la cache sia attiva.
Valori predefiniti importanti secondo il manuale: opcache.enable=1, opcache.enable_cli=0, opcache.validate_timestamps=1 e opcache.revalidate_freq=2. Con l'ultima impostazione OPcache verifica al massimo ogni due secondi se i file sono cambiati. Chi disattiva validate_timestamps deve svuotare la cache o riavviare PHP dopo ogni deployment. Altro in OPcache spiegata.
Configurare il JIT di PHP: modalità e impostazioni
Il JIT è controllato da due direttive:
| Direttiva | Predefinito da 8.4 | Predefinito prima di 8.4 | Significato |
|---|---|---|---|
opcache.jit |
disable |
tracing |
Modalità del JIT |
opcache.jit_buffer_size |
64M |
0 |
Memoria per il codice macchina generato, 0 disattiva il JIT |
Per opcache.jit il manuale conosce questi valori: disable (del tutto spento, non attivabile in fase di esecuzione), off (spento, ma attivabile in fase di esecuzione), tracing ovvero on (raccomandato per la maggior parte degli utenti) e function. Esiste inoltre una notazione numerica a quattro cifre per le regolazioni fini.
; attivare il JIT in modo mirato, ad es. per worker ad alto carico di calcolo
opcache.enable=1
opcache.jit=tracing
opcache.jit_buffer_size=64M
Se il JIT sia in esecuzione lo mostra lo stato di OPcache:
php -i | grep -i "opcache.jit" # impostazioni della CLI
php --ri "Zend OPcache" # configurazione dell'estensione OPcache
Tenga presente che la riga di comando può usare impostazioni diverse da PHP-FPM. Per l'esercizio web conta l'output di phpinfo() nel contesto FPM, idealmente richiamato solo internamente e poi rimosso.
Che cosa porta il JIT nella pratica?
Gli autori dell'RFC hanno misurato: lo script sintetico bench.php girava con il JIT a una velocità più che doppia. Nelle applicazioni reali il guadagno è stato piccolo; WordPress è arrivato a 326 invece di 315 richieste al secondo, il parser PHP girava circa 1,3 volte più veloce. L'RFC dice apertamente che il JIT non accelera in modo sensibile le applicazioni reali come WordPress.
Il motivo sta nel profilo delle tipiche applicazioni web. Trascorrono la maggior parte del tempo ad attendere database, file system o servizi esterni. Un percorso più rapido del processore lì aiuta poco. Possono invece trarne vantaggio l'elaborazione di immagini in PHP, i calcoli matematici, i parser o i worker di lunga durata.
Prestazioni senza JIT: le leve più efficaci
Per i siti web aziendali e gli shop vale la pena seguire questo ordine:
- Versione di PHP aggiornata: le nuove versioni portano ottimizzazioni e soprattutto correzioni di sicurezza.
- Dimensionare correttamente OPcache: memoria e spazio sufficienti per tutti i file dell'applicazione.
- Impostare PHP-FPM in modo adeguato: adeguare
pm.max_childrenalla memoria disponibile, invece di aumentarlo alla cieca. - Controllare il database: individuare le query lente, impostare gli indici.
- Caching a livello di applicazione: cache di pagina o di oggetti, dove il sistema la supporta.
- Misurare invece di tirare a indovinare:
request_slowlog_timeoutin PHP-FPM scrive nel slowlog un backtrace per le richieste lente.
JIT, prestazioni e sicurezza
Prestazioni e sicurezza sono più legate di quanto sembri. Primo: ogni componente aggiuntivo è codice aggiuntivo. L'RFC di introduzione cita esso stesso il rischio di errori nel JIT, nella generazione del codice e nell'assegnazione dei registri, oltre alla maggiore difficoltà nella ricerca dei guasti. Chi non ha bisogno misurabile del JIT lo lascia al valore predefinito disable.
Secondo: OPcache e i worker tengono il codice in memoria. Dopo un aggiornamento di sicurezza come quello per PHP2Shell, i vecchi processi continuano a girare con il vecchio codice finché non vengono riavviati. Lo svuotamento della sola cache non sostituisce questo riavvio, perché le vulnerabilità CVE-2026-109618 e CVE-2026-109619 si trovano nel binario PHP stesso.
Terzo: il miglior guadagno di prestazioni, una versione aggiornata, è al tempo stesso la misura di protezione più importante. PHP 8.2 raggiunge la fine del supporto il 31/12/2026; chi passa ora a 8.4 o 8.5 ottiene entrambe le cose. Come manteniamo i sistemi veloci e rafforzati nel tempo lo descrive il rafforzamento dei server web PHP.
Come aiuta concretamente PHP SOS?
- Analisi dello stato attuale: leggiamo le impostazioni di OPcache, JIT e FPM e le confrontiamo con carico e memoria.
- Misurare i colli di bottiglia: con slowlog e indicatori del server troviamo dove il tempo va davvero perso.
- Configurare in sicurezza: JIT solo dove aiuta in modo dimostrabile; OPcache in modo che deployment e aggiornamenti abbiano effetto in modo pulito.
- Pianificare gli aggiornamenti: cambi di versione con test e riavvio documentato, perché velocità e stato delle patch siano corretti.
Domande frequenti
Il JIT è attivo per impostazione predefinita in PHP?
Da PHP 8.4 non più: il valore predefinito di opcache.jit è disable. In precedenza era preimpostato tracing, ma il buffer opcache.jit_buffer_size era impostato a 0, per cui anche allora il JIT non girava.
Il JIT rende più veloce WordPress?
Poco. Già nell'RFC di introduzione gli autori scrivono che il JIT non accelera in modo sensibile le applicazioni reali come WordPress. Il loro valore misurato è salito da 315 a 326 richieste al secondo.
Mi serve OPcache se non uso il JIT?
Sì. OPcache memorizza il bytecode tradotto nella memoria condivisa e a ogni richiesta risparmia una nuova compilazione. Per quasi ogni sito PHP è la leva di prestazioni più importante. Da PHP 8.5 OPcache è integrata stabilmente in PHP.
Il JIT è un rischio per la sicurezza?
Più codice significa più errori possibili. L'RFC di introduzione cita esso stesso il rischio di errori nel JIT e la maggiore difficoltà nella ricerca dei guasti. Chi non ne ha bisogno lo lascia disattivato; chi lo usa dovrebbe installare gli aggiornamenti con particolare rapidità.