# JIT ir našumas PHP 8

> PHP JIT ir našumas PHP 8: kaip JIT kompiliatorius veikia su OPcache, kokie nustatymai galioja ir kodėl atnaujinimai svarbūs ir greičiui, ir saugumui.

Šaltinis: https://phpsos.de/lt/php/jit-und-performance/  
Būsena: 2026-10-25  
Teikėjas: PHP SOS, PHP avarinė pagalba ir serverio sauga. Skubi pagalba per „WhatsApp“: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20reikia%20pagalbos%20su%20m%C5%ABs%C5%B3%20PHP%20serveriu.%20%C4%AEmon%C4%97%3A%20%E2%80%A6%20Svetain%C4%97%3A%20%E2%80%A6

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

## PHP JIT konfigūravimas: režimai ir nustatymai

JIT valdomas dviem direktyvomis:

| Direktyva | Numatytoji nuo 8.4 | Numatytoji iki 8.4 | Reikšmė |
|---|---|---|---|
| `opcache.jit` | `disable` | `tracing` | JIT režimas |
| `opcache.jit_buffer_size` | `64M` | `0` | Sugeneruoto mašininio kodo atmintis, `0` išjungia JIT |

`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.

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

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

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

**Ar JIT PHP pagal numatymą aktyvus?**  
Nuo PHP 8.4 nebe: opcache.jit numatytoji reikšmė yra disable. Anksčiau buvo nustatytas tracing, bet buferis opcache.jit_buffer_size buvo 0, todėl JIT taip pat neveikė.

**Ar JIT pagreitina WordPress?**  
Vargu. Dar įvedimo RFC autoriai rašo, kad JIT realių programų, tokių kaip WordPress, ženkliai nepagreitina. Jų matavimo rezultatas pakilo nuo 315 iki 326 užklausų per sekundę.

**Ar man reikia OPcache, jei JIT nenaudoju?**  
Taip. OPcache saugo išverstą baitkodą bendroje atmintyje ir per kiekvieną užklausą sutaupo pakartotinį kompiliavimą. Beveik kiekvienai PHP svetainei tai svarbiausia našumo svirtis. Nuo PHP 8.5 OPcache yra tvirtai įtrauktas į PHP.

**Ar JIT yra saugumo rizika?**  
Daugiau kodo reiškia daugiau galimų klaidų. Pats įvedimo RFC nurodo JIT klaidų riziką ir sunkesnį klaidų paiešką. Kam jo nereikia, palieka išjungtą; kas naudoja, turėtų ypač greitai diegti atnaujinimus.

## Šaltiniai

- [PHP vadovas: OPcache ir JIT nustatymai](https://www.php.net/manual/en/opcache.configuration.php)
- [PHP RFC: JIT (PHP 8.0)](https://wiki.php.net/rfc/jit)
- [PHP RFC: OPcache kaip tvirta dalis (PHP 8.5)](https://wiki.php.net/rfc/make_opcache_required)
- [php.net: PHP 8.4 leidimas](https://www.php.net/releases/8.4/en.php)