JIT och prestanda i PHP 8

Kort sagt: PHP JIT (just-in-time-kompilatorn) översätter ofta körd PHP-kod till maskinkod under körning. Den kom med PHP 8.0, är en del av OPcache och är sedan PHP 8.4 avstängd som standard. Beräkningstunga uppgifter blir därmed märkbart snabbare, typiska webbplatser som WordPress knappt. Den större vinsten ger OPcache, en aktuell PHP-version och en lämpligt inställd processhantering, och varje aktuell version innehåller samtidigt de nödvändiga säkerhetsrättelserna.

Vad är JIT-kompilatorn i PHP?

PHP är ett tolkat språk: Källtexten översätts först till bytekod, så kallade opcodes, och dem kör Zend Engine. En JIT går ett steg längre. Den iakttar vilka kodavsnitt som körs ofta och översätter just dem till maskinkod för processorn. Därefter körs de utan omvägen via tolken.

RFC:n för införandet beskriver JIT som en nästan fristående del av OPcache. Den skapade maskinkoden ligger i ett extra område i OPcaches delade minne. Med PHP 8.4 har projektet byggt om JIT; enligt release-sidan bygger den nya implementeringen på IR-ramverket, en gemensam mellanrepresentation för kodgenerering. Hur motorn under den arbetar förklarar Zend Engine.

OPcache först: den egentliga prestandabasen

Utan OPcache översätter PHP varje fil på nytt vid varje förfrågan. OPcache sparar bytekoden i delat minne så att alla workers återanvänder den. För en webbplats med ett innehållshanteringssystem är det den i särklass viktigaste hävstången. Sedan PHP 8.5 är OPcache enligt en antagen RFC fast inkompilerat i PHP; de kända ini-inställningarna styr fortfarande om cachen är aktiv.

Viktiga standardvärden enligt manualen: opcache.enable=1, opcache.enable_cli=0, opcache.validate_timestamps=1 och opcache.revalidate_freq=2. Med den sista inställningen kontrollerar OPcache högst vartannat sekund om filer har ändrats. Den som stänger av validate_timestamps måste tömma cachen eller starta om PHP efter varje driftsättning. Mer om det under OPcache förklarat.

Konfigurera PHP JIT: lägen och inställningar

JIT styrs med två direktiv:

För opcache.jit känner manualen dessa värden: disable (helt av, går inte att slå på vid körning), off (av, men går att slå på vid körning), tracing respektive on (rekommenderas för de flesta användare) och function. Dessutom finns en fyrsiffrig talnotation för finjusteringar.

; slå på JIT målinriktat, t.ex. för beräkningstunga workers
opcache.enable=1
opcache.jit=tracing
opcache.jit_buffer_size=64M

Om JIT körs visar OPcache-statusen:

php -i | grep -i "opcache.jit"          # inställningar för CLI
php --ri "Zend OPcache"                 # konfiguration av OPcache-tillägget

Observera att kommandoraden kan använda andra inställningar än PHP-FPM. För webbdriften räknas utskriften av phpinfo() i FPM-kontext, helst bara hämtad internt och därefter borttagen igen.

Vad ger JIT i praktiken?

RFC:ns författare har mätt: Det syntetiska skriptet bench.php körde med JIT mer än dubbelt så snabbt. I verkliga applikationer blev vinsten liten; WordPress nådde 326 i stället för 315 förfrågningar per sekund, PHP-parsern körde ungefär 1,3 gånger så snabbt. RFC:n säger öppet att JIT inte märkbart accelererar verkliga applikationer som WordPress.

Orsaken ligger i profilen för typiska webbapplikationer. De väntar största delen av tiden på databas, filsystem eller externa tjänster. En snabbare processorväg hjälper där föga. Nytta kan däremot ha bildbehandling i PHP, matematiska beräkningar, parsrar eller långkörande workers.

Prestanda utan JIT: de verksammare hävstängerna

För företagswebbplatser och butiker lönar sig den här ordningen:

1. Aktuell PHP-version: Nya versioner ger optimeringar och framför allt säkerhetsrättelser.
2. Dimensionera OPcache rätt: tillräckligt med minne och plats för alla applikationens filer.
3. Ställ in PHP-FPM rätt: anpassa pm.max_children efter tillgängligt arbetsminne i stället för att höja blint.
4. Kontrollera databasen: hitta långsamma frågor, sätt index.
5. Cachning på applikationsnivå: sid- eller objektcache där systemet stöder det.
6. Mäta i stället för gissa: request_slowlog_timeout i PHP-FPM skriver en backtrace till slowlog för långsamma förfrågningar.

JIT, prestanda och säkerhet

Prestanda och säkerhet hänger ihop tätare än det verkar. För det första: Varje extra komponent är extra kod. RFC:n för införandet nämner själv risken för fel i JIT, i kodgenerering och registerallokering, samt den svårare felsökningen. Den som inte mätbart behöver JIT låter den vara kvar på standardvärdet disable.

För det andra: OPcache och workers håller kod i minnet. Efter en säkerhetsuppdatering som den för PHP2Shell fortsätter gamla processer att köra med gammal kod tills de har startats om. Att bara tömma cachen ersätter inte omstarten, eftersom sårbarheterna CVE-2026-109618 och CVE-2026-109619 sitter i själva PHP-binären.

För det tredje: Den bästa prestandavinsten, en aktuell version, är samtidigt den viktigaste skyddsåtgärden. PHP 8.2 når slutet av supporten den 31 december 2026; den som byter till 8.4 eller 8.5 nu vinner båda. Hur vi håller system varaktigt snabba och härdade beskriver serverhärdning för PHP-webbservrar.

Hur hjälper PHP SOS konkret?

• Nulägesanalys: Vi läser ut OPcache-, JIT- och FPM-inställningar och jämför dem med belastning och arbetsminne.
• Mäta flaskhalsar: Med slowlog och servernyckeltal hittar vi var tiden faktiskt går förlorad.
• Konfigurera säkert: JIT bara där den bevisligen hjälper; OPcache så att driftsättningar och uppdateringar slår igenom rent.
• Planera uppdateringar: Versionsbyten med test och dokumenterad omstart, så att fart och patchläge stämmer.

Vanliga frågor

Källor

• PHP-manualen: OPcache- och JIT-inställningar
• PHP RFC: JIT (PHP 8.0)
• PHP RFC: OPcache som fast del (PHP 8.5)
• php.net: PHP 8.4 Release