Configuring Redis for Data Caching in 1C-Bitrix
Bitrix's standard cache writes data to files in /bitrix/cache/. On a loaded site, this becomes thousands of small files, whose operations hit disk IOPS limits. Redis as an in-memory store provides microsecond access to cache and removes load from the file system.
Connecting Redis as Cache Backend
In /bitrix/.settings.php, add or modify the cache section:
'cache' => [
'value' => [
'type' => [
'class_name' => '\\Bitrix\\Main\\Data\\CacheEngineRedis',
'extension' => 'redis',
],
'sid' => 'site1', // unique prefix for data separation
],
],
Redis connection settings are configured in a separate file /bitrix/php_interface/redis.php or through configuration:
// /bitrix/php_interface/init.php
define('BX_CACHE_TYPE', 'redis');
define('BX_CACHE_SID', 'site1');
$GLOBALS['CACHE_REDIS'] = [
'host' => '127.0.0.1',
'port' => 6379,
'database' => 2, // separate database from sessions
'timeout' => 2,
];
Separating Cache and Sessions
Use different Redis databases (the database parameter):
- Database 0 — reserved by default
- Database 1 — sessions
- Database 2 — Bitrix data cache
- Database 3 — HTML page cache (if used)
This allows clearing cache independently from sessions: redis-cli -n 2 FLUSHDB clears only data cache.
Redis Configuration for Data Cache
# /etc/redis/redis.conf
bind 127.0.0.1
port 6379
maxmemory 1gb
maxmemory-policy allkeys-lru # evict least recently used when memory full
activerehashing yes
tcp-keepalive 300
allkeys-lru is the right policy for cache: when memory fills up, rarely-used keys are evicted. For sessions, volatile-lru is better (only evicts keys with TTL).
Tagged Cache with Redis
Bitrix uses tagged cache for invalidating groups of related data. When an infoblock element changes, the iblock_id_N tag invalidates all cache related to that infoblock. Redis stores tags more efficiently than the file system — no issue with thousands of small files.
Verify that tagged cache works:
redis-cli -n 2 KEYS "BITRIX_CACHE_TAG_*" | head -20
If there are no keys — tagged cache isn't being used or data hasn't been cached yet.
Cache Monitoring
# Usage statistics
redis-cli -n 2 INFO stats | grep -E "keyspace_hits|keyspace_misses"
# Hit rate = hits / (hits + misses)
# Goal: > 90%
# Number of keys
redis-cli -n 2 DBSIZE
# Memory usage
redis-cli INFO memory | grep used_memory_human
Low hit rate (< 70%) means cache is being flushed too often or TTL is too small. Check frequency of tag invalidation: if infoblock data changes every 10 seconds, the entire infoblock cache is flushed every 10 seconds — caching is pointless.