Redis Object Cache для WordPress та WooCommerce — це техніка серверного кешування, яка зберігає результати SQL-запитів, об’єкти параметрів (options) та транзієнти (transients) в оперативній пам’яті (RAM). Вона вирішує проблему високого затримки (TTFB) на динамічних сторінках, де статичне кешування сторінок (page caching) не працює: у кошику, на сторінці оформлення замовлення та в особистому кабінеті користувача.
Чому статичний кеш не працює в WooCommerce та як допомагає Redis
Для більшості інформаційних сторінок WordPress достатньо класичного HTML-кешування (наприклад, через Nginx FastCGI Cache, LiteSpeed або плагіни NGINX/WP Rocket). Проте для інтернет-магазинів на WooCommerce цей підхід має суттєві обмеження. Відповідно до офіційних рекомендацій WooCommerce, такі ендпоінти як /cart/, /checkout/ та сесії авторизованих покупців принципово не підлягають статичному кешуванню, адже відображають персоналізовані дані.
Коли користувач додає товар у кошик, кожен клік генерує десятки складних SQL-запитів до бази даних MySQL (метадані товарів, залишки, правила знижок, сесії). Без об’єктного кешування база даних стає «вузьким місцем», викликаючи затримки відповіді сервера (TTFB > 1–2 секунд), що безпосередньо погіршує поведінкові фактори. Детальніше про це ми писали у матеріалі про те, як швидкість завантаження сайту впливає на SEO і продажі.
Згідно з документацією WordPress WP_Object_Cache, об’єктне кешування wordpress призначене для перехоплення повторних звернень до бази даних. Redis зберігає оброблені об’єкти PHP безпосередньо у RAM, віддаючи їх за долі мілісекунди.
Архітектура взаємодії: PHP-FPM, Redis та MySQL
Робочий цикл запиту з підключеним Redis виглядає наступним чином:
- Запит від користувача: Браузер звертається до динамічної сторінки (наприклад, кошика).
- Перевірка кешу: PHP-скрипт через об’єктний каплера (
object-cache.php) перевіряє наявність потрібних об’єктів у Redis. - Cache Hit (Успіх): Якщо дані знайдено у RAM, вони негайно повертаються в PHP. Запит до MySQL не виконується.
- Cache Miss (Промах): Якщо даних немає, PHP робить запит до MySQL, отримує результат, записує його в Redis для майбутніх запитів і повертає відповідь користувачеві.
Конфігурація з’єднання: Unix Domain Sockets vs TCP/IP
При налаштуванні Redis на тому ж сервері, де розміщено веб-сайт (localhost), використання мережевого сокета TCP/IP створює зайві накладні витрати на рівні операційної системи. Документація з конфігурації Redis рекомендує використовувати Unix domain sockets для локальних з’єднань, що суттєво знижує навантаження, коли виконується налаштування redis на сервері.
| Параметр | TCP/IP (127.0.0.1:6379) | Unix Socket (/var/run/redis/redis-server.sock) |
|---|---|---|
| Латентність (Latency) | Вища (проходження через мережевий стек) | Мінімальна (міжпроцесна взаємодія IPC) |
| Пропускна здатність | Обмежена стеком TCP | Вища на 15–30% для локальних процесів |
| Безпека | Потребує налаштування firewall/bind | Захищено правами доступу до файлової системи |
1. Налаштування у redis.conf
unixsocket /var/run/redis/redis-server.sock
unixsocketperm 770
# Вимикаємо TCP, якщо Redis працює суто локально
port 0Переконайтеся, що користувач www-data (або користувач PHP-FPM) доданий до групи redis для надання прав читання та запису до сокету.
2. Конфігурація у wp-config.php
Щоб плагін Redis Object Cache у WordPress коректно підключався через Unix-сокет, додайте наступні директиви у конфігураційний файл сайту:
// Налаштування з'єднання Redis через Unix Socket
define('WP_REDIS_SCHEME', 'unix');
define('WP_REDIS_PATH', '/var/run/redis/redis-server.sock');
define('WP_REDIS_DATABASE', 0); // Індекс бази даних RedisУправління оперативною пам’яттю: maxmemory та Eviction Policies
Якщо Redis вичерпає виділену оперативну пам’ять без чітко заданої політики витіснення, він почне повертати помилки видачі даних (OOM command not allowed). Згідно з документацією Redis з витіснення ключів, для WordPress та WooCommerce критично важливо правильно налаштувати maxmemory-policy.
Рекомендовані конфігурації у redis.conf:
maxmemory 512mb # Виділений обсяг залежно від RAM сервера
maxmemory-policy allkeys-lru- allkeys-lru: Видаляє найменш використовувані ключі (LRU) серед усіх наявних. Найкращий вибір для стандартного об’єктного кешу WordPress.
- volatile-lru: Видаляє ключі з встановленим терміном придатності (TTL). Підходить, якщо Redis використовується одночасно і для розширеного persistence-збереження.
Ізоляція ключів: Мультисайти та кілька проєктів на одному сервері
Типова помилка при запуску кількох сайтів WordPress на одному сервері з єдиним екземпляром Redis — відсутність розмежування простору ключів. Це призводить до того, що Сайт А отримує контент або конфігурацію Сайту Б.
Щоб уникнути перетину ключів, обов’язково пропишіть унікальну сіль у файлі wp-config.php для кожного сайту:
define('WP_CACHE_KEY_SALT', 'site1_prod_8f3a_');Усунення проблем WooCommerce: застарілий кеш, залишки товарів та race conditions
Під час активних продажів або акцій виникає ризик race conditions (стану гонитви), коли кілька покупців одночасно оформлюють замовлення на один і той самий товар. Якщо об’єктний кеш залишків інвалідується із запізненням, покупець бачить товар у наявності, хоча на складі його вже немає.
Ключові кроки оптимізації бази даних MySQL та Redis для WooCommerce:
- Виключення некешованих груп (Non-persistent groups): Переконайтеся, що сесії WooCommerce та транзієнти кошика не кешуються безстроково. Плагіни повинні додавати
counts,wc_session_idтаtransientдо спискуWP_REDIS_IGNORED_GROUPSза потреби. - Очищення кешу redis woocommerce при імпорті: Якщо ви оновлюєте залишки або ціни через CSV/REST API, вбудовані хуки WordPress не завжди викликають `wp_cache_delete`. Використовуйте автоматизовані скрипти очищення після завершення масового оновлення.
- Моніторинг фрагментації: Слідкуйте за параметром
used_memory_rssу CLI (командаredis-cli info memory), щоб переконатися у відсутності витоків пам’яті.
Чеклист впровадження Redis Object Cache
| Крок | Дія | Мета |
|---|---|---|
| 1 | Перевірка завантаження MySQL | Визначити, чи є запити до `wp_options` та meta-таблиць блокуючими. |
| 2 | Налаштування Unix Socket | Перевести з’єднання з TCP (127.0.0.1) на сокет для зниження latency. |
| 3 | Ізоляція ключів (`WP_CACHE_KEY_SALT`) | Запобігти конфліктам між проєктами на одному сервері. |
| 4 | Конфігурація `maxmemory-policy` | Захистити Redis від падіння за помилкою Out Of Memory. |
| 5 | Тестування checkout та cart | Перевірити відсутність кешування персональних даних та залишків. |
Коли потрібна професійна налаштування Redis на сервері
Налаштування redis woocommerce вимагає збалансованого підходу: помилка у конфігурації може призвести до показу чужих кошиків або некоректного відображення цін. При виборі розширень варто звертати увагу на перевірені рішення — більше про це у нашій статті про те, як безпечно використовувати плагіни.
Команда VORONOV Solutions надає послуги з серверної оптимізації, налаштування систем кешування та комплексної оптимізації сайтів на WordPress/WooCommerce. Усі роботи виконуються прозоро за нашими затвердженими тарифами: у форматі разової погодинної розробки (€35/год), пакетів годин або в межах регулярного супроводу Development Retainer та Website Care.
Поширені запитання (FAQ)
Що саме зберігає Redis Object Cache, а що залишається у MySQL?
Redis Object Cache зберігає у RAM результати повторюваних SQL-запитів, об’єкти параметрів (таблиця wp_options), метадані постів та товарів (wp_postmeta), а також транзієнти. База даних MySQL залишається первинним і надійним місцем збереження усіх даних (замовлення, користувачі, товари), тоді як Redis виступає високошвидкісним буфером для читання.
У чому різниця між безкоштовним плагіном Redis Object Cache та версією Pro для WooCommerce?
Безкоштовна версія реалізує базовий функціонал `WP_Object_Cache` і підходить для більшості стандартних сайтів. Версія Pro містить спеціалізовану оптимізацію для WooCommerce: підтримку Fast-Events, покращену інвалідацію кешу залишків товарів, аналітику запросів у реальному часі та захист від race conditions під час пікових навантажень.
Як правильно виконувати очищення кешу Redis у WooCommerce після масового імпорту товарів?
При масовому імпорті через CSV або API рекомендується тимчасово вимикати об’єктний кеш або виконувати скидання через WP-CLI після завершення процедури за допомогою команди wp cache flush. Це гарантує, що покупці одразу побачать актуальні ціни та наявність товарів без ризику читання застарілих об’єктів з RAM.