JIT ir našumas PHP 8

Trumpai: PHP JIT (Just-in-Time kompiliatorius) dažnai vykdomą PHP kodą vykdymo metu verčia mašininiu kodu. Jis atsirado su PHP 8.0, yra OPcache dalis ir nuo PHP 8.4 pagal numatymą išjungtas. Skaičiavimams imlios užduotys dėl jo gerokai pagreitėja, tipinės svetainės, tokios kaip WordPress, vargu. Didesnę naudą duoda OPcache, nauja PHP versija ir tinkamai nustatytas procesų valdymas, o kiekviena nauja versija kartu atneša reikalingus saugumo pataisymus.

Kas yra JIT kompiliatorius PHP?

PHP yra interpretuojama kalba: pirminis tekstas pirmiausia verčiamas baitkodu, vadinamaisiais operacijų kodais (opcodes), o juos vykdo Zend Engine. JIT žengia dar vieną žingsnį. Jis stebi, kurios kodo atkarpos vykdomos dažnai, ir būtent jas išverčia į procesoriui skirtą mašininį kodą. Nuo to momento jos veikia be aplinkkelio per interpretatorių.

Įvedimo RFC JIT aprašo kaip beveik savarankišką OPcache dalį. Sugeneruotas mašininis kodas guli papildomoje bendros OPcache atminties srityje. Su PHP 8.4 projektas JIT perkūrė; pasak leidimo puslapio, naujas įgyvendinimas remiasi IR karkasu, bendru tarpiniu kodo generavimo vaizdu. Kaip veikia po juo esantis variklis, paaiškina Zend Engine.

Pirmiausia OPcache: tikrasis našumo pagrindas

Be OPcache PHP kiekvieną failą kiekvienai užklausai verčia iš naujo. OPcache baitkodą laiko bendroje atmintyje, kad visi darbiniai procesai (worker) jį naudotų pakartotinai. Svetainei su turinio valdymo sistema tai pati svarbiausia svirtis. Nuo PHP 8.5, pasak priimto RFC, OPcache yra tvirtai sukompiliuotas į PHP; žinomi ini nustatymai ir toliau valdo, ar talpykla aktyvi.

Svarbios numatytosios reikšmės pagal vadovą: opcache.enable=1, opcache.enable_cli=0, opcache.validate_timestamps=1 ir opcache.revalidate_freq=2. Su paskutiniu nustatymu OPcache tikrina daugiausia kas dvi sekundes, ar failai pasikeitė. Kas išjungia validate_timestamps, po kiekvieno diegimo turi išvalyti talpyklą arba paleisti PHP iš naujo. Daugiau skyriuje OPcache paaiškinta.

PHP JIT konfigūravimas: režimai ir nustatymai

JIT valdomas dviem direktyvomis:

opcache.jit vadovas žino šias reikšmes: disable (visiškai išjungta, vykdymo metu neįjungiama), off (išjungta, bet vykdymo metu įjungiama), tracing arba on (daugumai naudotojų rekomenduojama) ir function. Be to, yra keturženklis skaitinis užrašas smulkesniam derinimui.

; JIT įjungti tikslingai, pvz., skaičiavimams imliems darbiniams procesams
opcache.enable=1
opcache.jit=tracing
opcache.jit_buffer_size=64M

Ar JIT veikia, rodo OPcache būsena:

php -i | grep -i "opcache.jit"          # CLI nustatymai
php --ri "Zend OPcache"                 # OPcache plėtinio konfigūracija

Atkreipkite dėmesį, kad komandinė eilutė gali naudoti kitus nustatymus nei PHP-FPM. Žiniatinklio veiklai svarbi phpinfo() išvestis FPM kontekste, geriausia iškviečiama tik viduje ir po to vėl pašalinama.

Ką JIT duoda praktikoje?

RFC autoriai matavo: sintetinis skriptas bench.php su JIT veikė daugiau nei dvigubai greičiau. Su realiomis programomis laimėjimas buvo mažas; WordPress pasiekė 326, o ne 315 užklausų per sekundę, PHP analizatorius veikė maždaug 1,3 karto greičiau. RFC atvirai sako, kad JIT realių programų, tokių kaip WordPress, ženkliai nepagreitina.

Priežastis slypi tipinių žiniatinklio programų profilyje. Didžiąją laiko dalį jos laukia duomenų bazės, failų sistemos ar išorinių paslaugų. Greitesnis procesoriaus kelias ten padeda mažai. Pasipelnyti gali paveikslėlių apdorojimas PHP, matematiniai skaičiavimai, analizatoriai ar ilgai veikiantys darbiniai procesai.

Našumas be JIT: veiksmingesnės svirtys

Įmonių svetainėms ir parduotuvėms verta laikytis tokios eilės:

1. Nauja PHP versija: naujos versijos atneša optimizacijų ir visų pirma saugumo pataisymų.
2. OPcache tinkamai dimensionuoti: pakankamai atminties ir vietos visiems programos failams.
3. PHP-FPM tinkamai nustatyti: pm.max_children pritaikyti prie turimos operatyviosios atminties, o ne aklai didinti.
4. Patikrinti duomenų bazę: rasti lėtas užklausas, nustatyti indeksus.
5. Talpyklos programos lygiu: puslapių ar objektų talpykla, kur sistema tai palaiko.
6. Matuoti, o ne spėlioti: request_slowlog_timeout PHP-FPM lėtoms užklausoms įrašo atgalinį sekimą (backtrace) į lėtų užklausų žurnalą (slowlog).

JIT, našumas ir saugumas

Našumas ir saugumas susiję glaudžiau, nei atrodo. Pirma: kiekvienas papildomas komponentas yra papildomas kodas. Pats įvedimo RFC nurodo JIT klaidų riziką kodo generavime ir registrų paskirstyme, taip pat sunkesnę klaidų paiešką. Kam JIT nėra išmatuojamai reikalingas, palieka jį prie numatytosios reikšmės disable.

Antra: OPcache ir darbiniai procesai laiko kodą atmintyje. Po saugumo atnaujinimo, tokio kaip dėl PHP2Shell, seni procesai su senu kodu veikia toliau, kol paleidžiami iš naujo. Vien talpyklos išvalymas šio paleidimo iš naujo neatstoja, nes spragos CVE-2026-109618 ir CVE-2026-109619 slypi pačiame PHP vykdomajame faile.

Trečia: geriausias našumo laimėjimas, nauja versija, kartu yra svarbiausia apsaugos priemonė. PHP 8.2 palaikymą baigia 2026-12-31; kas dabar pereina prie 8.4 ar 8.5, laimi abiem atžvilgiais. Kaip sistemas ilgalaikiai išlaikome greitas ir sutvirtintas, aprašo PHP žiniatinklio serverių sutvirtinimas.

Kaip PHP SOS padeda konkrečiai?

• Esamos būklės analizė: nuskaitome OPcache, JIT ir FPM nustatymus ir lyginame su apkrova ir operatyviąja atmintimi.
• Matuoti kliūtis: su slowlog ir serverio rodikliais randame, kur laikas iš tikrųjų prarandamas.
• Saugiai konfigūruoti: JIT tik ten, kur jis įrodomai padeda; OPcache taip, kad diegimai ir atnaujinimai tvarkingai pritaikomi.
• Suplanuoti atnaujinimus: versijų keitimas su testu ir dokumentuotu paleidimu iš naujo, kad greitis ir pataisų būsena derėtų.

Dažni klausimai

Šaltiniai

• PHP vadovas: OPcache ir JIT nustatymai
• PHP RFC: JIT (PHP 8.0)
• PHP RFC: OPcache kaip tvirta dalis (PHP 8.5)
• php.net: PHP 8.4 leidimas