Кеширование объектов в WordPress: Redis и persistent cache

По умолчанию кеш объектов WordPress живёт только до конца текущего PHP-запроса: следующий посетитель снова заставляет сайт обращаться к базе данных. Persistent object cache сохраняет эти данные между запросами, а Redis выступает быстрым внешним хранилищем для такого кеша. Ниже — практическая схема для WordPress 6.x: что установить, какие настройки проверить, как читать и записывать значения и где кеш начинает вредить.

Redis и persistent cache — не одно и то же

Redis — отдельный сервер хранения данных. Persistent object cache — режим, при котором объектный кеш WordPress не очищается после завершения PHP-запроса. Плагин связывает эти два уровня: WordPress вызывает стандартный API кеша, а плагин отправляет значения в Redis.

Это отличается от кеша страниц. Кеш страниц сохраняет готовый HTML-ответ и может вообще не запускать WordPress для повторного запроса. Объектный кеш работает внутри WordPress: он ускоряет запросы к настройкам, мета-полям, результатам сложных вычислений и данным плагинов.

Redis не делает медленный запрос быстрым автоматически. Он сокращает число повторных обращений к базе, но только если приложение правильно выбирает ключи, группы и срок жизни данных.

* Сериализация — преобразование PHP-значения в формат, который можно сохранить во внешнем хранилище, а затем восстановить при чтении.

Что выбрать для WordPress 6.x

Для одного сайта на обычном виртуальном хостинге сначала проверьте, предоставляет ли хостер Redis как сервис. На VPS Redis можно разместить рядом с PHP и базой данных, но тогда нужно отдельно ограничить доступ к порту, настроить перезапуск и следить за памятью. Если сайт состоит из нескольких PHP-воркеров или нескольких серверов, общий Redis обычно полезнее локального кеша каждого процесса.

Подключение Redis Object Cache

Ниже используется актуальная ветка плагина Redis Object Cache для WordPress 6.x. Названия команд и доступные параметры зависят от версии плагина, поэтому перед обновлением сверяйте их с документацией репозитория.

1. Проверьте исходные условия

• У вас есть доступ администратора WordPress или SSH-доступ с WP-CLI.
• На сервере уже запущен Redis, а хостинг сообщил адрес и порт подключения.
• PHP может использовать клиент Redis, поддерживаемый установленной версией плагина.
• Перед изменениями создана резервная копия файла wp-config.php.

Узнайте у хостинга, нужен ли пароль, отдельная база Redis и разрешены ли внешние подключения. Не публикуйте пароль Redis в репозитории и не вставляйте его в статью или тикет поддержки.

2. Установите плагин

Через WP-CLI установите пакет с официальным slug redis-cache:

wp plugin install redis-cache --activate

Если WP-CLI нет, установите плагин через раздел «Плагины» в панели WordPress, используя тот же официальный проект. Проверка: плагин появляется в списке активных, а в разделе «Инструменты» или «Настройки» появляется его экран состояния.

3. Задайте параметры подключения

Для Redis на том же сервере минимальная конфигурация обычно выглядит так. Добавьте константы в wp-config.php до строки, которая заканчивает редактирование файла:

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );

Если Redis находится на другом хосте, используйте адрес, который выдал провайдер. Параметры пароля, TLS, базы Redis и клиента могут отличаться между версиями плагина и настройками хостинга: их нужно брать из документации именно вашей версии, а секреты хранить вне публичного кода.

Проверка: WordPress загружается без ошибки конфигурации, а плагин видит Redis. Если сайт перестал открываться сразу после правки, верните резервную копию wp-config.php и проверьте синтаксис PHP.

4. Включите постоянный кеш

В WP-CLI команда включения выглядит так:

wp redis enable

Проверка: экран Redis Object Cache показывает активное подключение и увеличение счётчиков чтения или записи после нескольких открытий страниц. Если доступен только административный интерфейс, ориентируйтесь на статус плагина и журнал PHP, а не на сам факт установки.

Как писать данные в объектный кеш

В собственном плагине используйте API WordPress, а не прямые вызовы Redis. Так код останется совместимым с другим backend кеша и не будет зависеть от конкретного PHP-клиента.

<?php

$cache_key = 'catalog_top_products';
$cache_group = 'shop_catalog';
$products = wp_cache_get( $cache_key, $cache_group );

if ( false === $products ) {
    $products = get_posts(
        array(
            'post_type'      => 'product',
            'posts_per_page' => 20,
            'post_status'    => 'publish',
        )
    );

    wp_cache_set( $cache_key, $products, $cache_group, 300 );
}

return $products;

Здесь значение хранится пять минут. Ключ должен однозначно описывать входные параметры: если результат зависит от языка, валюты или ID магазина, включите эти признаки в ключ. Группа помогает отделять кеш каталога от кеша других частей приложения.

После изменения исходных данных удаляйте старое значение или меняйте версию ключа. Инвалидация кеша — отдельная тема; здесь важно не считать Redis источником истины. Истиной остаётся база данных, а кеш можно очистить и построить заново.

Типичные ошибки и что проверить

Redis установлен, но кеш не работает

Самый частый сценарий — плагин активирован, но persistent cache не включён. Проверьте статус в панели плагина и выполните команду включения через WP-CLI. Константа WP_CACHE сама по себе не доказывает, что объектный кеш Redis подключён: она часто используется плагинами кеширования страниц.

Ошибка «Connection refused»

Redis не слушает указанный адрес и порт, закрыт локальным firewall или в wp-config.php указан неправильный host. Проверьте состояние сервиса и сетевой маршрут средствами вашего хостинга, затем сравните параметры с настройками Redis.

«Class Redis not found»

PHP не видит выбранный клиент Redis. Это не ошибка ключа WordPress: нужно установить или включить совместимое расширение PHP либо выбрать поддерживаемый плагином клиент, если такая возможность есть в вашей версии.

На сайте показываются старые данные

Redis работает, но приложение не удаляет кеш после изменения записи. Найдите место, где меняются исходные данные, и добавьте очистку соответствующего ключа через API WordPress. Полная очистка Redis может временно снять симптом, но не исправляет ошибочную инвалидацию.

После включения выросло потребление памяти

Persistent cache хранит значения дольше одного запроса, поэтому Redis может быстро заполниться крупными массивами, результатами запросов и дубликатами ключей. Ограничьте срок жизни данных, не складывайте в кеш целые объекты без необходимости и смотрите статистику памяти Redis.

Когда Redis не даст заметного ускорения

Если основная задержка создаётся генерацией HTML, внешним API или тяжёлым запросом, объектный кеш решит только одну часть проблемы. Если посетители получают готовые страницы из page cache, Redis может почти не влиять на время публичного ответа, но ускорять админку, AJAX и запросы, которые нельзя закешировать целиком.

Не включайте общий Redis вслепую на сайте с плагинами, которые используют одинаковые ключи или сохраняют несовместимые структуры данных. Для собственного кода используйте уникальные группы и префиксы, задавайте конечный TTL и проверяйте поведение после обновления WordPress и плагинов.

Что делать дальше

После подключения снимите базовые показатели: время ответа PHP, количество запросов к базе, долю попаданий в кеш, объём Redis и число ошибок подключения. Сравните их до и после на одинаковом сценарии — например, открытие каталога без прогрева и повторное открытие той же страницы. Затем проверьте сброс кеша после изменения записи и отдельно протестируйте админку, корзину и авторизованный режим: именно там объектный кеш чаще всего приносит пользу и чаще всего раскрывает ошибки инвалидации.