PHP: полный мануал с примерами, функциями и ООП

Что ускоряет OPcache: готовить код один раз, исполнять для каждого запроса

Интернет-магазин принимает много запросов, каждый использует одни и те же PHP-файлы. Перед исполнением движок разбирает исходник и готовит инструкции. OPcache позволяет сохранить эту подготовленную форму и использовать её снова. Если посетители разные, корзины всё равно вычисляются отдельно: кеш инструкций не хранит готовую корзину первого посетителя.

OPcache сохраняет подготовленный к исполнению PHP-код. При следующем запросе движок может взять готовые инструкции, но сами действия скрипта выполняются снова: SQL, HTTP-запросы, циклы и вывод не превращаются в готовый HTML-кеш. Экземпляр кеша связан с конкретным окружением PHP; консольный вызов не является удалённым управлением всеми PHP-FPM серверами.

<?php
declare(strict_types=1);

$configuration = opcache_get_configuration();
if ($configuration === false) throw new RuntimeException('Нет доступа к OPcache API');
echo $configuration['directives']['opcache.enable'] ? "Подготовленный код кешируется\n" : "Кеш отключён\n";

Подготовленный код кешируется

PHP 8.5 и прежние версии: разные способы подключения

OPcache входит в PHP с 5.5; для 5.2–5.4 существовало отдельное PECL-расширение. Начиная с PHP 8.5 он всегда встроен в бинарник и загружен. Это не означает, что кеширование обязательно включено: opcache.enable и enable_cli продолжают управлять работой. В 8.5 строки zend_extension=opcache.so или zend_extension=php_opcache.dll вызывают предупреждение и должны быть удалены из старой конфигурации при миграции.

Для PHP до 8.5 действовал способ сборки shared extension с --enable-opcache, особенно при --disable-all, и загрузкой через zend_extension с путём к opcache.so/php_opcache.dll. Это Zend-расширение, поэтому обычное extension= не равнозначная замена. При совместном использовании с Xdebug OPcache загружается раньше. На странице installation официального manual ещё присутствует историческая инструкция; для 8.5 применяются более новые правила migration85.

<?php
declare(strict_types=1);

var_dump(extension_loaded('Zend OPcache'));
var_dump(function_exists('opcache_get_status'));
echo ini_get('opcache.enable_cli') === '1' ? "CLI-кеш включён\n" : "CLI-кеш выключен\n";

bool(true)
bool(true)
CLI-кеш включён

php -d opcache.enable_cli=1 -d opcache.jit=disable -d opcache.jit_buffer_size=0 -d opcache.file_update_protection=0 -d opcache.cache_id=phpmanual-local -d opcache.file_cache=C:/php-lab/cache example.php

Учебная file_update_protection=0 позволяет сразу кешировать созданные файлы. На работающем сайте это решение связывают с атомарной публикацией исходников. Не копируйте весь профиль лаборатории в production. Настройки памяти, числа файлов и проверки изменений выбираются по приложению; старое fast_shutdown=1 из исторических рекомендаций более не действует.

Прогрев, изменение кода и разные экземпляры кеша

После старта новый экземпляр памяти пустой. Первые запросы либо специальный прогрев наполняют его. При изменении исходников важно, когда PHP заметит новый код. validate_timestamps и revalidate_freq задают автоматическую проверку; при отключённой проверке обновление входит в процесс развёртывания.

<?php
declare(strict_types=1);

$path = __DIR__ . '/calculation.php';
// Только наш учебный файл: исключаем защиту от совсем нового timestamp.
touch($path, time() - 60);

opcache_compile_file($path);
echo require $path, "\n";
echo require $path, "\n";

42
42

На Linux CLI не управляет in-memory кешем независимого PHP-FPM мастера. Несколько серверов за балансировщиком имеют свои экземпляры; несколько пулов не стоит автоматически считать независимыми кешами без знания процесса запуска. На Windows область разделения определяется также SAPI, пользователем и cache_id. Поэтому «opcache_reset вернул true в консоли» не равно «все посетители уже видят новый релиз».

Для одного изменённого файла есть invalidate, для памяти всего экземпляра — reset, для preloaded-объявлений требуется restart процесса. Файловый кеш — отдельный второй уровень: reset его не удаляет, тогда как актуальный invalidate обрабатывает соответствующую файловую запись. Политика обновления должна быть согласована с конкретной версией и способом развёртывания, а не случайным публичным URL сброса.

Полная таблица настроек: назначение, версия и область изменения

INI_SYSTEM означает настройку при запуске сервера/процесса; ini_set в странице её не заменяет. INI_ALL разрешает runtime-изменение только в рамках специальных правил директивы. Значения в таблице — исходные значения документации, а не готовый универсальный production-профиль. В пакетах ОС они могут быть изменены.

Фактическая ёмкость max_accelerated_files выбирается из 223, 463, 983, 1979, 3907, 7963, 16229, 32531, 65407, 130987, 262237, 524521, 1048793: ближайшее не меньше заданного значения после ограничения допустимого диапазона. Поэтому число в статусе может отличаться от ini. При нехватке памяти рост числа ключей сам по себе не поможет.

jit_hot_loop, jit_hot_func, jit_hot_return и jit_hot_side_exit принимают 0…255. Вне диапазона используется стандартное значение; 0 выключает соответствующий вид трассировки. Список настроек JIT зависит от поддержки в сборке. Порог компиляции не является таймаутом или ограничением пользовательского цикла.

При validate_timestamps=0 отдельные проверки времени всё ещё могут происходить во время компиляции из-за file_update_protection/max_file_size. Это не означает автоматическую актуализацию всего кеша. Подготовьте воспроизводимый план deploy до отключения проверок. Параметры shared memory и huge pages имеют разные роли: общий сегмент может пытаться использовать huge pages и без копирования text segment директивой huge_code_pages.

Проходы оптимизатора и их битовая маска

Оптимизатор преобразует PHP-инструкции перед сохранением. Маска optimization_level задаёт проходы, а не уровень качества JPEG и не права доступа. Стандартная комбинация сохраняет поведение обычного кода; особые небезопасные предположения полезны только для внутренней диагностики.

Например, агрессивная подстановка константы может проигнорировать порядок её объявления. Предположение об отсутствии перегрузки арифметики некорректно для GMP/BCMath-объектов с do_operation. Не включайте все биты в надежде получить «максимальную скорость»: исключённые биты исключены по смысловой причине. Типовая оптимизация проекта начинается с измерений реальных узких мест.

JIT: режимы, пороги и реальная польза

JIT переводит подходящие участки в машинный код. OPcache без JIT всё равно полезен: он исключает повторную подготовку PHP-исходников. Для страницы, которая большую часть времени ждёт SQL или API, JIT не устраняет это ожидание. Больше шансов на выигрыш у длительных вычислительных участков; измерять надо реальную нагрузку после прогрева.

Продвинутая числовая запись CRTO содержит четыре независимые цифры. C:0 без специальных CPU-оптимизаций,1 использует AVX при доступности. R:0 без распределения регистров,1 локальное,2 глобальное. T:0 все функции при загрузке,1 при первом вызове,2 профиль первого запроса с последующей компиляцией горячих функций,3 профилирование горячих функций в ходе работы,4 не используется,5 tracing. O:0 без JIT,1 обычные VM-handlers,2 их встраивание,3 вывод типов,4 граф вызовов,5 оптимизация всего скрипта.

Нулевой jit_buffer_size отключает JIT, ненулевой резервирует память под машинный код. С PHP 8.4 ошибка инициализации включённого JIT прерывает старт fatal error: сначала проверяют профиль на отдельном экземпляре. Для расследования есть jit_debug, jit_bisect_limit и opcache_jit_blacklist. Примеры этой главы не выдают обычное CLI-исполнение за доказательство ускорения JIT.

Preload: чем постоянные объявления отличаются от обычного кеша

С PHP 7.4 startup-скрипт может подготовить функции, классы, интерфейсы и трейты в постоянную память. Они доступны следующим запросам без обычной загрузки объявления. Глобальные константы таким же образом не становятся preloaded. Выигрыш оплачивается базовым потреблением памяти и более строгим обновлением: старые preloaded-объявления убирает restart процесса, а не замена файла на диске.

На Windows preload не поддерживается. Для обычной короткой CLI-команды польза мала: процесс сразу завершится. Исключение в документации — отдельные задачи FFI-библиотек. Практический смысл в долгоживущем серверном процессе, где одни объявления используются многими запросами. Не обязательно загружать весь vendor: измеряют реально нужную часть и базовую память.

opcache.preload=/srv/shop/preload.php
opcache.preload_user=www-data

<?php
declare(strict_types=1);

// preload.php: выполняется при старте поддерживаемого Unix SAPI.
$files = [__DIR__ . '/src/Price.php', __DIR__ . '/src/Cart.php'];
foreach ($files as $path) {
    if (!opcache_compile_file($path)) throw new RuntimeException('Preload не завершён');
}

Startup-файл сам исполняется. Если он использует include/require, тела подключённых файлов тоже исполняются и цепочки их include обрабатываются. Это позволяет условные объявления, но также запускает побочные действия. opcache_compile_file не выполняет тело и даёт больше свободы порядка компиляции, в том числе файлов с наследованием. Для include базовый класс должен быть определён до потомка; условные объявления требуют исполнения нужной ветки.

Если последующий запрос включает уже preloaded-файл, его основное тело всё равно может исполниться, а постоянные символы не объявляются заново. include_once не делает факт preloading равнозначным прошлому обычному include этого запроса. Иногда повторное включение нужно именно ради глобальных констант или runtime-инициализации — поэтому файлы объявлений и побочные действия стоит разделять осмысленно.

При старте FPM от root выполняйте preload с подходящим непривилегированным пользователем. Явное preload_user=root разрешает root-исполнение, но это не рекомендуемый универсальный профиль. С 8.3 правила CLI/phpdbg допускают root-start без этой отдельной настройки; это исключение не следует переносить на серверную модель. Зависимости и объём постоянной памяти проверяют на отдельном окружении перед выпуском.

Полный список функций OPcache по задачам

OPcache не предлагает классы для вашей корзины или платежа. Его функции относятся к подготовке и эксплуатации PHP-кода, а не к бизнес-данным. Подробные карточки содержат различия return, области действия и версии.

Практический маршрут: после deploy видно старую страницу

Мониторинг должен отличать нормальный холодный старт от постоянных промахов и нехватки памяти. Счётчики oom_restarts/hash_restarts/manual_restarts, заполнение памяти и число ключей помогают выбрать, какой предел исследовать. Нельзя из одного процента hit rate заключить, что приложение быстро: медленный SQL, внешний HTTP и тяжёлые циклы остаются. Их разбирает раздел измерения производительности.

Примеры не включают JIT ради красивого числа ускорения и не сбрасывают кеш опубликованного сайта. Чтобы измерить эффект, сравнивают одинаковую нагрузку, прогретость, версии и ресурсы. Сначала устраняют причину задержки, затем выбирают соответствующий вид кеша.