Накратко: PHP JIT (Just-in-Time компилатор) превежда често изпълнявания PHP код в машинен код по време на работа. Той се появи с PHP 8.0, част е от OPcache и от PHP 8.4 по подразбиране е изключен. Изчислително тежките задачи така стават значително по-бързи, типичните уебсайтове като WordPress – едва. По-голяма полза носят OPcache, актуалната версия на PHP и подходящо настроеното управление на процесите, а всяка актуална версия носи и необходимите корекции за сигурност.
Какво е JIT компилаторът в PHP?
PHP е интерпретиран език: изходният текст първо се превежда в байткод, т.нар. опкодове, и Zend Engine ги изпълнява. JIT отива една стъпка по-далеч. Той наблюдава кои участъци от кода се изпълняват често и превежда точно тях в машинен код за процесора. Оттам нататък те работят без заобиколния път през интерпретатора.
RFC за въвеждането описва JIT като почти самостоятелна част от OPcache. Създаденият машинен код се намира в допълнителна област на споделената памет на OPcache. С PHP 8.4 проектът преработи JIT; според страницата на изданието новата реализация се основава на IR framework, обща междинна форма за генериране на код. Как работи машината отдолу, обяснява Zend Engine.
Първо OPcache: същинската основа на производителността
Без OPcache PHP превежда всеки файл наново при всяка заявка. OPcache съхранява байткода в споделената памет, така че всички worker процеси да го използват повторно. За уебсайт със система за управление на съдържание това е с огромна разлика най-важният лост. От PHP 8.5, според приетия RFC, OPcache е неотменно компилиран в PHP; познатите ini настройки продължават да управляват дали кешът е активен.
Важни стойности по подразбиране според ръководството: opcache.enable=1, opcache.enable_cli=0, opcache.validate_timestamps=1 и opcache.revalidate_freq=2. С последната настройка OPcache проверява най-много на всеки две секунди дали файловете са променяни. Който изключи validate_timestamps, трябва след всяко внедряване да изчисти кеша или да рестартира PHP. Повече има в OPcache, обяснен.
Конфигуриране на PHP JIT: режими и настройки
JIT се управлява с две директиви:
| Директива | По подразбиране от 8.4 | По подразбиране преди 8.4 | Значение |
|---|---|---|---|
opcache.jit |
disable |
tracing |
режим на JIT |
opcache.jit_buffer_size |
64M |
0 |
памет за създадения машинен код, 0 изключва JIT |
За opcache.jit ръководството познава тези стойности: disable (напълно изключен, не може да се включи по време на изпълнение), off (изключен, но може да се включи по време на изпълнение), tracing, респективно on (препоръчва се за повечето потребители) и function. Освен това има четирицифрен запис за фини настройки.
; включване на JIT целенасочено, напр. за изчислително тежки worker процеси
opcache.enable=1
opcache.jit=tracing
opcache.jit_buffer_size=64M
Дали JIT работи, показва статусът на OPcache:
php -i | grep -i "opcache.jit" # настройки на CLI
php --ri "Zend OPcache" # конфигурация на разширението OPcache
Имайте предвид, че командният ред може да използва други настройки от PHP-FPM. За уеб режима важи изходът на phpinfo() в контекста на FPM, в идеалния случай извикан само вътрешно и след това премахнат.
Какво дава JIT на практика?
Авторите на RFC са измервали: синтетичният скрипт bench.php с JIT работеше повече от два пъти по-бързо. При реални приложения печалбата беше малка; WordPress достигна 326 вместо 315 заявки в секунда, а PHP парсерът работеше около 1,3 пъти по-бързо. RFC казва открито, че JIT не ускорява значително реални приложения като WordPress.
Причината е в профила на типичните уеб приложения. Те прекарват по-голямата част от времето в чакане на база данни, файловата система или външни услуги. По-бърз път в процесора там помага малко. Могат да се възползват обработка на изображения в PHP, математически изчисления, парсери или дълго работещи worker процеси.
Производителност без JIT: по-ефективните лостове
За фирмени уебсайтове и магазини си струва тази последователност:
- Актуална версия на PHP: новите версии носят оптимизации и преди всичко корекции за сигурност.
- Правилно оразмеряване на OPcache: достатъчно памет и място за всички файлове на приложението.
- Подходящо настройване на PHP-FPM:
pm.max_childrenда се съобрази с наличната оперативна памет, вместо да се увеличава сляпо. - Проверка на базата данни: откриване на бавни заявки, задаване на индекси.
- Кеширане на ниво приложение: кеш на страници или обекти, където системата го поддържа.
- Измерване вместо гадаене:
request_slowlog_timeoutв PHP-FPM записва backtrace за бавни заявки в slowlog.
JIT, производителност и сигурност
Производителността и сигурността са свързани по-тясно, отколкото изглежда. Първо: всеки допълнителен компонент е допълнителен код. RFC за въвеждането самото посочва риска от грешки в JIT, в генерирането на код и в разпределението на регистри, както и по-трудното откриване на грешки. Който не се нуждае измеримо от JIT, го оставя на стойността по подразбиране disable.
Второ: OPcache и worker процесите държат код в паметта. След актуализация за сигурност като тази за PHP2Shell старите процеси продължават да работят със стария код, докато не бъдат рестартирани. Изчистването на кеша само не замества това рестартиране, защото уязвимостите CVE-2026-109618 и CVE-2026-109619 се намират в самия двоичен файл на PHP.
Трето: най-добрата печалба от производителност, актуалната версия, е същевременно най-важната мярка за защита. PHP 8.2 достига края на поддръжката на 31.12.2026 г.; който премине сега към 8.4 или 8.5, печели и от двете. Как поддържаме системите трайно бързи и заздравени, описва Заздравяването на сървъра за PHP уеб сървъри.
Как помага PHP SOS конкретно?
- Анализ на състоянието: Четем настройките на OPcache, JIT и FPM и ги сравняваме с натоварването и оперативната памет.
- Измерване на тесните места: Със slowlog и показатели на сървъра откриваме къде действително се губи времето.
- Сигурна конфигурация: JIT само там, където доказано помага; OPcache така, че внедряванията и актуализациите да действат чисто.
- Планиране на актуализациите: Смяна на версия с тест и документирано рестартиране, за да са наред и скоростта, и състоянието на пачовете.
Често задавани въпроси
JIT активен ли е в PHP по подразбиране?
От PHP 8.4 вече не е: стойността по подразбиране на opcache.jit е disable. Преди това по подразбиране беше tracing, но буферът opcache.jit_buffer_size беше нула, така че JIT също не работеше.
JIT прави ли WordPress по-бърз?
Едва ли. Още в RFC за въвеждането авторите пишат, че JIT не ускорява значително реални приложения като WordPress. Измерената им стойност се покачи от 315 на 326 заявки в секунда.
Нужен ли ми е OPcache, ако не използвам JIT?
Да. OPcache съхранява преведения байткод в споделената памет и спестява повторното компилиране при всяка заявка. Това е най-важният лост за производителност при почти всеки PHP уебсайт. От PHP 8.5 OPcache е вграден неотменно в PHP.
JIT риск за сигурността ли е?
Повече код означава повече възможни грешки. RFC за въвеждането самото посочва риска от грешки в JIT и по-трудното откриване на грешки. Който не се нуждае от него, го оставя изключен; който го използва, трябва особено бързо да внедрява актуализациите.