PHP 8.3 JIT: я провёл месяц бенчмарков и вот что реально происходит

Когда PHP 8.0 вышел с JIT-компилятором, интернет взорвался. "PHP теперь БЫСТРЕЕ Python!" "JIT изменит всё!" "Переписывайте на PHP!". Заголовки были прекрасны. Реальность — немного иначе.

Я потратил месяц на бенчмарки JIT в нашем реальном highload-проекте на PHP 8.3 + CodeIgniter 4.6. Расскажу что нашёл. Без маркетинга, только цифры и контекст.

Немного теории (обещаю, коротко)

JIT (Just-In-Time compilation) — это компиляция горячего кода в нативные машинные инструкции во время выполнения. В отличие от OPcache, который кэширует opcode (байткод PHP), JIT генерирует настоящий машинный код.

PHP реализует два режима JIT:

• Tracing JIT (jit=tracing) — анализирует трассы выполнения, оптимизирует горячие пути. Лучше для численных вычислений.

• Function JIT (jit=function) — компилирует целые функции. Более предсказуемый, но менее агрессивный.

Конфигурация в php.ini:

[opcache]
opcache.enable=1
opcache.jit=tracing
opcache.jit_buffer_size=256M
opcache.jit_hot_loop=64
opcache.jit_hot_func=127
opcache.jit_hot_return=8
opcache.jit_hot_side_exit=8

Бенчмарк 1: Мандельброт (классика)

function mandelbrot(float $x0, float $y0): int
{
    $x = 0.0;
    $y = 0.0;
    $iteration = 0;
    $maxIteration = 1000;

    while ($x * $x + $y * $y <= 4.0 && $iteration < $maxIteration) {
        $xTemp = $x * $x - $y * $y + $x0;
        $y = 2.0 * $x * $y + $y0;
        $x = $xTemp;
        $iteration++;
    }

    return $iteration;
}

Результаты:

JIT Tracing ускорил Мандельброт в 5 раз. Потрясающий результат! Но кто в вашем web-приложении считает Мандельброт?

Бенчмарк 2: Реальный CI4 request

Результаты на типичном API endpoint (среднее по 10,000 запросов):

Разница: 1.2%. Это в пределах погрешности измерений.

Почему JIT не помогает веб-приложениям

Типичный PHP web-request проводит время примерно так:

• ~45% — ожидание БД (I/O bound)

• ~25% — сетевые операции (Redis, внешние API)

• ~15% — OPcache-оптимизированный PHP-код

• ~10% — сериализация/десериализация (JSON, etc.)

• ~5% — собственно бизнес-логика с вычислениями

JIT помогает именно с CPU-bound вычислениями. Но в web-запросе CPU-bound части — это ~20% от общего времени. Максимальное теоретическое ускорение: 16%. На практике — 1-3%.

Правильная конфигурация для highload CI4

[opcache]
opcache.enable=1
opcache.enable_cli=0

opcache.memory_consumption=256
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0  ; В prod — ВСЕГДА 0
opcache.save_comments=1        ; CI4 использует атрибуты
opcache.preload=/var/www/app/preload.php
opcache.preload_user=www-data

opcache.jit=tracing
opcache.jit_buffer_size=128M
opcache.jit_hot_loop=64
opcache.jit_hot_func=127

И обязательно — preload для CI4:

<?php
// preload.php

$preloadClasses = [
    \App\Models\UserModel::class,
    \App\Models\ProductModel::class,
    \App\Libraries\Cache\ResilientCacheService::class,
    \App\Services\AuthService::class,
    // ... топ-50 самых используемых классов
];

foreach ($preloadClasses as $class) {
    if (class_exists($class)) {
        opcache_compile_file((new \ReflectionClass($class))->getFileName());
    }
}

С preload время ответа на первые запросы после деплоя сократилось с 200ms до 45ms. Это важнее JIT.

Итог: стоит ли включать JIT?

Включайте, если:

• У вас PHP 8.1+ (в 8.0 JIT был сыроват)

• Есть CPU-bound операции (обработка данных, вычисления)

• Достаточно памяти для JIT buffer

Не ждите чудес, если:

• Приложение I/O-bound (БД, Redis, внешние API)

• Это стандартное CRUD web-приложение

• Надеетесь что JIT заменит оптимизацию запросов

Прежде чем думать о JIT, убедитесь что правильно настроен OPcache, нет N+1 запросов, есть кэширование и нормальные индексы в БД. Это даст 10-100× ускорение. JIT — ещё 1-5% сверху. Но 5% при 10 миллионах запросов в сутки — тоже деньги. Поэтому включайте. Просто знайте зачем. 📊