Настройка PHP-акселераторов для 1С-Битрикс
PHP-акселераторы — зонтичный термин. В 2024 году под ним понимают либо OPcache (кеш байткода, встроен в PHP), либо JIT-компиляцию (PHP 8.0+), либо специализированные расширения типа APCu для кеширования данных в памяти. Битрикс использует все три механизма в разных сценариях, и настроить их нужно согласованно.
OPcache + JIT: два уровня ускорения
OPcache кеширует скомпилированный байткод — экономит время парсинга и компиляции. JIT идёт дальше: компилирует часто выполняемый байткод в машинный код x86-64. Теоретически — 3–5x прирост. На практике для веб-приложений вроде Битрикс JIT даёт 5–15%, потому что узкое место — I/O (база, диск), а не CPU.
Включение JIT в php.ini:
[opcache]
opcache.enable = 1
opcache.memory_consumption = 192
opcache.jit = 1255
opcache.jit_buffer_size = 64M
Значение 1255 для opcache.jit расшифровывается:
-
1— использовать регистры процессора (register allocation) -
2— уровень оптимизации (2 из 3) -
5— режим триггера JIT: компилировать функции при горячем исполнении -
5— уровень оптимизации для JIT
Более консервативный вариант для стабильности:
opcache.jit = tracing
opcache.jit_buffer_size = 32M
tracing — JIT трассирует горячие пути выполнения. Это эффективнее для циклов, но PHP-приложения с Битрикс имеют много коротких запросов — выигрыш скромнее.
APCu: кеш данных в shared memory
APCu (APC User Cache) — хранилище ключ-значение в разделяемой памяти. Битрикс использует его через собственный уровень абстракции кеша (Bitrix\Main\Data\ManagedCache + CPHPCacheType).
Установка:
pecl install apcu
echo "extension=apcu.so" > /etc/php.d/40-apcu.ini
Настройка в php.ini:
[apcu]
apc.enabled = 1
apc.shm_size = 128M
apc.ttl = 3600
apc.user_ttl = 3600
apc.gc_ttl = 600
apc.slam_defense = 1
apc.enable_cli = 0
apc.slam_defense = 1 защищает от «dog-pile effect»: когда кеш протухает, множество запросов одновременно начинают его регенерировать. С включённой защитой только один процесс генерирует значение, остальные получают устаревшие данные или ждут.
Подключение APCu к кешированию Битрикс
Битрикс определяет тип кеша через b_option или через конфигурационный файл. Для подключения APCu:
В файле /bitrix/php_interface/dbconn.php:
define("CACHED_b_file", 3600);
define("CACHED_b_agent", 3610);
define("CACHED_b_lang", 3600);
define("CACHED_b_option", 3600);
define("CACHED_b_iblock", 3600);
define("BX_CACHE_TYPE", "apc");
define("BX_CACHE_SID", $_SERVER["DOCUMENT_ROOT"] . "/");
Класс кеша Bitrix\Main\Data\ManagedCache при BX_CACHE_TYPE = "apc" использует APCu. Инвалидация происходит через теги — Битрикс пишет в таблицу b_cache_tag и при следующем запросе проверяет актуальность тегов.
Тонкий момент: APCu и несколько сайтов на сервере
APCu — процессное пространство shared memory. Два сайта на одном PHP-FPM пуле делят одно пространство APCu. Если не разделить пространство имён — кеш одного сайта может перезаписать кеш другого.
Решение: разные PHP-FPM пулы с разным apc.cache_by_default и константой BX_CACHE_SID включающей $_SERVER["DOCUMENT_ROOT"] — это и делает стандартный dbconn.php.
Тест прироста
Замер до и после с ab (Apache Benchmark):
# До включения JIT
ab -n 1000 -c 10 http://site.ru/catalog/ | grep "Requests per second"
# После включения JIT + APCu
ab -n 1000 -c 10 http://site.ru/catalog/ | grep "Requests per second"
Ожидаемый результат на PHP-тяжёлой странице (нет I/O-узкого места): 20–40% прироста RPS. Если страница тратит 80% времени на запросы к БД — прироста почти не будет.
Расширение Swoole / FrankenPHP
Это уже следующий уровень: Swoole и FrankenPHP держат PHP-приложение в памяти как постоянный процесс, устраняя накладные расходы на Bootstrap при каждом запросе. Битрикс официально не поддерживает Swoole — глобальные переменные, статические классы и файловая система сессий несовместимы с persistent-процессом без доработки. FrankenPHP в worker-режиме — то же самое. Использовать на свой страх, только с полным тестированием.







