Налаштування 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-запитів і закінчується комплексною перебудовою інфраструктури під ключ. У нашому портфоліо — понад 200 успішних проєктів. Ми — команда сертифікованих фахівців з 10‑річним досвідом роботи в Бітрікс.

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

Nginx. Не просто «увімкнули gzip». Конкретно:

• gzip_comp_level 4-5 — вище безглуздо, CPU з'їдає більше, ніж економить трафік;
• brotli on з brotli_static on — для попередньо стиснутих файлів (Brotli стискає на 20–30% краще за gzip);
• 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 разів. Це дозволило скоротити витрати на сервер до 40% без втрати продуктивності.

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

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

Після аудиту вашого проекту ми визначимо вузькі місця за 2 години та запропонуємо конкретний план прискорення. Замовте безкоштовний аудит швидкості — заповніть форму на сайті.

Фронтенд

Зображення — 60–80% ваги сторінки:

• WebP через CFile::ResizeImageGet() з BX_RESIZE_IMAGE_PROPORTIONAL + конвертація;
• srcset + sizes — не завантажуємо 3000px картинку в блок 400px;
• loading="lazy" для всього нижче першого екрану;
• AVIF — ще 20–30% економії порівняно з 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 проектів з оптимізації швидкості сайту. Замовте безкоштовний аудит швидкості — зв'яжіться з нами просто зараз.