Kort gezegd: De PHP JIT (just-in-time-compiler) vertaalt vaak uitgevoerde PHP-code tijdens de uitvoering naar machinecode. Hij kwam met PHP 8.0, maakt deel uit van OPcache en staat sinds PHP 8.4 standaard uit. Rekenintensieve taken worden er aanzienlijk sneller mee, typische websites zoals WordPress nauwelijks. De grotere winst leveren OPcache, een actuele PHP-versie en een passend ingestelde procesbeheer, en elke actuele versie brengt tegelijk de benodigde beveiligingscorrecties mee.
Wat is de JIT-compiler in PHP?
PHP is een geïnterpreteerde taal: de broncode wordt eerst vertaald naar bytecode, zogeheten opcodes, en die voert de Zend Engine uit. Een JIT gaat een stap verder. Hij observeert welke codedelen vaak draaien en vertaalt precies die naar machinecode voor de processor. Vanaf dat moment draaien ze zonder omweg via de interpreter.
De RFC voor de invoering beschrijft de JIT als vrijwel zelfstandig onderdeel van OPcache. De gegenereerde machinecode staat in een extra gebied van het gedeelde OPcache-geheugen. Met PHP 8.4 heeft het project de JIT opnieuw opgebouwd; volgens de releasepagina is de nieuwe implementatie gebaseerd op het IR-framework, een gemeenschappelijke tussenrepresentatie voor het genereren van code. Hoe de engine daaronder werkt, legt de Zend Engine uit.
OPcache eerst: de eigenlijke prestatiebasis
Zonder OPcache vertaalt PHP elk bestand bij elk verzoek opnieuw. OPcache bewaart de bytecode in het gedeelde geheugen, zodat alle workers hem hergebruiken. Voor een website met een contentmanagementsysteem is dat veruit de belangrijkste hefboom. Sinds PHP 8.5 is OPcache volgens de aangenomen RFC vast in PHP ingecompileerd; de bekende ini-instellingen bepalen nog steeds of de cache actief is.
Belangrijke standaardwaarden volgens de handleiding: opcache.enable=1, opcache.enable_cli=0, opcache.validate_timestamps=1 en opcache.revalidate_freq=2. Met de laatste instelling controleert OPcache hooguit elke twee seconden of bestanden zijn gewijzigd. Wie validate_timestamps uitschakelt, moet na elke deployment de cache legen of PHP opnieuw starten. Meer daarover onder OPcache uitgelegd.
PHP JIT configureren: modi en instellingen
De JIT wordt via twee directives aangestuurd:
| Directive | Standaard vanaf 8.4 | Standaard vóór 8.4 | Betekenis |
|---|---|---|---|
opcache.jit |
disable |
tracing |
modus van de JIT |
opcache.jit_buffer_size |
64M |
0 |
geheugen voor gegenereerde machinecode, 0 schakelt de JIT uit |
Voor opcache.jit kent de handleiding deze waarden: disable (helemaal uit, tijdens de uitvoering niet in te schakelen), off (uit, maar tijdens de uitvoering in te schakelen), tracing respectievelijk on (voor de meeste gebruikers aanbevolen) en function. Daarnaast is er een viercijferige getalnotatie voor fijnafstelling.
; JIT gericht inschakelen, bijv. voor rekenintensieve workers
opcache.enable=1
opcache.jit=tracing
opcache.jit_buffer_size=64M
Of de JIT draait, toont de OPcache-status:
php -i | grep -i "opcache.jit" # instellingen van de CLI
php --ri "Zend OPcache" # configuratie van de OPcache-extensie
Houd er rekening mee dat de opdrachtregel andere instellingen kan gebruiken dan PHP-FPM. Voor webgebruik telt de uitvoer van phpinfo() in de FPM-context, bij voorkeur alleen intern opgevraagd en daarna weer verwijderd.
Wat levert de JIT in de praktijk op?
De auteurs van de RFC hebben gemeten: het synthetische script bench.php liep met JIT meer dan twee keer zo snel. Bij echte toepassingen bleef de winst klein; WordPress haalde 326 in plaats van 315 verzoeken per seconde, de PHP-parser liep ongeveer 1,3 keer zo snel. De RFC zegt openlijk dat de JIT echte toepassingen zoals WordPress niet merkbaar versnelt.
De reden ligt in het profiel van typische webtoepassingen. Ze wachten het grootste deel van de tijd op database, bestandssysteem of externe diensten. Een sneller processorpad helpt daar weinig. Profiteren kunnen daarentegen beeldverwerking in PHP, wiskundige berekeningen, parsers of langlopende workers.
Prestaties zonder JIT: de effectievere hefbomen
Voor bedrijfswebsites en webshops loont deze volgorde:
- Actuele PHP-versie: nieuwe versies brengen optimalisaties en vooral beveiligingscorrecties.
- OPcache goed dimensioneren: genoeg geheugen en ruimte voor alle bestanden van de toepassing.
- PHP-FPM passend instellen:
pm.max_childrenafstemmen op het beschikbare werkgeheugen, in plaats van blind te verhogen. - Database controleren: trage queries vinden, indexen aanleggen.
- Caching op toepassingsniveau: pagina- of objectcache, waar het systeem dat ondersteunt.
- Meten in plaats van raden:
request_slowlog_timeoutin PHP-FPM schrijft voor trage verzoeken een backtrace naar het slowlog.
JIT, prestaties en beveiliging
Prestaties en beveiliging hangen nauwer samen dan het lijkt. Ten eerste: elk extra onderdeel is extra code. De RFC voor de invoering noemt zelf het risico van fouten in de JIT, bij het genereren van code en de registertoewijzing, en de moeilijkere foutopsporing. Wie de JIT niet aantoonbaar nodig heeft, laat hem op de standaard disable.
Ten tweede: OPcache en workers houden code in het geheugen. Na een beveiligingsupdate zoals die voor PHP2Shell blijven oude processen met oude code doorlopen totdat ze opnieuw zijn gestart. Het legen van de cache alleen vervangt die herstart niet, want de lekken CVE-2026-109618 en CVE-2026-109619 zitten in de PHP-binary zelf.
Ten derde: de beste prestatiewinst, een actuele versie, is tegelijk de belangrijkste beschermingsmaatregel. PHP 8.2 bereikt op 31 december 2026 het einde van de ondersteuning; wie nu naar 8.4 of 8.5 overstapt, wint beide. Hoe wij systemen blijvend snel en gehard houden, beschrijft de serverhardening voor PHP-webservers.
Hoe helpt PHP SOS concreet?
- Nulmeting: Wij lezen OPcache-, JIT- en FPM-instellingen uit en vergelijken ze met belasting en werkgeheugen.
- Knelpunten meten: Met slowlog en serverkengetallen vinden wij waar de tijd daadwerkelijk verloren gaat.
- Veilig configureren: JIT alleen waar hij aantoonbaar helpt; OPcache zo dat deployments en updates netjes doorwerken.
- Updates inplannen: Versiewissels met test en gedocumenteerde herstart, zodat snelheid en patchstatus kloppen.
Veelgestelde vragen
Is de JIT in PHP standaard actief?
Sinds PHP 8.4 niet meer: de standaardwaarde van opcache.jit is disable. Daarvoor stond tracing ingesteld, maar de buffer opcache.jit_buffer_size stond op 0, waardoor de JIT eveneens niet draaide.
Maakt de JIT WordPress sneller?
Nauwelijks. Al in de RFC voor de invoering schrijven de auteurs dat de JIT echte toepassingen zoals WordPress niet merkbaar versnelt. Hun meetwaarde steeg van 315 naar 326 verzoeken per seconde.
Heb ik OPcache nodig als ik de JIT niet gebruik?
Ja. OPcache slaat de vertaalde bytecode op in het gedeelde geheugen en bespaart bij elk verzoek het opnieuw compileren. Dat is voor bijna elke PHP-website de belangrijkste prestatiehefboom. Sinds PHP 8.5 is OPcache vast in PHP ingebouwd.
Is de JIT een beveiligingsrisico?
Meer code betekent meer mogelijke fouten. De RFC voor de invoering noemt zelf het risico van fouten in de JIT en de moeilijkere foutopsporing. Wie hem niet nodig heeft, laat hem uit; wie hem gebruikt, moet updates bijzonder snel doorvoeren.