Pe scurt: PHP JIT (compilatorul just-in-time) traduce în timpul execuției, în cod-mașină, codul PHP executat frecvent. A apărut cu PHP 8.0, face parte din OPcache și este oprit implicit din PHP 8.4. Sarcinile cu calcul intensiv devin astfel sensibil mai rapide, site-urile tipice precum WordPress aproape deloc. Câștigul mai mare îl aduc OPcache, o versiune PHP actuală și o gestionare potrivită a proceselor, iar fiecare versiune actuală aduce totodată remedierile de securitate necesare.
Ce este compilatorul JIT în PHP?
PHP este un limbaj interpretat: codul sursă este tradus mai întâi în bytecode, așa-numitele opcodes, iar Zend Engine le execută. Un JIT merge cu un pas mai departe. El observă ce secțiuni de cod rulează des și traduce exact aceste secțiuni în cod-mașină pentru procesor. Din acel moment ele rulează fără ocolul prin interpretor.
RFC-ul de introducere descrie JIT ca pe o parte aproape independentă a OPcache. Codul-mașină generat se află într-o zonă suplimentară a memoriei comune a OPcache. Cu PHP 8.4, proiectul a reconstruit JIT-ul; potrivit paginii de lansare, noua implementare se bazează pe framework-ul IR, o reprezentare intermediară comună pentru generarea de cod. Cum funcționează motorul de dedesubt explică Zend Engine.
Mai întâi OPcache: adevărata bază a performanței
Fără OPcache, PHP traduce fiecare fișier din nou la fiecare cerere. OPcache păstrează bytecode-ul în memoria comună, astfel încât toți workerii îl reutilizează. Pentru un site cu sistem de gestiune a conținutului, aceasta este, cu mare diferență, cea mai importantă pârghie. Din PHP 8.5, OPcache este, potrivit RFC-ului adoptat, compilat fix în PHP; cunoscutele setări ini controlează în continuare dacă cache-ul este activ.
Valori implicite importante potrivit manualului: opcache.enable=1, opcache.enable_cli=0, opcache.validate_timestamps=1 și opcache.revalidate_freq=2. Cu ultima setare, OPcache verifică cel mult la două secunde dacă fișierele s-au schimbat. Cine dezactivează validate_timestamps trebuie să golească cache-ul sau să repornească PHP după fiecare deployment. Mai multe la OPcache explicat.
Configurarea PHP JIT: moduri și setări
JIT este controlat prin două directive:
| Directivă | Implicit din 8.4 | Implicit înainte de 8.4 | Semnificație |
|---|---|---|---|
opcache.jit |
disable |
tracing |
modul JIT |
opcache.jit_buffer_size |
64M |
0 |
memorie pentru codul-mașină generat, 0 oprește JIT |
Pentru opcache.jit, manualul cunoaște aceste valori: disable (complet oprit, nu poate fi pornit la execuție), off (oprit, dar poate fi pornit la execuție), tracing, respectiv on (recomandat pentru majoritatea utilizatorilor) și function. Pe lângă acestea există o notație numerică din patru cifre pentru reglaje fine.
; pornește JIT țintit, de ex. pentru workeri cu calcul intensiv
opcache.enable=1
opcache.jit=tracing
opcache.jit_buffer_size=64M
Dacă JIT rulează, arată starea OPcache:
php -i | grep -i "opcache.jit" # setările CLI
php --ri "Zend OPcache" # configurația extensiei OPcache
Rețineți că linia de comandă poate folosi alte setări decât PHP-FPM. Pentru exploatarea web contează ieșirea phpinfo() în contextul FPM, ideal accesată doar intern și apoi eliminată.
Ce aduce JIT în practică?
Autorii RFC-ului au măsurat: scriptul sintetic bench.php a rulat cu JIT de mai mult de două ori mai rapid. La aplicațiile reale, câștigul a fost mic; WordPress a ajuns la 326 în loc de 315 cereri pe secundă, iar parserul PHP a rulat de aproximativ 1,3 ori mai rapid. RFC-ul spune deschis că JIT nu accelerează semnificativ aplicațiile reale precum WordPress.
Motivul se află în profilul aplicațiilor web tipice. Ele așteaptă cea mai mare parte a timpului baza de date, sistemul de fișiere sau servicii externe. O cale mai rapidă a procesorului ajută acolo puțin. Pot beneficia, în schimb, procesarea de imagini în PHP, calculele matematice, parserele sau workerii de lungă durată.
Performanță fără JIT: pârghiile mai eficiente
Pentru site-urile de companie și magazine, această ordine merită:
- Versiune PHP actuală: versiunile noi aduc optimizări și, mai ales, remedieri de securitate.
- Dimensionarea corectă a OPcache: suficientă memorie și loc pentru toate fișierele aplicației.
- Setarea potrivită a PHP-FPM: adaptați
pm.max_childrenla memoria disponibilă, în loc să o măriți orbește. - Verificarea bazei de date: găsiți interogările lente, setați indecși.
- Caching la nivel de aplicație: cache de pagini sau de obiecte, acolo unde sistemul îl acceptă.
- Măsurați, nu ghiciți:
request_slowlog_timeoutdin PHP-FPM scrie un backtrace în slowlog pentru cererile lente.
JIT, performanță și securitate
Performanța și securitatea sunt mai strâns legate decât pare. În primul rând: fiecare componentă suplimentară înseamnă cod suplimentar. RFC-ul de introducere menționează el însuși riscul erorilor din JIT, din generarea de cod și din alocarea registrelor, precum și depanarea mai grea. Cine nu are nevoie măsurabilă de JIT îl lasă pe valoarea implicită disable.
În al doilea rând: OPcache și workerii țin codul în memorie. După o actualizare de securitate, precum cea pentru PHP2Shell, procesele vechi rulează mai departe cu cod vechi până sunt repornite. O simplă golire a cache-ului nu înlocuiește această repornire, deoarece vulnerabilitățile CVE-2026-109618 și CVE-2026-109619 se află în binarul PHP însuși.
În al treilea rând: cel mai bun câștig de performanță, o versiune actuală, este totodată cea mai importantă măsură de protecție. PHP 8.2 ajunge la 31.12.2026 la sfârșitul suportului; cine trece acum la 8.4 sau 8.5 câștigă amândouă. Cum menținem sistemele rapide și securizate pe termen lung descrie securizarea serverelor web PHP.
Cum ajută PHP SOS concret?
- Analiza stării actuale: Citim setările OPcache, JIT și FPM și le comparăm cu sarcina și memoria.
- Măsurarea blocajelor: Cu slowlog și indicatorii serverului găsim unde se pierde efectiv timpul.
- Configurare sigură: JIT doar acolo unde ajută dovedit; OPcache astfel încât deployment-urile și actualizările să se aplice corect.
- Planificarea actualizărilor: Schimbări de versiune cu test și repornire documentată, pentru ca viteza și starea de patch să fie în regulă.
Întrebări frecvente
Este JIT activ implicit în PHP?
Din PHP 8.4, nu mai este: valoarea implicită a opcache.jit este disable. Înainte era presetat tracing, dar bufferul opcache.jit_buffer_size era setat pe 0, așa că nici atunci JIT nu rula.
Face JIT WordPress mai rapid?
Aproape deloc. Încă din RFC-ul de introducere, autorii scriu că JIT nu accelerează semnificativ aplicațiile reale precum WordPress. Valoarea lor măsurată a crescut de la 315 la 326 de cereri pe secundă.
Am nevoie de OPcache dacă nu folosesc JIT?
Da. OPcache stochează bytecode-ul tradus în memoria comună și economisește la fiecare cerere recompilarea. Aceasta este pentru aproape orice site PHP cea mai importantă pârghie de performanță. Din PHP 8.5, OPcache este integrat fix în PHP.
Este JIT un risc de securitate?
Mai mult cod înseamnă mai multe erori posibile. RFC-ul de introducere menționează el însuși riscul erorilor din JIT și depanarea mai grea. Cine nu are nevoie de el îl lasă oprit; cine îl folosește ar trebui să instaleze actualizările deosebit de rapid.