Configuring PHP Accelerators for 1C-Bitrix
PHP accelerators are an umbrella term. In 2024, it means either OPcache (bytecode cache, built into PHP), JIT compilation (PHP 8.0+), or specialized extensions like APCu for in-memory data caching. Bitrix uses all three mechanisms in different scenarios, and they need to be configured coherently.
OPcache + JIT: Two Levels of Acceleration
OPcache caches compiled bytecode — saves parsing and compilation time. JIT goes further: compiles frequently-executed bytecode to x86-64 machine code. Theoretically 3–5x speedup. In practice for web apps like Bitrix, JIT gives 5–15%, because the bottleneck is I/O (database, disk), not CPU.
Enabling JIT in php.ini:
[opcache]
opcache.enable = 1
opcache.memory_consumption = 192
opcache.jit = 1255
opcache.jit_buffer_size = 64M
The value 1255 for opcache.jit is decoded as:
-
1— use CPU registers (register allocation) -
2— optimization level (2 of 3) -
5— JIT trigger mode: compile functions on hot execution -
5— JIT optimization level
A more conservative option for stability:
opcache.jit = tracing
opcache.jit_buffer_size = 32M
tracing — JIT traces hot execution paths. More effective for loops, but Bitrix apps with many short requests see modest gains.
APCu: In-Memory Data Cache
APCu (APC User Cache) — key-value store in shared memory. Bitrix uses it through its own cache abstraction layer (Bitrix\Main\Data\ManagedCache + CPHPCacheType).
Installation:
pecl install apcu
echo "extension=apcu.so" > /etc/php.d/40-apcu.ini
Configuration in 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 protects against the "dog-pile effect": when cache expires, many requests simultaneously regenerate it. With protection enabled, only one process generates the value, others get stale data or wait.
Connecting APCu to Bitrix Caching
Bitrix determines cache type via b_option or configuration file. To connect APCu:
In /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"] . "/");
The Bitrix\Main\Data\ManagedCache class with BX_CACHE_TYPE = "apc" uses APCu. Invalidation happens through tags — Bitrix writes to b_cache_tag table and checks tag validity on next request.
Subtle Point: APCu and Multiple Sites on One Server
APCu is process shared memory space. Two sites on one PHP-FPM pool share one APCu space. Without namespace separation — one site's cache can overwrite another's.
Solution: separate PHP-FPM pools with different apc.cache_by_default and BX_CACHE_SID constant including $_SERVER["DOCUMENT_ROOT"] — this is what standard dbconn.php does.
Performance Testing
Baseline and after measurements with ab (Apache Benchmark):
# Before enabling JIT
ab -n 1000 -c 10 http://site.ru/catalog/ | grep "Requests per second"
# After enabling JIT + APCu
ab -n 1000 -c 10 http://site.ru/catalog/ | grep "Requests per second"
Expected result on PHP-heavy page (no I/O bottleneck): 20–40% RPS gain. If page spends 80% time on database queries — nearly no gain.
Swoole / FrankenPHP Extension
This is the next level: Swoole and FrankenPHP keep PHP application in memory as a persistent process, eliminating bootstrap overhead on each request. Bitrix officially doesn't support Swoole — global variables, static classes, and file session system are incompatible with persistent process without modifications. FrankenPHP in worker mode is the same. Use at your own risk, only with comprehensive testing.