# JIT un veiktspēja PHP 8

> PHP JIT un veiktspēja PHP 8: kā JIT kompilators darbojas ar OPcache, kādi iestatījumi ir spēkā un kāpēc atjauninājumi svarīgi ātrumam un drošībai.

Avots: https://phpsos.de/lv/php/jit-und-performance/  
Aktuāls uz: 25.10.2026  
Pakalpojuma sniedzējs: PHP SOS, PHP ārkārtas palīdzība un serveru drošība. Tūlītēja palīdzība pa WhatsApp: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20nepiecie%C5%A1ama%20pal%C4%ABdz%C4%ABba%20ar%20m%C5%ABsu%20PHP%20serveri.%20Uz%C5%86%C4%93mums%3A%20%E2%80%A6%20Vietne%3A%20%E2%80%A6

**Īsi:** PHP JIT (Just-in-Time kompilators) izpildes laikā bieži izpildāmo PHP kodu pārvērš mašīnkodā. Tas parādījās ar PHP 8.0, ir OPcache daļa un kopš PHP 8.4 pēc noklusējuma ir izslēgts. Skaitļošanas ietilpīgi uzdevumi tā rezultātā kļūst ievērojami ātrāki, tipiskas vietnes, piemēram, WordPress, diez vai. Lielāku ieguvumu dod OPcache, aktuāla PHP versija un pareizi iestatīta procesu pārvaldība, un katra aktuāla versija vienlaikus nes vajadzīgos drošības labojumus.

## Kas ir JIT kompilators PHP?

PHP ir interpretēta valoda: avota teksts vispirms tiek pārveidots baitkodā, tā sauktajos opcodes, un tos izpilda Zend Engine. JIT iet vēl soli tālāk. Tas novēro, kuri koda posmi darbojas bieži, un tieši tos pārveido mašīnkodā procesoram. No tā brīža tie darbojas bez apkārtceļa caur interpretatoru.

Ieviešanas RFC apraksta JIT kā gandrīz patstāvīgu OPcache daļu. Izveidotais mašīnkods atrodas papildu apgabalā OPcache koplietojamā atmiņā. Ar PHP 8.4 projekts JIT uzbūvēja no jauna; saskaņā ar izlaiduma lapu jaunā implementācija balstās uz IR ietvaru, kopīgu starpattēlojumu koda ģenerēšanai. Kā zemāk darbojas dzinējs, izskaidro [Zend Engine](https://phpsos.de/lv/php/zend-engine/).

## Vispirms OPcache: īstais veiktspējas pamats

Bez OPcache PHP katru failu katrā pieprasījumā pārveido no jauna. OPcache baitkodu glabā koplietojamā atmiņā, lai visi darbprocesi to izmantotu atkārtoti. Vietnei ar satura pārvaldības sistēmu tas ir ar lielu atrāvienu svarīgākais sviras punkts. Kopš PHP 8.5 saskaņā ar pieņemto RFC OPcache ir cieši iekompilēts PHP; zināmie ini iestatījumi joprojām nosaka, vai kešatmiņa ir aktīva.

Svarīgas noklusējuma vērtības saskaņā ar rokasgrāmatu: `opcache.enable=1`, `opcache.enable_cli=0`, `opcache.validate_timestamps=1` un `opcache.revalidate_freq=2`. Ar pēdējo iestatījumu OPcache pārbauda ne biežāk kā ik pēc divām sekundēm, vai faili ir mainījušies. Kas izslēdz `validate_timestamps`, tam pēc katras izvietošanas jāiztukšo kešatmiņa vai jāpārstartē PHP. Vairāk sadaļā [OPcache izskaidrots](https://phpsos.de/lv/php/opcache/).

## PHP JIT konfigurēšana: režīmi un iestatījumi

JIT vada ar divām direktīvām:

| Direktīva | Noklusējums no 8.4 | Noklusējums pirms 8.4 | Nozīme |
|---|---|---|---|
| `opcache.jit` | `disable` | `tracing` | JIT režīms |
| `opcache.jit_buffer_size` | `64M` | `0` | atmiņa ģenerētajam mašīnkodam, `0` izslēdz JIT |

Direktīvai `opcache.jit` rokasgrāmata min šādas vērtības: `disable` (pilnīgi izslēgts, izpildes laikā neieslēdzams), `off` (izslēgts, bet izpildes laikā ieslēdzams), `tracing` jeb `on` (lielākajai daļai lietotāju ieteicams) un `function`. Bez tam ir četrciparu skaitļu pieraksts smalkai noregulēšanai.

```ini
; JIT mērķtiecīgi ieslēgt, piemēram, skaitļošanas ietilpīgiem darbprocesiem
opcache.enable=1
opcache.jit=tracing
opcache.jit_buffer_size=64M
```

Vai JIT darbojas, rāda OPcache statuss:

```bash
php -i | grep -i "opcache.jit"          # CLI iestatījumi
php --ri "Zend OPcache"                 # OPcache paplašinājuma konfigurācija
```

Ņemiet vērā, ka komandrinda var izmantot citus iestatījumus nekā PHP-FPM. Tīmekļa darbībā svarīga ir `phpinfo()` izvade FPM kontekstā, ideālā gadījumā izsaukta tikai iekšēji un pēc tam noņemta.

## Ko JIT dod praksē?

RFC autori mērīja: sintētiskais skripts bench.php ar JIT darbojās vairāk nekā divreiz ātrāk. Reālām lietojumprogrammām ieguvums bija mazs; WordPress sasniedza 326 nevis 315 pieprasījumus sekundē, PHP parseris darbojās apmēram 1,3 reizes ātrāk. RFC atklāti saka, ka JIT reālas lietojumprogrammas, piemēram, WordPress, būtiski nepaātrina.

Iemesls ir tipisku tīmekļa lietojumprogrammu profilā. Tās lielāko daļu laika gaida datubāzi, failu sistēmu vai ārējus pakalpojumus. Ātrāks procesora ceļš tur palīdz maz. Gūt labumu var attēlu apstrāde PHP, matemātiski aprēķini, parseri vai ilgi darbojoši darbprocesi.

## Veiktspēja bez JIT: efektīvākie sviras punkti

Uzņēmumu vietnēm un veikaliem noder šāda secība:

1. **Aktuāla PHP versija:** jaunās versijas nes optimizācijas un galvenokārt drošības labojumus.
2. **OPcache pareizi dimensionēt:** pietiekami daudz atmiņas un vietas visiem lietojumprogrammas failiem.
3. **PHP-FPM pareizi iestatīt:** `pm.max_children` pielāgot pieejamajai operatīvajai atmiņai, nevis akli palielināt.
4. **Pārbaudīt datubāzi:** atrast lēnus vaicājumus, izveidot indeksus.
5. **Kešatmiņa lietojumprogrammas līmenī:** lapu vai objektu kešatmiņa, kur sistēma to atbalsta.
6. **Mērīt, nevis minēt:** `request_slowlog_timeout` PHP-FPM lēniem pieprasījumiem ieraksta backtrace slowlog.

## JIT, veiktspēja un drošība

Veiktspēja un drošība ir ciešāk saistītas, nekā šķiet. Pirmkārt: katra papildu sastāvdaļa ir papildu kods. Ieviešanas RFC pats min kļūdu risku JIT, koda ģenerēšanā un reģistru piešķiršanā, kā arī sarežģītāku kļūdu meklēšanu. Kam JIT nav izmērāmi vajadzīgs, tas to atstāj pie noklusējuma `disable`.

Otrkārt: OPcache un darbprocesi glabā kodu atmiņā. Pēc drošības atjauninājuma, piemēram, saistībā ar PHP2Shell, veci procesi ar veco kodu turpina darboties, līdz tiek pārstartēti. Kešatmiņas iztīrīšana vien šo pārstartēšanu neaizstāj, jo ievainojamības CVE-2026-109618 un CVE-2026-109619 atrodas pašā PHP binārfailā.

Treškārt: labākais veiktspējas ieguvums, aktuāla versija, vienlaikus ir svarīgākais aizsardzības pasākums. PHP 8.2 atbalstu beidz 31.12.2026; kas tagad pāriet uz 8.4 vai 8.5, iegūst abus. Kā mēs sistēmas ilgstoši uzturam ātras un nostiprinātas, apraksta [servera nostiprināšana PHP tīmekļa serveriem](https://phpsos.de/lv/leistungen/server-haertung/).

## Kā PHP SOS palīdz konkrēti?

- **Esošā stāvokļa analīze:** mēs nolasām OPcache, JIT un FPM iestatījumus un salīdzinām tos ar slodzi un operatīvo atmiņu.
- **Mērīt šaurās vietas:** ar slowlog un servera rādītājiem mēs atrodam, kur laiks patiešām tiek zaudēts.
- **Droša konfigurēšana:** JIT tikai tur, kur tas pierādāmi palīdz; OPcache tā, lai izvietošanas un atjauninājumi darbotos tīri.
- **Ieplānot atjauninājumus:** versiju maiņa ar testu un dokumentētu pārstartēšanu, lai ātrums un ielāpu stāvoklis būtu kārtībā.


## Biežāk uzdotie jautājumi

**Vai JIT PHP pēc noklusējuma ir aktīvs?**  
Kopš PHP 8.4 vairs nē: opcache.jit noklusējuma vērtība ir disable. Agrāk bija iestatīts tracing, taču buferis opcache.jit_buffer_size bija iestatīts uz 0, tāpēc JIT arī nedarbojās.

**Vai JIT padara WordPress ātrāku?**  
Diez vai. Jau ieviešanas RFC autori raksta, ka JIT reālas lietojumprogrammas, piemēram, WordPress, būtiski nepaātrina. Viņu mērījums pieauga no 315 līdz 326 pieprasījumiem sekundē.

**Vai OPcache man vajadzīgs, ja JIT neizmantoju?**  
Jā. OPcache glabā pārveidoto baitkodu koplietojamā atmiņā un katrā pieprasījumā ietaupa atkārtotu kompilēšanu. Tas ir svarīgākais veiktspējas sviras punkts gandrīz katrai PHP vietnei. Kopš PHP 8.5 OPcache ir cieši iebūvēts PHP.

**Vai JIT ir drošības risks?**  
Vairāk koda nozīmē vairāk iespējamu kļūdu. Ieviešanas RFC pats min kļūdu risku JIT un sarežģītāku kļūdu meklēšanu. Kam tas nav vajadzīgs, to atstāj izslēgtu; kas to lieto, atjauninājumus ieviešot īpaši ātri.

## Avoti

- [PHP rokasgrāmata: OPcache un JIT iestatījumi](https://www.php.net/manual/en/opcache.configuration.php)
- [PHP RFC: JIT (PHP 8.0)](https://wiki.php.net/rfc/jit)
- [PHP RFC: OPcache kā obligāta sastāvdaļa (PHP 8.5)](https://wiki.php.net/rfc/make_opcache_required)
- [php.net: PHP 8.4 izlaidums](https://www.php.net/releases/8.4/en.php)