Налаштування PHP-акселераторів для 1С-Bitrix
PHP-акселератори — парасолька-термін. У 2024 році під ним розуміють або OPcache (кеш байткода, вбудований у PHP), або JIT-компіляцію (PHP 8.0+), або спеціалізовані розширення типу APCu для кеширування даних у пам'яті. Bitrix використовує всі три механізми в різних сценаріях, і налаштувати їх потрібно узгоджено.
OPcache + JIT: два рівні прискорення
OPcache кешує скомпільований байткод — економить час розбору та компіляції. JIT йде далі: компілює часто виконуваний байткод у машинний код x86-64. Теоретично — 3–5x прирост. На практиці для веб-застосувань типу Bitrix 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-застосування з Bitrix мають багато коротких запитів — виграш скромніше.
APCu: кеш даних у спільній пам'яті
APCu (APC User Cache) — сховище ключ-значення в розділяємій пам'яті. Bitrix використовує його через власний рівень абстракції кешу (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 до кеширування Bitrix
Bitrix визначає тип кешу через 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. Інвалідація відбувається через теги — Bitrix пише в таблицю b_cache_tag і при наступному запиті перевіряє актуальність тегів.
Тонкий момент: APCu та кілька сайтів на сервері
APCu — процесне пространство спільної пам'яті. Два сайти на одному 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 при кожному запиті. Bitrix офіційно не підтримує Swoole — глобальні змінні, статичні класи та файлова система сесій несумісні з persistent-процесом без доробки. FrankenPHP в worker-режимі — те ж саме. Використовуйте на власний страх, тільки з повним тестуванням.