Memcached Configuration for 1C-Bitrix

Memcached Configuration for 1C-Bitrix

1C-Bitrix has built-in Memcached support through its caching module. When properly configured, component cache, HTML page cache (composite site), and sessions are stored in memory, bypassing the filesystem. On a server with slow disks (HDD), the difference between file-based cache and Memcached is 5–10× in read time.

Installation and Basic Setup

apt install memcached php-memcached

# Configuration /etc/memcached.conf
-d                        # daemon mode
-m 1024                   # memory in MB
-u memcache
-l 127.0.0.1              # localhost only
-p 11211
-c 1024                   # max connections
-I 32m                    # max item size (for large cache objects)
-t 4                      # threads (= number of CPU cores)

-I 32m — the default per-item limit is 1 MB. 1C-Bitrix caches full HTML blocks of pages; a catalog page with 50 products in HTML can weigh 2–5 MB. Without increasing this limit, Memcached silently drops large objects without saving them.

Connecting Memcached to 1C-Bitrix

In the file /bitrix/.settings.php (not dbconn.php):

return [
    'cache' => [
        'value' => [
            'type' => 'memcache',
            'memcache' => [
                'host' => '127.0.0.1',
                'port' => '11211',
            ],
            'sid' => 'bitrix_cache',
        ],
    ],
];

Or via the admin interface: Settings → Product Settings → Caching — select "Memcache".

Session cache in php.ini:

session.save_handler = memcached
session.save_path = "127.0.0.1:11211"

Multiple Memcached Servers

With multiple application nodes, sessions must be stored in a shared Memcached:

// .settings.php with a server pool
'memcache' => [
    [
        'host' => '10.0.0.10',
        'port' => '11211',
        'weight' => 1,
    ],
    [
        'host' => '10.0.0.11',
        'port' => '11211',
        'weight' => 1,
    ],
],

Memcached uses consistent hashing to distribute keys across nodes — when a node is added or removed, only a portion of the keys are redistributed.

Monitoring and Diagnostics

# Basic statistics
echo "stats" | nc 127.0.0.1 11211

# Key metrics
echo "stats" | nc 127.0.0.1 11211 | grep -E "curr_items|bytes|get_hits|get_misses|evictions"

evictions > 0 — Memcached is evicting old data to make room for new entries. If evictions keep growing, increase -m or analyze what is consuming memory.

Hit rate = get_hits / (get_hits + get_misses). Below 80% — the cache is ineffective: TTL is too short or objects are being evicted prematurely.

# Calculate hit rate
hits=$(echo "stats" | nc 127.0.0.1 11211 | grep get_hits | awk '{print $3}')
misses=$(echo "stats" | nc 127.0.0.1 11211 | grep get_misses | awk '{print $3}')
echo "Hit rate: $(echo "scale=2; $hits / ($hits + $misses) * 100" | bc)%"

Memcached vs Redis for 1C-Bitrix

For component cache and HTML — Memcached is sufficient. For task queues, counters, pub/sub — use Redis.

Common Issue: Stale Cache After Updates

1C-Bitrix invalidates cache by tags. When a product is updated, all caches containing that product's tag are invalidated. If invalidation is not working, verify that the tag system is properly configured in cache_flags.php:

// bitrix/php_interface/cache_flags.php
$GLOBALS['CACHE_FLAGS'] = [
    'iblock_id_list' => true,
    'catalog_price' => true,
];