# JIT és teljesítmény a PHP 8-ban

> PHP JIT és teljesítmény a PHP 8-ban: hogyan dolgozik a JIT-fordító az OPcache-sel, mely beállítások érvényesek, és miért számítanak a frissítések.

Forrás: https://phpsos.de/hu/php/jit-und-performance/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**Röviden:** A PHP JIT (just-in-time fordító) a gyakran végrehajtott PHP-kódot futásidőben gépi kóddá fordítja. A PHP 8.0-val jelent meg, az OPcache része, és a PHP 8.4 óta alapértelmezés szerint ki van kapcsolva. A számításigényes feladatok ezzel jelentősen gyorsulnak, a tipikus weboldalak, például a WordPress, alig. A nagyobb nyereséget az OPcache, az aktuális PHP-verzió és a megfelelően beállított folyamatkezelés hozza, és minden aktuális verzió egyúttal a szükséges biztonsági javításokat is magával hozza.

## Mi a JIT-fordító a PHP-ban?

A PHP interpretált nyelv: a forráskódot először bájtkóddá, úgynevezett opcode-okká fordítják, és ezeket hajtja végre a Zend Engine. A JIT egy lépéssel továbbmegy. Megfigyeli, mely kódrészek futnak gyakran, és pontosan ezeket fordítja le a processzor gépi kódjára. Ettől kezdve az értelmezőn keresztüli kerülőút nélkül futnak.

A bevezetést szolgáló RFC a JIT-et az OPcache szinte önálló részeként írja le. A létrehozott gépi kód az OPcache közös memóriájának egy további tartományában van. A PHP 8.4-gyel a projekt újraépítette a JIT-et; a kiadási oldal szerint az új megvalósítás az IR-keretrendszerre épül, amely a kódgenerálás közös köztes ábrázolása. Hogyan dolgozik alatta a motor, azt [a Zend Engine](https://phpsos.de/hu/php/zend-engine/) oldal magyarázza.

## Először az OPcache: a valódi teljesítményalap

OPcache nélkül a PHP minden fájlt minden kérésnél újrafordít. Az OPcache a bájtkódot a közös memóriában őrzi, így az összes worker újrahasznosítja. Egy tartalomkezelő rendszerrel működő weboldalnál ez messze a legfontosabb eszköz. A PHP 8.5 óta az OPcache az elfogadott RFC szerint fixen bele van fordítva a PHP-ba; a megszokott ini-beállítások továbbra is azt vezérlik, hogy aktív-e a gyorsítótár.

A kézikönyv szerinti fontos alapértékek: `opcache.enable=1`, `opcache.enable_cli=0`, `opcache.validate_timestamps=1` és `opcache.revalidate_freq=2`. Az utolsó beállítással az OPcache legfeljebb kétmásodpercenként ellenőrzi, változtak-e a fájlok. Aki kikapcsolja a `validate_timestamps`-t, minden telepítés után ürítse a gyorsítótárat, vagy indítsa újra a PHP-t. Többet erről az [OPcache elmagyarázva](https://phpsos.de/hu/php/opcache/) oldalon.

## A PHP JIT beállítása: módok és beállítások

A JIT-et két direktíva vezérli:

| Direktíva | Alapérték 8.4-től | Alapérték 8.4 előtt | Jelentés |
|---|---|---|---|
| `opcache.jit` | `disable` | `tracing` | a JIT módja |
| `opcache.jit_buffer_size` | `64M` | `0` | memória a létrehozott gépi kódnak, a `0` kikapcsolja a JIT-et |

Az `opcache.jit`-hez a kézikönyv ezeket az értékeket ismeri: `disable` (teljesen ki, futásidőben nem kapcsolható be), `off` (ki, de futásidőben bekapcsolható), `tracing`, illetve `on` (a legtöbb felhasználónak ajánlott) és `function`. Emellett létezik egy négyjegyű számírásmód a finombeállításokhoz.

```ini
; a JIT célzott bekapcsolása, pl. számításigényes workerekhez
opcache.enable=1
opcache.jit=tracing
opcache.jit_buffer_size=64M
```

Hogy fut-e a JIT, azt az OPcache állapota mutatja:

```bash
php -i | grep -i "opcache.jit"          # a CLI beállításai
php --ri "Zend OPcache"                 # az OPcache bővítmény konfigurációja
```

Vegye figyelembe, hogy a parancssor más beállításokat használhat, mint a PHP-FPM. Webes üzemben a `phpinfo()` kimenete számít FPM-környezetben, ideális esetben csak belsőleg lekérve, majd ismét eltávolítva.

## Mit hoz a JIT a gyakorlatban?

Az RFC szerzői mértek: a bench.php szintetikus szkript JIT-tel több mint kétszer olyan gyorsan futott. A valós alkalmazásoknál a nyereség kicsi volt; a WordPress másodpercenként 326 kérést ért el 315 helyett, a PHP-értelmező körülbelül 1,3-szor olyan gyorsan futott. Az RFC nyíltan kimondja, hogy a JIT a valós alkalmazásokat, például a WordPresst nem gyorsítja jelentősen.

Az ok a tipikus webalkalmazások profiljában van. Idejük nagy részét adatbázisra, fájlrendszerre vagy külső szolgáltatásokra várakozva töltik. Egy gyorsabb processzorút ott keveset segít. Profitálhat viszont a PHP-ban végzett képfeldolgozás, a matematikai számítások, az értelmezők vagy a hosszan futó workerek.

## Teljesítmény JIT nélkül: a hatékonyabb eszközök

Vállalati weboldalaknál és webshopoknál ez a sorrend éri meg:

1. **Aktuális PHP-verzió:** Az új verziók optimalizálásokat, és mindenekelőtt biztonsági javításokat hoznak.
2. **Az OPcache helyes méretezése:** elég memória és hely az alkalmazás összes fájljának.
3. **A PHP-FPM megfelelő beállítása:** a `pm.max_children` igazítása a rendelkezésre álló memóriához, vakon való növelés helyett.
4. **Az adatbázis ellenőrzése:** lassú lekérdezések megkeresése, indexek beállítása.
5. **Gyorsítótárazás alkalmazásszinten:** oldal- vagy objektumgyorsítótár, ahol a rendszer támogatja.
6. **Mérés találgatás helyett:** a PHP-FPM `request_slowlog_timeout` beállítása a lassú kérésekhez backtrace-t ír a slowlogba.

## JIT, teljesítmény és biztonság

A teljesítmény és a biztonság szorosabban függ össze, mint gondolná. Először: minden további összetevő további kód. A bevezetést szolgáló RFC maga is megnevezi a JIT hibáinak kockázatát a kódgenerálásban és a regiszterkiosztásban, valamint a nehezebb hibakeresést. Aki a JIT-et nem igényli mérhetően, hagyja az alapértelmezett `disable` értéken.

Másodszor: az OPcache és a workerek kódot tartanak a memóriában. Egy biztonsági frissítés után, mint a PHP2Shellhez tartozó, a régi folyamatok régi kóddal futnak tovább, amíg újra nem indítják őket. A gyorsítótár puszta ürítése nem helyettesíti ezt az újraindítást, mert a CVE-2026-109618 és a CVE-2026-109619 rések magában a PHP-binárisban vannak.

Harmadszor: a legjobb teljesítménynyereség, az aktuális verzió, egyben a legfontosabb védelmi intézkedés. A PHP 8.2 támogatása 2026. december 31-én ér véget; aki most vált 8.4-re vagy 8.5-re, mindkettőt megnyeri. Hogyan tartjuk a rendszereket tartósan gyorsan és keményítetten, azt a [PHP-webszerverek keményítése](https://phpsos.de/hu/leistungen/server-haertung/) oldal írja le.

## Hogyan segít konkrétan a PHP SOS?

- **Helyzetelemzés:** Kiolvassuk az OPcache-, JIT- és FPM-beállításokat, és összevetjük őket a terheléssel és a memóriával.
- **A szűk keresztmetszetek mérése:** A slowloggal és a szerver mutatószámaival megtaláljuk, hol vész el ténylegesen az idő.
- **Biztonságos konfiguráció:** JIT csak ott, ahol igazoltan segít; az OPcache úgy, hogy a telepítések és a frissítések rendesen érvényesüljenek.
- **A frissítések beütemezése:** Verzióváltás teszttel és dokumentált újraindítással, hogy a sebesség és a javítási állapot rendben legyen.


## Gyakori kérdések

**Alapértelmezés szerint aktív a JIT a PHP-ban?**  
A PHP 8.4 óta már nem: az opcache.jit alapértéke disable. Korábban a tracing volt az előbeállítás, de az opcache.jit_buffer_size puffer 0-ra volt állítva, így a JIT akkor sem futott.

**Gyorsabbá teszi a JIT a WordPressst?**  
Alig. Már a bevezetést szolgáló RFC-ben azt írják a szerzők, hogy a JIT a valós alkalmazásokat, például a WordPresst nem gyorsítja jelentősen. Mért értékük másodpercenként 315-ről 326 kérésre nőtt.

**Kell az OPcache, ha nem használom a JIT-et?**  
Igen. Az OPcache a lefordított bájtkódot a közös memóriában tárolja, és minden kérésnél megspórolja az újrafordítást. Ez szinte minden PHP-weboldalnál a legfontosabb teljesítményt növelő eszköz. A PHP 8.5 óta az OPcache fixen be van építve a PHP-ba.

**Biztonsági kockázat a JIT?**  
Több kód több lehetséges hibát jelent. A bevezetést szolgáló RFC maga is megnevezi a JIT hibáinak kockázatát és a nehezebb hibakeresést. Aki nem igényli, ne használja; aki használja, különösen gyorsan telepítse a frissítéseket.

## Források

- [PHP-kézikönyv: OPcache- és JIT-beállítások](https://www.php.net/manual/en/opcache.configuration.php)
- [PHP RFC: JIT (PHP 8.0)](https://wiki.php.net/rfc/jit)
- [PHP RFC: Az OPcache mint fix összetevő (PHP 8.5)](https://wiki.php.net/rfc/make_opcache_required)
- [php.net: PHP 8.4 kiadás](https://www.php.net/releases/8.4/en.php)