Настройка Memcached для 1С-Битрикс: кэширование, сессии, композит

Сайт на 1С-Битрикс с 20 000 товаров начинает тормозить при фильтрации каталога — страницы генерируются 5–7 секунд, база данных задыхается от запросов. Первое, что мы делаем в таких проектах, — заменяем файловый кэш на Memcached. Это даёт прирост скорости в 5–10 раз на страницах каталога и снижает нагрузку на БД до 90%. В этом материале — как настроить Memcached правильно, чтобы избежать проблем с инвалидацией и вытеснением данных.

Почему Memcached критичен для высоконагруженных сайтов?

Битрикс имеет встроенную поддержку Memcached через модуль кэширования. При правильной настройке кэш компонентов, HTML-страниц (композитный сайт) и сессии хранятся в памяти, минуя файловую систему. На сервере с HDD разница между файловым кэшем и Memcached — 5–10× по времени чтения. Memcached использует consistent hashing для распределения ключей по нодам — это гарантирует минимальное перераспределение при добавлении или удалении сервера.

Типичные боли, которые решает Memcached

• Медленная загрузка страниц каталога из-за чтения кэша с диска
• Рост нагрузки на базу при пиковых посещениях (до 5000 rps)
• Потеря кэша после перезагрузки веб-сервера (файловый кэш не сохраняется)
• Неэффективное использование памяти: файловый кэш занимает дисковое пространство, а не RAM

Как мы настраиваем Memcached под ключ

Наши инженеры имеют 10+ лет опыта работы с Битрикс и выполнили более 100 проектов по оптимизации кэширования. В работе используем только актуальные версии: PHP 8.1+, Memcached 1.6+, php-memcached extension. Гарантируем стабильность и прирост производительности.

Процесс работы

1. Аналитика — замер текущей производительности, выявление узких мест (до 2 часов)
2. Проектирование — расчёт объёма памяти, количества соединений, параметров ядра
3. Установка и конфигурация — настройка Memcached, подключение в Битрикс через .settings.php
4. Тестирование — проверка hit rate, инвалидации, совместимости с композитным режимом
5. Оптимизация — настройка TTL, тегированного кэширования, мониторинг evictions
6. Документация — передача конфигов и инструкций по обслуживанию

Сроки: от 1 до 3 рабочих дней в зависимости от архитектуры проекта. Стоимость настройки — от 25 000 ₽, окупаемость — 2–3 месяца за счёт снижения нагрузки на сервер.

Что входит в работу

• Конфигурационные файлы Memcached с оптимальными параметрами
• Настройка подключения к Битрикс (файл .settings.php, php.ini для сессий)
• Включение тегированного кэширования и настройка cache_flags.php
• Мониторинг: скрипты для сбора статистики (hit rate, evictions)
• Документация: описание конфигурации и инструкция по обслуживанию
• Обучение: консультация по управлению кэшем для вашего администратора
• Поддержка: 2 недели после настройки для решения возможных проблем

Как избежать вытеснения?

Вытеснение (evictions) — это когда Memcached удаляет старые данные, чтобы освободить место под новые. Если evictions постоянно растут, значит выделенной памяти не хватает. В Битрикс это часто случается при кэшировании больших HTML-блоков каталога. Решение — увеличить параметр -m в конфигурации. На практике для проекта с 10 000 товаров и 500 посетителями в сутки достаточно 2 ГБ памяти.

Как подключить Memcached к Битрикс?

Установка и базовая настройка:

apt install memcached php-memcached

# Конфигурация /etc/memcached.conf
-d                        # daemon mode
-m 1024                   # память в МБ
-u memcache
-l 127.0.0.1              # только localhost
-p 11211
-c 1024                   # max connections
-I 32m                    # max item size (для крупных объектов кэша)
-t 4                      # потоки (= количество ядер)

Параметр -I 32m критичен: дефолтный лимит 1 МБ, а страница каталога с 50 товарами в HTML может весить 2–5 МБ. Без увеличения кэш молча не сохраняет крупные объекты.

Подключение в Битрикс:

<?php
// /bitrix/.settings.php
return [
    'cache' => [
        'value' => [
            'type' => 'memcache',
            'memcache' => [
                'host' => '127.0.0.1',
                'port' => '11211',
            ],
            'sid' => 'bitrix_cache',
        ],
    ],
];
?>

; php.ini для кэша сессий
session.save_handler = memcached
session.save_path = "127.0.0.1:11211"

Либо через админку: Настройки → Настройки продукта → Кэширование — выбрать «Memcache».

Как проверить эффективность кэша?

# Базовая статистика
echo "stats" | nc 127.0.0.1 11211 | grep -E "curr_items|bytes|get_hits|get_misses|evictions"

# Подсчёт 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)%"

Hit rate — ключевая метрика. Если ниже 80%, кэш неэффективен: либо слишком короткий TTL, либо объекты вытесняются раньше времени. Мониторинг evictions обязателен: если они растут — увеличивайте -m.

Сравнение Memcached и Redis для Битрикс

Для кэша компонентов и HTML — Memcached достаточен. Для очередей задач, счётчиков, pub/sub — Redis.

Таблица типичных ошибок при настройке

Типичная проблема: устаревший кэш после обновлений

Битрикс инвалидирует кэш по тегам. При обновлении товара инвалидируются все кэши, содержащие тег этого товара. Если инвалидация не работает — проверяем, что тег-система правильно настроена в cache_flags.php:

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

Также важно, чтобы в настройках компонентов не был отключён тегированный кэш. После настройки вы снижаете затраты на серверное оборудование и ускоряете окупаемость проекта.

Дополнительные материалы

Подробнее о Memcached читайте в Wikipedia. По настройке Битрикс — документация 1С-Битрикс.

Свяжитесь с нами для бесплатной консультации и анализа вашего проекта. Закажите настройку Memcached под ключ и получите прирост скорости за 1–3 дня.

80% сайтов на Битрикс тормозят из-за одной таблицы

b_iblock_element_property — EAV-структура, где каждая строка хранит одно значение одного свойства одного элемента. Каталог в 50 000 товаров с 30 свойствами даёт 1,5 млн строк. Умный фильтр делает JOIN этой таблицы с b_iblock_element по пяти свойствам — и MySQL уходит в full table scan на 3–5 секунд.

Наш опыт показывает: без вмешательства в эту таблицу ускорение сайта невозможно. Мы берёмся за проекты, где скорость загрузки упала до 8–10 секунд, и возвращаем TTFB < 200 мс за 1–2 недели. Оптимизация скорости сайта начинается с аудита slow-запросов и заканчивается комплексной перестройкой инфраструктуры под ключ.

[Свяжитесь с нами для аудита] — мы определим узкие места за 2 часа и предложим конкретный план.

Серверная оптимизация

Nginx. Не просто «включили gzip». Конкретно:

• gzip_comp_level 4-5 — выше бессмысленно, CPU сжирает больше, чем экономит трафик;
• brotli on с brotli_static on — для предварительно сжатых файлов;
• HTTP/2 с http2_max_concurrent_streams 128;
• fastcgi_cache для PHP-ответов — кэширование на уровне Nginx, минуя PHP-FPM;
• worker_processes auto, worker_connections под количество одновременных соединений.

PHP-FPM. Выбор между pm = dynamic и pm = static — не академический:

• Static: фиксированное количество воркеров, без overhead на форк — для выделенных серверов с предсказуемой нагрузкой.
• Dynamic: экономит RAM при низком трафике. pm.max_children считаем как (доступная RAM - RAM для MySQL/Redis) / средний расход на процесс.
• OPcache: opcache.memory_consumption=256, opcache.max_accelerated_files=20000, opcache.validate_timestamps=0 на продакшене (перезагрузка PHP-FPM при деплое).

MySQL/MariaDB. Главное узкое место почти всегда:

• slow_query_log с порогом 0.5 сек — каждый запрос разбираем через EXPLAIN.
• innodb_buffer_pool_size = 70–80% доступной RAM на выделенном сервере.
• Составные индексы для фасетного поиска: (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) на b_iblock_element_property.
• OPTIMIZE TABLE b_iblock_element_property после массовых операций.

Как настроить кэширование на три уровня?

Управляемый кэш компонентов. TTL настраиваем для каждого компонента отдельно. Каталог — 3600 сек, новостная лента — 300 сек, баннеры — 86400. Одинаковый TTL везде — гарантия либо устаревших данных, либо бесполезного кэша.

Композитный кэш. Технология bitrix:composite — Nginx отдаёт готовый HTML из файла, PHP не запускается. Динамические зоны (корзина, авторизация) подгружаются AJAX-запросом через CBitrixComponent::setFrameMode(true). TTFB < 50 мс. Но: не все компоненты совместимы, $APPLICATION->ShowPanel() и прямой вывод через echo ломают композит. Проверяем каждую страницу через панель «Производительность → Композитный сайт».

Сравнение: композитный кэш быстрее управляемого в 10–20 раз по времени первого байта. Официальная документация Битрикс по композитному кэшу: Bitrix Composite.

Memcached / Redis. Переносим кэш из файловой системы:

• Сессии → Redis (session.save_handler = redis) — быстрее файлов в 10–50×, плюс работа в кластере.
• Кэш компонентов → Memcached через .settings.php: 'cache' => ['type' => 'memcache'].
• Кэш ORM-запросов — чтобы одинаковые GetList() не нагружали MySQL на каждом хите.

Почему стандартных настроек MySQL недостаточно?

Индексы. Составные для фасетного поиска. Покрывающие для частых выборок — MySQL отвечает из индекса, не обращаясь к данным. Частичные индексы (MariaDB) для фильтрации по ACTIVE = 'Y'. Аудит неиспользуемых индексов — каждый замедляет INSERT/UPDATE.

Партиционирование. Для таблиц с миллионами строк: b_stat_session, b_search_content_stem, Highload-блоки с историей. Партиция по дате — запрос «заказы за месяц» не сканирует данные за три года.

Реальный кейс: каталог 200 000 товаров, 50 свойств. Фильтр по 10 свойствам занимал 12 секунд. После создания составных индексов по (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) и партиционирования b_iblock_element_property по IBLOCK_ID время выполнения упало до 0,3 секунды. Нагрузка на MySQL снизилась в 40 раз.

Очистка. В любой базе за год-два накапливается: устаревший поисковый индекс, просроченные записи в b_cache_tag, история b_iblock_element_prop_s*, логи в b_event_log на гигабайты. Настраиваем регулярную очистку через агенты.

Партиционирование также решает проблему с параллельными запросами при обмене с 1С через CommerceML. Подробнее: MySQL Partitioning Documentation.

Фронтенд

Изображения — 60–80% веса страницы:

• WebP через CFile::ResizeImageGet() с BX_RESIZE_IMAGE_PROPORTIONAL + конвертация;
• srcset + sizes — не грузим 3000px картинку в блок 400px;
• loading="lazy" для всего ниже первого экрана;
• AVIF — ещё 20–30% экономии vs WebP (подробнее: WebP).

CSS/JS:

• Встроенный модуль Битрикс: объединение и минификация через «Настройки → Оптимизация CSS/JS»;
• PurgeCSS / UnCSS — на типичном Битрикс-проекте 60–70% CSS не используются;
• defer / async для некритичного JS;
• Critical CSS инлайном в <head> для мгновенного FCP.

Шрифты:

• <link rel="preload" as="font" crossorigin> для основного шрифта;
• font-display: swap — текст виден сразу;
• Subsetting через pyftsubset — вырезаем кириллицу + латиницу, файл уменьшается в 3–5 раз.

CDN

Cloudflare, BunnyCDN, AWS CloudFront или российские (Selectel CDN, VK Cloud CDN).

• Статика (CSS, JS, изображения, шрифты) — через CDN.
• Правила кэширования: Cache-Control: public, max-age=31536000, immutable для файлов с хешем.
• Оптимизация изображений на лету (imgproxy, Cloudflare Polish) без нагрузки на origin.

Зачем нужно нагрузочное тестирование?

Не синтетические бенчмарки, а реальные сценарии:

• k6 / wrk — имитация маршрутов: каталог → фильтрация → карточка → корзина → оформление.
• Метрики: RPS, время ответа (p50, p95, p99), процент ошибок.
• Xdebug (callgrind) или Blackfire — профилирование PHP, поиск узких мест.

Результат тестирования — объективная картина, где реально тормозит, а не где «кажется». После оптимизации прогоняем повторно — фиксируем улучшения.

Результаты

Что входит в работу?

1. Аудит текущей производительности — анализ slow-запросов, профилирование PHP, проверка кэширования, CDN, серверных настроек.
2. Настройка серверной части — Nginx, PHP-FPM, MySQL, Redis/Memcached, OPcache.
3. Оптимизация кэширования — управляемый кэш, композитный сайт, настройка TTL, тегированное кэширование.
4. Работа с БД — создание индексов, партиционирование, очистка, реорганизация EAV-таблиц.
5. Фронтенд — изображения (WebP/AVIF), CSS/JS (минификация, deferred), шрифты (preload, subsetting).
6. CDN — подключение, настройка правил кэширования.
7. Нагрузочное тестирование — сценарии реальных пользователей, отчёт по метрикам.
8. Документация — описание всех изменений, рекомендации по дальнейшему обслуживанию.
9. Гарантия — поддержка в течение 1 месяца после сдачи.

Мониторинг

Без мониторинга через полгода всё деградирует. Новый модуль, нерасчищенные логи, изменение в шаблоне — и скорость вернулась к исходной.

• web-vitals API — Real User Monitoring от реальных посетителей.
• Synthetic monitoring — Pingdom, UptimeRobot, регулярные проверки из разных локаций.
• Алерты — TTFB > 500 мс или LCP > 3 сек → уведомление.

Сроки и стоимость

Стоимость рассчитывается индивидуально после аудита. [Получите консультацию по вашему проекту] — оценим текущее состояние и предложим план ускорения с конкретными сроками и бюджетом. Мы — команда с 10+ годами опыта в Битрикс, выполнили более 200 проектов по оптимизации скорости сайта.