Configuring Managed Cache in 1C-Bitrix
Managed cache in Bitrix is a tagged caching mechanism where each cached object is labelled with tags and invalidation happens by tag rather than by TTL. This solves the main problem with standard file cache: when one record is updated in an infoblock of 10,000 elements, the entire infoblock cache is flushed — all components using its data start running cold.
How Managed Cache Works
The \Bitrix\Main\Data\ManagedCache class operates on top of a storage backend — by default memcached or Redis (configured in /bitrix/.settings.php). Tags are stored separately from data: each tag is a version counter. When a tag is invalidated, the counter is incremented, and all records with an outdated tag version are treated as invalid.
Example usage in a component:
$managedCache = Application::getInstance()->getManagedCache();
$cacheTag = 'iblock_id_' . $ibId;
if ($managedCache->read(3600, 'my_cache_key', $cacheTag)) {
$result = $managedCache->get('my_cache_key');
} else {
$result = /* expensive query */;
$managedCache->set('my_cache_key', $result);
$managedCache->registerTag($cacheTag);
}
When \Bitrix\Main\TaggedCache::clearByTag('iblock_id_5') is called, only data tagged with that tag is flushed — all other components continue serving from cache.
Configuring Redis as the Backend
For production, Redis is recommended — it is faster than memcached when working with tags and supports persistence. Configuration in /bitrix/.settings.php:
'cache' => [
'value' => [
'type' => [
'class_name' => '\\Bitrix\\Main\\Data\\CacheEngineRedis',
'extension' => 'redis',
],
'sid' => 'mysite',
'host' => '127.0.0.1',
'port' => 6379,
'serializer' => Redis::SERIALIZER_IGBINARY,
],
],
The serializer => IGBINARY parameter matters: it reduces the size of serialised PHP objects by 30–50% compared to the default serialize().
Case Study: Cache Invalidation with Frequent Updates
An online store with hourly 1C synchronisation: every hour prices and stock for 500–2,000 items are updated. With standard cache using the IBLOCK_N tag, the entire infoblock cache was flushed 24 times per day. After switching to managed cache with granular tags of the form iblock_element_ID, flushing happens only for changed elements. Pages of unchanged products continue to be served from cache.
What Needs to Be Configured
Correct managed cache setup includes: selecting and configuring the backend (Redis/memcached), verifying the Bitrix version (D7 API, main module version 20+), reviewing components for use of the outdated CBitrixComponent::getCache(), and migrating to ManagedCache where granular invalidation is required. Work takes 1–3 days depending on the number of components and whether Redis is already on the server.