JIT og ydelse i PHP 8

Kort sagt: PHP JIT (just-in-time-compileren) oversætter ofte udført PHP-kode til maskinkode under kørslen. Den kom med PHP 8.0, er en del af OPcache og er siden PHP 8.4 som standard slået fra. Beregningstunge opgaver bliver dermed betydeligt hurtigere, typiske websites som WordPress næppe. Den største gevinst giver OPcache, en aktuel PHP-version og en passende indstillet procesadministration, og hver aktuel version bringer samtidig de nødvendige sikkerhedsrettelser.

Hvad er JIT-compileren i PHP?

PHP er et fortolket sprog: Kildeteksten oversættes først til bytecode, såkaldte opcodes, og dem udfører Zend Engine. En JIT går et skridt videre. Den iagttager, hvilke kodeafsnit der ofte kører, og oversætter netop dem til maskinkode til processoren. Herefter kører de uden omvejen over fortolkeren.

RFC'en om indførelsen beskriver JIT som en næsten selvstændig del af OPcache. Den frembragte maskinkode ligger i et ekstra område af OPcaches delte hukommelse. Med PHP 8.4 har projektet bygget JIT'en op på ny; ifølge release-siden bygger den nye implementering på IR-frameworket, en fælles mellemrepræsentation til kodegenerering. Hvordan motoren arbejder dernede, forklarer Zend Engine.

OPcache først: det egentlige ydelsesgrundlag

Uden OPcache oversætter PHP hver fil på ny ved hver forespørgsel. OPcache gemmer bytecode i den delte hukommelse, så alle workers genbruger den. For et website med et content management-system er det langt den vigtigste løftestang. Siden PHP 8.5 er OPcache ifølge den vedtagne RFC kompileret fast ind i PHP; de kendte ini-indstillinger styrer fortsat, om cachen er aktiv.

Vigtige standardværdier ifølge manualen: opcache.enable=1, opcache.enable_cli=0, opcache.validate_timestamps=1 og opcache.revalidate_freq=2. Med den sidste indstilling kontrollerer OPcache højst hvert andet sekund, om filer er ændret. Den, der slår validate_timestamps fra, skal efter hver udrulning tømme cachen eller genstarte PHP. Mere om det under OPcache forklaret.

Konfigurér PHP JIT: tilstande og indstillinger

JIT styres via to direktiver:

For opcache.jit kender manualen disse værdier: disable (helt fra, kan ikke slås til under kørslen), off (fra, men kan slås til under kørslen), tracing hhv. on (anbefalet til de fleste brugere) og function. Desuden findes der en firecifret talskrivemåde til finjusteringer.

; slå JIT til målrettet, f.eks. for beregningstunge workers
opcache.enable=1
opcache.jit=tracing
opcache.jit_buffer_size=64M

Om JIT kører, viser OPcache-status:

php -i | grep -i "opcache.jit"          # kommandolinjens indstillinger
php --ri "Zend OPcache"                 # konfigurationen af OPcache-udvidelsen

Vær opmærksom på, at kommandolinjen kan bruge andre indstillinger end PHP-FPM. For webdrift tæller outputtet fra phpinfo() i FPM-konteksten, ideelt kun hentet internt og derefter fjernet igen.

Hvad giver JIT i praksis?

RFC'ens forfattere har målt: Det syntetiske script bench.php kørte med JIT mere end dobbelt så hurtigt. Ved reelle applikationer faldt gevinsten lille ud; WordPress nåede 326 i stedet for 315 forespørgsler i sekundet, PHP-parseren kørte omkring 1,3 gange så hurtigt. RFC'en siger åbent, at JIT ikke accelererer reelle applikationer som WordPress nævneværdigt.

Årsagen ligger i typiske webapplikationers profil. De venter størstedelen af tiden på database, filsystem eller eksterne tjenester. En hurtigere processorsti hjælper dér lidt. Profitere kan derimod billedbehandling i PHP, matematiske beregninger, parsere eller langvarigt kørende workers.

Ydelse uden JIT: de mere virksomme løftestænger

For virksomhedswebsites og shops lønner denne rækkefølge sig:

1. Aktuel PHP-version: Nye versioner bringer optimeringer og først og fremmest sikkerhedsrettelser.
2. Dimensionér OPcache rigtigt: nok hukommelse og plads til alle applikationens filer.
3. Indstil PHP-FPM passende: tilpas pm.max_children til den tilgængelige arbejdshukommelse i stedet for blindt at øge.
4. Kontrollér databasen: find langsomme forespørgsler, opret indekser.
5. Caching på applikationsniveau: side- eller objektcache, hvor systemet understøtter det.
6. Mål i stedet for at gætte: request_slowlog_timeout i PHP-FPM skriver for langsomme forespørgsler et backtrace i slowloggen.

JIT, ydelse og sikkerhed

Ydelse og sikkerhed hænger tættere sammen, end det ser ud. For det første: Hver ekstra komponent er ekstra kode. RFC'en om indførelsen nævner selv risikoen for fejl i JIT, i kodegenerering og registertildeling, samt den vanskeligere fejlfinding. Den, der ikke målbart har brug for JIT, lader den stå på standarden disable.

For det andet: OPcache og workers holder kode i hukommelsen. Efter en sikkerhedsopdatering som den til PHP2Shell kører gamle processer videre med gammel kode, indtil de er genstartet. At tømme cachen alene erstatter ikke denne genstart, for sårbarhederne CVE-2026-109618 og CVE-2026-109619 sidder i selve PHP-binæren.

For det tredje: Den bedste ydelsesgevinst, en aktuel version, er samtidig den vigtigste beskyttelsesforanstaltning. PHP 8.2 når den 31.12.2026 slutningen af understøttelsen; den, der nu skifter til 8.4 eller 8.5, vinder begge dele. Hvordan vi holder systemer varigt hurtige og hærdede, beskriver serverhærdning for PHP-webservere.

Hvordan hjælper PHP SOS konkret?

• Analyse af nutilstanden: Vi udlæser OPcache-, JIT- og FPM-indstillinger og sammenholder dem med belastning og arbejdshukommelse.
• Måle flaskehalse: Med slowlog og serverkennetal finder vi, hvor tiden faktisk går tabt.
• Konfigurere sikkert: JIT kun dér, hvor den påviseligt hjælper; OPcache sådan, at udrulninger og opdateringer virker rent.
• Indplanlægge opdateringer: Versionsskift med test og dokumenteret genstart, så tempo og patch-status stemmer.

Ofte stillede spørgsmål

Kilder

• PHP-manualen: OPcache- og JIT-indstillinger
• PHP RFC: JIT (PHP 8.0)
• PHP RFC: OPcache som fast bestanddel (PHP 8.5)
• php.net: PHP 8.4 Release