Объектный кэш WordPress на Valkey: настройка и пределы

Постоянный объектный кэш хранит результаты обращений WordPress к базе данных в Valkey между запросами, так что следующий запрос читает их из памяти, а не спрашивает базу снова. На сайте с вошедшими пользователями, загруженной админкой или магазином на WooCommerce он резко сокращает число запросов к базе на страницу и заметно ускоряет админку. На сайте-визитке, страницы которого уже отдаются из страничного кэша, он почти ничего не меняет: страница вообще не доходит до PHP, так что экономить нечего.

Это различие и есть вся статья в одном предложении. Сама настройка занимает десять минут: плагин, четыре строки в wp-config.php и кнопка. Подумать придётся о другом: относится ли ваш сайт к тем, кому это выгодно, какого размера нужен кэш, и как распознать несколько типичных сбоев - устаревшие опции, отсутствующий drop-in, кэш, случайно общий для нескольких сайтов. Всё это разобрано ниже.

Что такое объектный кэш#

Объектный кэш в WordPress был всегда: класс WP_Object_Cache, стоящий за wp_cache_get() и wp_cache_set(). Ядро использует его для опций, записей, метаданных записей, терминов, пользователей и результатов запросов, а плагины - для собственных данных. По умолчанию он живёт в памяти PHP и умирает в конце каждого запроса. Он избавляет от повторных обращений в пределах одной загрузки страницы и никак не помогает между загрузками.

Постоянный объектный кэш заменяет этот класс другим, который хранит те же данные на внешнем сервере. WordPress загружает замену из файла drop-in wp-content/object-cache.php раньше почти всего остального. Когда он на месте, второй запрос той же записи не обращается к базе ни за записью, ни за её метаданными, терминами или автором - всё берётся из Valkey.

Начиная с WordPress 6.1 экран Site Health рекомендует постоянный объектный кэш на сайтах, которые считает достаточно крупными, чтобы от него выиграть, - поэтому многие владельцы сайтов впервые слышат о нём именно там.

Что он ускоряет, а что нет#

Объектный кэш помогает только запросам, которые запускают PHP и обращаются к базе данных. Значит, вопрос в том, какие запросы на вашем сайте так делают.

Две последние строки - неудобные. Если страница медленная, потому что плагин выполняет meta_query, сканирующий сто тысяч строк, объектный кэш отдаст результат быстро во второй раз и так же медленно в первый - и при каждой очистке кэша. А если страница медленная, потому что конструктор страниц тратит 800 мс на сборку HTML в PHP, никакой кэш данных этого не изменит. Измеряйте, прежде чем что-то добавлять. Query Monitor показывает число и время запросов на страницу, а также попадает ли объектный кэш.

Порядок действий для медленного сайта на WordPress:

1. Кэш страниц для анонимного трафика - для большинства сайтов это самый большой выигрыш.
2. Исправить самые медленные запросы и самые тяжёлые плагины.
3. Постоянный объектный кэш для всего, что кэш страниц отдать не может.
4. И только потом думать о дополнительных PHP workers или памяти.

Сторона кэша страниц и то, как слои сочетаются между собой, разобраны в статье скорость и кэширование WordPress.

Плагины#

Есть несколько способов получить drop-in, который общается с Valkey. Все они говорят на протоколе Redis, поэтому подключаются к Valkey без изменений.

• Redis Object Cache (бесплатный, автор Till Krüss) - самый распространённый. Он устанавливает object-cache.php, показывает в админке состояние и статистику попаданий и настраивается константами WP_REDIS_*. Он умеет работать через расширение phpredis, Relay или Predis - клиент на чистом PHP, поставляемый в комплекте, - так что работает даже там, где нельзя устанавливать расширения PHP.
• Object Cache Pro - коммерческая версия от того же автора с более эффективной сериализацией и сжатием, более экономной очисткой групп и поддержкой. Ориентирована на крупные магазины и агентства.
• W3 Total Cache и LiteSpeed Cache включают настройки объектного кэша наряду с кэшированием страниц. Разумный вариант, если вы уже используете один из них; избегайте одновременной работы двух drop-in объектного кэша - object-cache.php бывает только один.

В этой статье используется Redis Object Cache, потому что он бесплатный, распространённый и хорошо документирован.

Настройка шаг за шагом#

1. Проверьте, что WordPress может достучаться до Valkey. С любой машины с клиентом выполните valkey-cli -h <host> -p <port> --askpass, а затем PING - ответ должен быть PONG. Если WordPress работает на одном сервере, а Valkey на другом, каждое чтение кэша - это сетевой вызов, поэтому они должны находиться в одной локации. В RE:NODE и веб-хостинг, и Valkey работают в Германии, а тариф Valkey выдаётся с хостом, портом и сгенерированным паролем.
2. Проверьте наличие расширения phpredis. Файл с содержимым <?php phpinfo(); в корне сайта, открытый один раз и затем удалённый, показывает раздел redis, если расширение есть. Если его нет, плагин переключится на Predis - медленнее, но работает.
3. Добавьте константы в `wp-config.php` выше строки That's all, stop editing!:

define( 'WP_REDIS_HOST', '203.0.113.20' );define( 'WP_REDIS_PORT', 6380 );define( 'WP_REDIS_PASSWORD', 'the-generated-password' );define( 'WP_REDIS_DATABASE', 0 );define( 'WP_REDIS_PREFIX', 'shop_example_com:' );define( 'WP_REDIS_TIMEOUT', 1 );define( 'WP_REDIS_READ_TIMEOUT', 1 );define( 'WP_REDIS_MAXTTL', 86400 );

1. Установите и активируйте Redis Object Cache через Plugins, затем Add New.
2. Включите его в Settings, затем Redis, кнопкой Enable Object Cache. Это копирует drop-in в wp-content/object-cache.php. В WP-CLI то же самое делает wp redis enable, а wp redis status сообщает о состоянии подключения.
3. Откройте несколько страниц и проверьте экран состояния: там должно быть Connected, а число попаданий должно расти. Query Monitor при повторной загрузке той же страницы админки должен показывать гораздо меньше запросов к базе.

Константы, в которых стоит разобраться:

• `WP_REDIS_PREFIX` на практике обязательна. Два сайта на WordPress, направленные на один Valkey без разных префиксов, делят кэш опций и отдают настройки друг друга - одна из самых запутанных ошибок, какую только можно устроить. Используйте домен.
• `WP_REDIS_MAXTTL` ограничивает срок жизни каждого ключа. Некоторые плагины сохраняют записи кэша без срока жизни; без ограничения они живут, пока их не вытеснят. Сутки - разумный потолок.
• `WP_REDIS_TIMEOUT` и `WP_REDIS_READ_TIMEOUT` задаются в секундах. Держите их короткими: если Valkey недоступен, каждая страница ждёт таймаута, прежде чем переключиться на базу.
• `WP_REDIS_PASSWORD` принимает массив [ 'username', 'password' ], если вы используете пользователя ACL, а не пользователя по умолчанию.
• `WP_REDIS_DISABLED` со значением true обходит кэш, не удаляя drop-in, - это аварийный выключатель.

Не держите пароль в системе контроля версий, если wp-config.php лежит в репозитории. Остальное содержимое wp-config.php описано в статье ручная установка WordPress.

Расчёт размера Valkey для WordPress#

Размер объектного кэша - это примерно набор объектов, к которым ваш сайт регулярно обращается: опции (включая автозагружаемые), записи, метаданные, термины, пользователи, transients и всё, что добавляют плагины. Для большинства сайтов это на удивление немного.

Измеряйте, а не гадайте: после суток обычного трафика INFO memory показывает used_memory_human, и то же число показывает экран состояния плагина.

Правильная политика вытеснения для Valkey, используемого только как объектный кэш, - allkeys-lru или allkeys-lfu: когда память заполняется, наименее полезные записи отбрасываются, и WordPress восстанавливает их из базы. С noeviction заполненный кэш приводит к отказам записи, и плагин сообщает об ошибках. Если тот же Valkey держит ещё и сессии или очереди другого приложения, этот конфликт - повод дать WordPress собственный экземпляр; компромисс объясняется в статье память и политики вытеснения Valkey.

Для объектного кэша сохранение данных важно меньше, чем для чего-либо ещё в Valkey, потому что всё в нём можно восстановить. И всё же оно помогает: после перезапуска сохранённый кэш сразу прогрет, а не заставляет каждую страницу разом платить за холодный старт.

Transients, автозагружаемые опции и устаревшие данные#

Два механизма WordPress меняют поведение, когда установлен постоянный объектный кэш, и оба объясняют ошибки, на которые жалуются люди.

Transients уходят из базы данных. Без объектного кэша set_transient() пишет в таблицу wp_options. С ним transients живут только в Valkey и в базу вообще не попадают. Обычно это улучшение - просроченные transients больше не копятся в wp_options, - но это значит, что плагин, хранящий в transient что-то важное, потеряет это при очистке кэша или вытеснении ключа. Transients задуманы как одноразовые; плагин, использующий их как хранилище, содержит ошибку, которую объектный кэш просто обнаруживает.

Опции кэшируются, включая `alloptions`. WordPress загружает все автозагружаемые опции разом и кэширует их одной записью. Если изменить опцию напрямую в базе - через phpMyAdmin, скрипт миграции или search-replace, - WordPress продолжит отдавать закэшированное значение, пока кэш не очистят. Это классическое «я поменял адрес сайта в базе, и ничего не произошло». После любой прямой правки базы очищайте кэш на экране плагина или командой wp cache flush.

Родственная ловушка - огромная запись alloptions. Некоторые плагины автозагружают сотни килобайт опций; тогда каждый запрос тянет этот блоб из Valkey, и расход памяти на запрос растёт. Размер показывают Query Monitor и wp option list --autoload=on --format=total_bytes. Сокращение автозагружаемых опций помогает и с объектным кэшем, и без него.

Тестовые копии, переезды и multisite

В трёх ситуациях кэш становится источником путаницы, а не скорости, и для каждой есть простое правило.

Тестовые копии. Клонируйте сайт на staging, скопируйте вместе с ним wp-config.php - и тестовый сайт теперь читает и пишет записи кэша продакшена: тот же хост, тот же префикс. Правки со staging появляются на продакшене, пока ключи не истекут, а опции продакшена - на staging. Дайте каждой копии собственный WP_REDIS_PREFIX или собственный Valkey до первой загрузки страницы. Правильно заданный WP_ENVIRONMENT_TYPE сам по себе ключи кэша не меняет.

Переезды. Перенос сайта на новый хостинг с заменой URL через search-replace - это прямая правка базы, поэтому очистите объектный кэш на новом хостинге после импорта и до тестирования. Остальные шаги переезда описаны в статье перенос WordPress на новый хостинг. Если вы переносите базу, но оставляете тот же Valkey, очистите и его.

Multisite. Сеть использует один drop-in и один префикс; плагин разделяет подсайты по id блога и считает некоторые группы, например пользователей и метаданные сайтов, глобальными для всей сети. Не пытайтесь дать каждому подсайту свой префикс, правя константы для каждого сайта. Рассчитывайте кэш на всю сеть и учитывайте, что очистка затронет все подсайты сразу.

Deploy. Большинству deploy кода очистка вообще не нужна. Она нужна deploy, который меняет то, как плагин хранит закэшированные данные - новую структуру под тем же ключом, - и обычно это берёт на себя процедура обновления самого плагина. Когда deploy приводит к ошибкам, которые исчезают после очистки, произошло именно это.

Устранение неполадок#

«Error establishing a Redis connection» или состояние Not Connected. Проверьте хост, порт и пароль с сервера WordPress через valkey-cli. Отказ в подключении означает неверный адрес или порт; WRONGPASS или NOAUTH - неверный пароль.

Сайт показывает настройки или название другого сайта. Два сайта делят префикс и базу. Дайте каждому уникальный WP_REDIS_PREFIX, затем очистите кэш.

Изменения, сделанные в базе, не появляются. Закэшированные опции. Очистите объектный кэш.

После включения страницы стали медленнее. Обычно дело в задержке: если каждый вызов кэша идёт через медленную сеть, сотни вызовов на страницу складываются. Проверьте, что WordPress и Valkey находятся рядом. Реже - Predis на сайте, делающем тысячи вызовов кэша на страницу, медленнее phpredis.

`object-cache.php` постоянно исчезает или принадлежит другому плагину. Два плагина кэша соревнуются за drop-in. Выберите один и отключите функцию объектного кэша в другом.

Сайт полностью ломается после сбоя Valkey. Так быть не должно - плагин переключается на базу данных. Если это всё же происходит, задайте WP_REDIS_DISABLED равным true, чтобы поднять сайт, и проверьте таймауты.

FAQ#

Нужен ли объектный кэш, если уже есть кэш страниц?

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

Совместим ли Redis Object Cache с Valkey?

Он говорит на протоколе Redis через phpredis, Relay или Predis, а Valkey реализует этот протокол, так что плагин подключается с теми же настройками хоста, порта и пароля. Направьте константы на сервер Valkey и включите плагин как обычно.

Могут ли несколько сайтов на WordPress делить один экземпляр Valkey?

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

Потеряются ли данные при очистке объектного кэша?

Нет, если плагины ведут себя правильно: всё в объектном кэше восстанавливается из базы данных. Ожидайте более медленную минуту, пока кэш прогревается. Исключение - плагин, который хранит важные данные только в transients, а это ошибка плагина.

Помогает ли объектный кэш оформлению заказа в WooCommerce?

Да - страницы корзины, оформления заказа и аккаунта нельзя закэшировать как страницы, поэтому они при каждой загрузке запускают PHP и обращаются к базе. Кэширование товаров, опций и данных, связанных с сессией, сокращает эту работу. Обращения к платёжным шлюзам, которые являются внешними, он не ускоряет.