Bitrix Managed Cache Setup: Redis & Tagged Caching

Bitrix Managed Cache Setup: Redis & Tagged Caching Imagine an online store with a catalog of 50,000 items. Every hour prices update from 1C — and the entire cache is cleared. The server goes down under load, pages load in 10 seconds. Sound familiar? Managed cache (Механизм тегированного кеширован

Our competencies:

Frequently Asked Questions

Bitrix Managed Cache Setup: Redis & Tagged Caching

Imagine an online store with a catalog of 50,000 items. Every hour prices update from 1C — and the entire cache is cleared. The server goes down under load, pages load in 10 seconds. Sound familiar? Managed cache (Механизм тегированного кеширования) solves this without capital investment. We set it up turnkey on Redis or memcached — with guaranteed results. Our experience: over 10 years and 50 successful Bitrix projects. You get savings in server resources and several-fold site acceleration without increasing your hosting budget.

How Managed Cache Solves Performance Problems

Managed cache (\Bitrix\Main\Data\ManagedCache) works on a tag principle: each cached object is marked with a unique identifier. When data updates, only that tag is cleared, not the entire infoblock. This yields 5–10x speed improvement on pages unaffected by changes.

Example from our practice: an online store with hourly 1C exchange (500–2000 items) — after implementing granular iblock_element_ID tags, page load time dropped from 8 seconds to 0.4. Cache was cleared only for changed items, not the whole catalog.

Parameter Standard file cache Managed cache (Redis)
Invalidation mechanism By TTL (time-to-live) By tags (targeted clearing)
Impact of 1C update Clears entire infoblock Clears only changed elements
Page response time 3–10 sec at peak 0.2–0.5 sec stable
Server load High (frequent regeneration) Low (cache lives longer)

What is Tagged Caching and How It Works

Tagged caching is an approach where each cached data fragment is associated with one or more tags. Tags are string identifiers, e.g., iblock_id_5 or element_123. When changes occur (price update, product addition), you invalidate only the corresponding tag, not the entire cache. This minimizes cache regeneration and reduces server load.

How Managed Cache Is Structured

The class \Bitrix\Main\Data\ManagedCache works atop 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 increments; all records with an outdated tag version are considered 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 = /* heavy query */; $managedCache->set('my_cache_key', $result); $managedCache->registerTag($cacheTag); } 

Calling \Bitrix\Main\TaggedCache::clearByTag('iblock_id_5') clears only data marked with that tag — other components keep working from cache.

Configuring Redis as Backend

For production Redis is recommended — it's 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, ], ], 

Parameter serializer => IGBINARY is important: it reduces the size of serialized PHP objects by 30–50% compared to the default serialize().

Learn more about Redis in the official documentation and about tagged caching in Wikipedia.

Why Redis is Better Than Memcached for Managed Cache

Redis wins due to:

  • Persistence — data is not lost on restart (if disk saving is enabled).
  • Support for complex structures — tags can be conveniently stored as hashes or sets.
  • Built-in igbinary — reduces data size by 30–50%.
  • Faster tag invalidation thanks to atomic operations.

Benchmarks show that Redis read/write speed for tags is 2–3 times higher than memcached, especially with many tags (10,000+).

How We Set Up Managed Cache: Step-by-Step

  1. Audit current state: check Bitrix version, presence of main module 20+, identify components not using ManagedCache.
  2. Choose backend: if Redis is already on the server, use it. Otherwise, set up Redis or propose memcached.
  3. Edit .settings.php: specify host, port, igbinary serializer.
  4. Refactor components: replace getCache() with ManagedCache, add granular tags by item ID, section ID, infoblock ID.
  5. Test: load testing, invalidation verification, metrics.
  6. Document: provide the team with instructions for adding new components.

What's Included in Turnkey Managed Cache Setup

Stage What We Do Result
1. Analysis Check Bitrix version, main module 20+ availability, current components Report with recommendations
2. Backend setup Install and configure Redis/memcached, edit .settings.php Working cache storage
3. Component refactoring Replace CBitrixComponent::getCache() with ManagedCache, add tags Granular invalidation
4. Testing Verify 50+ pages, simulate 1C updates Metrics: TTFB, cache hit ratio
5. Documentation Write instructions for adding new components Knowledge transfer to team

Timeline and Pricing

Setup takes 1 to 3 business days depending on the number of components and server readiness (Redis availability). Pricing is calculated individually after a free audit — just contact us and we'll send a detailed estimate.

How to Avoid Common Setup Mistakes

Carefully verify tag registration: every set call must be accompanied by registerTag. Ensure Redis is configured for persistence (save). Use tags not only for items but also for sections, properties, metadata. Load testing before deployment is mandatory — otherwise you risk cache invalidation at peak times.

Get a consultation — we'll help you with your project. Contact us for a free audit of your current cache.