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 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 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.
; 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:
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:
- Aktuális PHP-verzió: Az új verziók optimalizálásokat, és mindenekelőtt biztonsági javításokat hoznak.
- Az OPcache helyes méretezése: elég memória és hely az alkalmazás összes fájljának.
- A PHP-FPM megfelelő beállítása: a
pm.max_childrenigazítása a rendelkezésre álló memóriához, vakon való növelés helyett. - Az adatbázis ellenőrzése: lassú lekérdezések megkeresése, indexek beállítása.
- Gyorsítótárazás alkalmazásszinten: oldal- vagy objektumgyorsítótár, ahol a rendszer támogatja.
- Mérés találgatás helyett: a PHP-FPM
request_slowlog_timeoutbeá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 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.