# JIT och prestanda i PHP 8

> PHP JIT och prestanda i PHP 8: hur JIT-kompilatorn samverkar med OPcache, vilka inställningar som gäller och varför uppdateringar räknas för fart och säkerhet.

Källa: https://phpsos.de/sv/php/jit-und-performance/  
Aktualitet: 2026-10-25  
Leverantör: PHP SOS, PHP-nödhjälp och serversäkerhet. Omedelbar hjälp via WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20beh%C3%B6ver%20hj%C3%A4lp%20med%20v%C3%A5r%20PHP-server.%20F%C3%B6retag%3A%20%E2%80%A6%20Webbplats%3A%20%E2%80%A6

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

## Konfigurera PHP JIT: lägen och inställningar

JIT styrs med två direktiv:

| Direktiv | Standard från 8.4 | Standard före 8.4 | Betydelse |
|---|---|---|---|
| `opcache.jit` | `disable` | `tracing` | JIT:s läge |
| `opcache.jit_buffer_size` | `64M` | `0` | minne för skapad maskinkod, `0` stänger av JIT |

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.

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

```bash
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](https://phpsos.de/sv/leistungen/server-haertung/).

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

**Är JIT aktiv som standard i PHP?**  
Inte längre sedan PHP 8.4: Standardvärdet för opcache.jit är disable. Tidigare var tracing förinställt, men bufferten opcache.jit_buffer_size var satt till 0, varför JIT inte heller då körde.

**Gör JIT WordPress snabbare?**  
Knappt. Redan i RFC:n för införandet skriver författarna att JIT inte märkbart accelererar verkliga applikationer som WordPress. Deras mätvärde steg från 315 till 326 förfrågningar per sekund.

**Behöver jag OPcache om jag inte använder JIT?**  
Ja. OPcache lagrar den översatta bytekoden i delat minne och sparar ny kompilering vid varje förfrågan. Det är för nästan varje PHP-webbplats den viktigaste prestandahävstången. Sedan PHP 8.5 är OPcache fast inbyggt i PHP.

**Är JIT en säkerhetsrisk?**  
Mer kod betyder fler möjliga fel. RFC:n för införandet nämner själv risken för fel i JIT och den svårare felsökningen. Den som inte behöver det låter bli att använda det; den som använder det bör installera uppdateringar särskilt snabbt.

## Källor

- [PHP-manualen: OPcache- och JIT-inställningar](https://www.php.net/manual/en/opcache.configuration.php)
- [PHP RFC: JIT (PHP 8.0)](https://wiki.php.net/rfc/jit)
- [PHP RFC: OPcache som fast del (PHP 8.5)](https://wiki.php.net/rfc/make_opcache_required)
- [php.net: PHP 8.4 Release](https://www.php.net/releases/8.4/en.php)