Aktuālā situācija: PHP2Shell. Divas kritiskas PHP ievainojamības (CVSS 9.2) ļauj izpildīt ļaunprātīgu kodu bez pieteikšanās. Ielāpi kopš 21.10.2026.Kas jādara tagad →

JIT un veiktspēja PHP 8

JIT kompilators kopš PHP 8.0 pārvērš PHP mašīnkodā. Tipiskām vietnēm tas dod maz; vairāk dod OPcache, aktuālas versijas un sakārtota konfigurācija.

Aktuāls uz 4 min lasīšanas laiksPHP zināšanas

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

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.

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.

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

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.

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

Tūlītējs kontakts

Katra stunda ir svarīga. Rakstiet mums tūlīt.

Īsi aprakstiet sistēmu, PHP versiju un novēroto. Mēs sazināsimies, noskaidrosim situāciju un strādāsim attālināti, līdz incidents ir slēgts un dokumentēts.

Tūlītēja palīdzība