Redis object cache для WordPress на VPS

Що робить об’єктний кеш Redis для WordPress

Об’єктний кеш Redis для WordPress зберігає результати запитів до бази даних у пам’яті. Наступний запит читає їх із Redis, а не надсилає повторний запит до MySQL. WordPress уже має вбудований об’єктний кеш, WP_Object_Cache, але він працює в пам’яті PHP і видаляється після завершення запиту. Drop-in-файл замінює його кешем, який взаємодіє з Redis. Тому кеш зберігається між запитами.

Об’єктне кешування — це не кешування сторінок. Ця різниця визначає, чи буде цей посібник для вас корисним. Кеш сторінок зберігає готовий HTML для URL і повторно віддає його без запуску PHP. Це швидше за будь-яку операцію Redis і працює для неавторизованих відвідувачів. Коли користувач входить в обліковий запис, додає товар у кошик або відкриває адмінпанель, кеш сторінок більше не використовується, і WordPress обробляє весь запит: bootstrap, плагіни та запити до бази даних. Об’єктний кеш здешевлює саме таку обробку. Це інструмент для трафіку, який не може обробити кеш сторінок: авторизованих сеансів, кошиків, оформлення замовлення та wp-admin. У магазині на WooCommerce це більша частина ресурсоємного трафіку.

Ці два типи кешування доповнюють один одного. На завантаженому сайті потрібні обидва. Чітко визначте, яку проблему ви вирішуєте. Сайт-візитка з неавторизованими читачами отримує майже всю швидкодію від кешу сторінок. Додавання Redis майже нічого не змінить.

Перед початком врахуйте одне обмеження. Об’єктний кеш не прискорює повільний запит. Він усуває лише повторне виконання запиту, який уже було виконано. Перший запит після промаху кешу оплачується повністю. Тому плагін, який виконує неіндексований запит, усе одно виконає його один раз протягом терміну життя кешу.

Що потрібно спочатку

• Linux VPS із shell і sudo. Панель керування не потрібна.
• WordPress, який працює через PHP-FPM, наприклад у LAMP-стеку на Ubuntu 24.04.
• WP-CLI на сервері. Для кожного кроку є еквівалент у панелі адміністратора, але варіант із shell швидший.
• Redis на тому самому комп’ютері, що й PHP. Саме низька затримка є головною перевагою, а мережевий перехід її нівелює.

Наведені нижче команди призначені для Ubuntu 24.04 із PHP 8.3 і вебкористувачем www-data. Змініть версію PHP і користувача відповідно до конфігурації вашого сервера. Виконуйте команди wp з каталогу WordPress, у якому міститься wp-config.php.

Встановлення Redis і розширення PHP

sudo apt update
sudo apt install -y redis-server php-redis
sudo systemctl enable --now redis-server
redis-cli ping

redis-cli ping має повернути PONG. Якщо виведено Could not connect to Redis at 127.0.0.1:6379: Connection refused, сервер не запущений, тому перед продовженням перегляньте systemctl status redis-server.

php-redis — це PhpRedis, розширення C з PECL. Воно швидше за Predis, написаний на чистому PHP, і плагін автоматично використовує його, якщо розширення доступне. PHP-FPM завантажує розширення під час запуску, тому нове розширення стане доступним лише після перезапуску пулу.

sudo systemctl restart php8.3-fpm
php -m | grep redis

Зверніть увагу на останню перевірку: php -m показує модулі PHP командного рядка, а FPM може завантажувати інший набір модулів. Вирішальною є перевірка власної діагностики плагіна нижче.

Станом на August 2026 Ubuntu 24.04 містить Redis 7.0.15, чого достатньо для кешу об’єктів. Якщо потрібен актуальніший випуск, Redis має власний APT-репозиторій.

sudo apt install -y lsb-release curl gpg
curl -fsSL https://packages.redis.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg
sudo chmod 644 /usr/share/keyrings/redis-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/redis.list
sudo apt update
sudo apt install -y redis

Якщо ваш дистрибутив постачає Valkey — форк, створений після зміни ліцензії у 2024 році, — він використовує той самий протокол, тому все наведене нижче застосовується без змін.

Прив’яжіть Redis так, щоб інші не могли до нього підключитися

За замовчуванням Redis не має пароля. Будь-хто, хто може відкрити з’єднання з портом 6379, може прочитати всі кешовані значення та виконати FLUSHALL. Екземпляри, доступні з інтернету, сканери знаходять протягом кількох годин, тому мережеві параметри потрібно налаштувати до оптимізації.

Відкрийте /etc/redis/redis.conf і перевірте, чи містить він такі рядки:

bind 127.0.0.1 -::1
protected-mode yes

Потім перевірте, що фактично прослуховується, оскільки файл конфігурації лише описує налаштування, а ss показує реальний стан.

sudo ss -lntp | grep 6379

Потрібно, щоб результатом було 127.0.0.1:6379. 0.0.0.0:6379 означає, що Redis відповідає на публічному інтерфейсі: виправте рядок bind і перезапустіть Redis.

Якщо PHP і Redis працюють на одному сервері, Unix-сокет кращий за TCP через loopback. У цьому випадку з’єднання не проходить через стек TCP, а доступ визначається правами на файл, а не правилом firewall, яке пізніше можна випадково змінити.

unixsocket /run/redis/redis-server.sock
unixsocketperm 770

Власником сокета є користувач і група redis, тому користувача вебсервера потрібно додати до цієї групи.

sudo systemctl restart redis-server
sudo usermod -aG redis www-data
sudo systemctl restart php8.3-fpm
redis-cli -s /run/redis/redis-server.sock ping

Ця команда також має вивести PONG. Could not connect to Redis at /run/redis/redis-server.sock: Permission denied означає, що група не застосувалася. Перевірте id www-data і пам’ятайте: запущений PHP-FPM зберігає групи, які мав під час запуску, тому перезапуск є в цьому списку. Не вимикайте TCP, доки не переконаєтеся, що сокет працює, інакше помилка в конфігурації одночасно заблокує обидва способи підключення.

Скільки пам’яті виділити Redis?

Визначте це значення для свого сервера. Redis без maxmemory зростає, доки ядру не бракує пам’яті й OOM killer не завершує один із процесів, зазвичай найбільший. На сервері WordPress це часто MySQL. journalctl -k | grep -i "out of memory" показує таке завершення вже після події, а до цього моменту сайт уже недоступний.

Візьміть загальний обсяг RAM і відніміть необхідні ресурси. MySQL або MariaDB резервує innodb_buffer_pool_size, а також буфери для кожного підключення. PHP-FPM споживає pm.max_children, помножене на фактичний resident size одного worker. На сайті з великою кількістю плагінів це зазвичай 64 MB–128 MB. Ядру та web server потрібно кілька сотень мегабайтів. Залишок — це ваша верхня межа, частину якої можна виділити Redis.

Тепер вимірюйте, а не вгадуйте. Після доби реального трафіку:

redis-cli info memory | grep -E 'used_memory_human|maxmemory_human|maxmemory_policy'
redis-cli dbsize

Якщо used_memory_human значно нижче за встановлену межу, зменште межу й поверніть RAM MySQL, який використає її ефективніше. Якщо значення досягає межі, а evicted_keys протягом дня зростає, збільште межу. Задайте значення в /etc/redis/redis.conf.

maxmemory 256mb
maxmemory-policy allkeys-lru

redis-cli config set maxmemory 256mb застосовується негайно й втрачається під час наступного перезапуску. Це та сама проблема, що й із простим sysctl -w. Відредагуйте файл, потім виконайте sudo systemctl restart redis-server і знову прочитайте значення. Додаткове обмеження варто встановити: параметр MemoryMax для unit systemd не дасть неправильно налаштованому Redis вивести сервер з ладу. Встановіть його вище за maxmemory, але не рівним цьому значенню, оскільки обмеження cgroup завершує процес, а не видаляє ключ. Якщо Redis працює в контейнері поруч із WordPress, те саме значення потрібно вказати в обмеженнях пам’яті у вашому Compose-файлі, а вибір запускати базу даних у Docker чи на хості визначається тією самою логікою.

Свідомо виберіть політику виселення

Нова інсталяція Redis за замовчуванням використовує noeviction. Перевірте свою конфігурацію:

redis-cli config get maxmemory-policy

За політики noeviction повністю заповнений екземпляр припиняє приймати операції запису й повертає таке повідомлення:

(error) OOM command not allowed when used memory > 'maxmemory'.

Цей єдиний рядок описує найгірший сценарій відмови в цьому посібнику, оскільки сайт не стає недоступним. Він працює повільніше. Кожна операція запису в кеш завершується помилкою, тому WordPress знову звертається до бази даних по значення, потім на наступному запиті знову намагається зберегти його, і знову отримує помилку. Тепер сайт виконує всю початкову роботу з базою даних і додатково здійснює обмін із Redis для кожного ключа. В адміністративній панелі WordPress немає повідомлення про цю проблему. Цей рядок з’являється в журналі помилок PHP, тому після підключення кешу, якщо сайт став повільнішим, виконайте пошук OOM command not allowed за допомогою grep.

allkeys-lru — правильний варіант за замовчуванням для цього випадку. Коли пам’ять закінчується, Redis видаляє ключ, до якого найдовше не зверталися. Це саме те, що потрібно кешу об’єктів, оскільки кожне його значення є копією даних, які все ще зберігаються в MySQL. Втрата ключа коштує одного запиту. Відмова в операції запису коштує всіх запитів у кожному запиті, доки хтось не виявить проблему.

Для цього завдання уникайте політик volatile-*. Вони враховують лише ключі, для яких задано термін дії, а Redis зазначає, що без таких ключів вони працюють як noeviction. WordPress зберігає більшість записів кешу об’єктів без TTL, тому volatile-lru у кеші об’єктів може заповнитися й почати відмовляти в операціях запису. allkeys-lfu — прийнятна альтернатива, якщо ваш трафік дуже часто звертається до невеликого набору ключів, оскільки ця політика видаляє ключі за частотою використання, а не за давністю звернення. Виберіть політику свідомо й запишіть причину вибору.

Persistence: вимкніть, якщо немає конкретної причини залишати її ввімкненою

Пакетний redis.conf вмикає RDB-знімки рядками на кшталт save 900 1 і залишає append-only file вимкненим. Для звичайного object cache знімки не дають переваг. Дані за визначенням можна відновити, а cache, відновлений із файлу двадцятихвилинної давності, містить застарілі значення, яким WordPress довірятиме.

Знімки також споживають ресурси. BGSAVE створює копію процесу, а copy-on-write може різко збільшити використання пам’яті, поки дочірній процес записує дані. На невеликому VPS це видно в журналі Redis:

Can't save in background: fork: Cannot allocate memory

Під час запуску також часто з’являється таке попередження. Redis повідомляє, що пізніше операція fork, імовірно, завершиться помилкою:

WARNING overcommit_memory is set to 0! Background save may fail under low memory condition.

Щоб вимкнути знімки, задайте порожній розклад збереження у /etc/redis/redis.conf, перезапустіть сервіс і переконайтеся, що значення знову стало порожнім.

save ""

sudo systemctl restart redis-server
redis-cli config get save

Залишайте persistence увімкненою лише тоді, коли той самий екземпляр зберігає дані, які неможливо відновити, наприклад чергу завдань або лічильники rate limit. У такому разі розділіть їх. Для cache потрібне видалення ключів, а для довговічних даних — збереження ключів. maxmemory і eviction застосовуються до всього екземпляра, а не до окремого індексу бази даних. Два екземпляри на двох сокетах — оптимальне рішення.

Встановіть плагін і зрозумійте призначення drop-in

wp plugin install redis-cache --activate
wp redis enable
wp redis status

wp redis enable виводить Object cache enabled. у разі успіху. Фактично команда копіює wp-content/plugins/redis-cache/includes/object-cache.php у wp-content/object-cache.php. Ця копія і є drop-in, а саме drop-in виконує основну роботу. WordPress завантажує wp-content/object-cache.php на дуже ранньому етапі, ще до виконання коду будь-якого плагіна. Завдяки цьому кеш доступний протягом усього запиту. Активний плагін без drop-in не кешує нічого.

Повідомлення про помилки показують, яка саме частина не спрацювала. Object cache could not be enabled. означає, що копіювання не вдалося, тому wp-content недоступний для запису користувачу, від імені якого працює WP-CLI. A foreign object cache drop-in was found. означає, що інший плагін кешування вже використовує це ім’я файлу. Виправленням є wp redis update-dropin. Повідомлення, що закінчується на Redis server is unreachable:, а потім супроводжується помилкою клієнта, означає неправильні параметри підключення. Поверніться до redis-cli ping.

Якщо копіювання не вдалося через права доступу, розмістіть файл вручну та передайте його у власність користувачу вебсервера.

cp wp-content/plugins/redis-cache/includes/object-cache.php wp-content/object-cache.php
sudo chown www-data:www-data wp-content/object-cache.php

Видалення плагіна не видаляє drop-in. Спочатку виконайте wp redis disable. Команда виводить Object cache disabled. і видаляє файл. Якщо видалити каталог плагіна, а drop-in залишити, сайт продовжить працювати зі старим кодом кешування, який більше нікому оновлювати.

Параметри підключення у wp-config.php

Додайте їх перед рядком /* That's all, stop editing! */, оскільки константи, визначені після нього, застосовуються надто пізно.

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'shop_prod:' );

Для Unix-сокета задайте схему та шлях. Параметри хоста й порту буде проігноровано.

define( 'WP_REDIS_SCHEME', 'unix' );
define( 'WP_REDIS_PATH', '/run/redis/redis-server.sock' );
define( 'WP_REDIS_PREFIX', 'shop_prod:' );

WP_REDIS_MAXTTL примусово встановлює термін дії для кожного ключа в секундах. Він не потрібен разом із allkeys-lru і корисний, якщо потрібно жорстко обмежити максимальний строк зберігання застарілого кешованого значення.

Один Redis для кількох сайтів: префікси та бази даних

Redis за замовчуванням надає шістнадцять нумерованих баз даних і окремий плоский простір ключів у кожній із них. Дві інсталяції WordPress, підключені до бази даних 0 без префікса, записують однакові імена ключів в один простір. Через це один сайт може читати параметри іншого та використовувати їх у відповідях. Призначте кожному сайту власний префікс.

define( 'WP_REDIS_PREFIX', 'shopA_prod:' );
define( 'WP_REDIS_DATABASE', 1 );

Префікс розділяє імена ключів. Індекс бази даних розділяє простори ключів. Це важливо під час очищення: очищення одного індексу не впливає на інші. У документації плагіна також описано WP_REDIS_SELECTIVE_FLUSH. Ця операція видаляє лише ключі, що відповідають вашому префіксу, а не всю базу даних, але для цього потрібно виконати пошук таких ключів.

Префікси та індекси не розділяють обсяг пам’яті. maxmemory і політика видалення застосовуються до всього екземпляра. Тому активний сайт може витіснити ключі тихого сайту, і жоден із них не повідомить про це. Сайти, які не повинні впливати один на одного, потребують окремих екземплярів Redis. Кожен екземпляр має використовувати власний сокет і мати власний ліміт.

Не допускайте потрапляння staging у кеш production

Staging-сайт зазвичай є копією файлів і бази даних production. Це означає, що він є копією wp-config.php з тим самим префіксом і тим самим індексом бази даних. Якщо підключити його до того самого Redis, він записуватиме ключі production зі значеннями staging. Тестова ціна або змінений параметр після цього з’явиться на робочому сайті без деплою та без сліду в журналі.

Задайте окремий salt для кожного середовища вручну. У wp-config.php staging-сайту:

define( 'WP_REDIS_PREFIX', 'shop_staging:' );
define( 'WP_REDIS_DATABASE', 5 );

Ще краще — надати staging окремий екземпляр Redis або взагалі не використовувати object cache. define( 'WP_REDIS_DISABLED', true ); вимикає кеш під час виконання та залишає drop-in на місці. Це також найшвидший спосіб перевірити, чи пов’язана помилка з кешем.

У старіших посібниках для цього використовують WP_CACHE_KEY_SALT. У readme плагіна цю константу позначено як застарілу та замінену на WP_REDIS_PREFIX, тому використовуйте нову назву.

Перевіряйте, а не довіряйте

Почніть із власної діагностики плагіна.

wp redis status

Найважливіший рядок — Drop-in. Drop-in: Valid означає, що WordPress завантажує файл цього плагіна. Drop-in: Not installed означає, що копіювання не відбулося і сайт не має постійного кешу, незалежно від того, наскільки успішним виглядає екран адміністратора. Status показує стан підключення, а Client називає використовуване розширення. Саме тут потрібно підтвердити використання PhpRedis, а не Predis.

Потім безпосередньо запитайте ядро WordPress, оскільки йому байдуже, що вважає плагін.

wp eval 'var_dump( wp_using_ext_object_cache() );'

bool(true) означає, що ядро працює із зовнішнім кешем об’єктів.

Потім переконайтеся, що ключі надходять із налаштованим вами префіксом.

redis-cli -n 0 dbsize
redis-cli -n 0 --scan --pattern 'shop_prod:*' | head

Зростання dbsize під час переходів сайтом є підтвердженням. Нульова кількість ключів за наявності коректного drop-in означає, що підключення непомітно завершується помилкою або префікс не відповідає тому, який ви очікуєте.

Нарешті, перевірте показники, які Redis збирає для вас.

redis-cli info stats | grep -E 'keyspace_hits|keyspace_misses|evicted_keys|expired_keys'

Коефіцієнт влучань — keyspace_hits / (keyspace_hits + keyspace_misses), і документація Redis наводить цю формулу. Інтерпретуйте його з урахуванням двох застережень. Лічильники охоплюють увесь екземпляр від моменту останнього перезапуску, тому вони змішують дані всіх сайтів і застосунків, які ним спільно користуються. Крім того, коефіцієнт одразу після очищення кешу або перезапуску нічого не показує, оскільки кеш ще заповнюється. Дайте йому попрацювати протягом звичайного дня з мережевим трафіком.

Не порівнюйте своє значення з коефіцієнтом влучань або кількістю запитів, опублікованими хостинг-провайдером. Вони описують його сайти та набір плагінів. Важливе значення — ваше власне, виміряне до та після на сторінці, яку кеш сторінок не може обслуговувати.

curl -o /dev/null -s -w '%{time_starttransfer}\n' -b cookies.txt https://example.com/my-account/

Виконайте це з jar-файлом cookie для автентифікованого користувача кілька разів: спочатку з вимкненим кешем (WP_REDIS_DISABLED), а потім з увімкненим. Ця різниця і є вашим результатом.

Коли Redis уповільнює WordPress

Повністю заповнений інстанс із неправильною політикою — головна причина, описана вище: OOM command not allowed when used memory > 'maxmemory'. у журналі, а сайт платить і за базу даних, і за кеш.

Redis на іншому хості — друга причина. WordPress виконує сотні викликів кешу об’єктів під час одного запиту. Якщо запит містить 500 викликів, а кожен обмін даними займає 1 ms, це дає пів секунди очікування, якого не було б під час роботи через локальний сокет. Тримайте Redis на тому самому сервері або в приватній мережі з латентністю меншою за 1 ms.

Величезна таблиця опцій, завантажуваних автоматично, — третя причина. На старих сайтах це трапляється часто. WordPress кешує всі такі опції одним ключем, тому мегабайт даних передається через з’єднання під час кожного запиту. Виміряйте її розмір:

wp db query "SELECT ROUND(SUM(LENGTH(option_value))/1024) AS kb FROM wp_options WHERE autoload IN ('yes','on','auto','auto-on');"

У WordPress 6.6 додано нові значення автозавантаження, тому старий запит, який враховує лише 'yes', занижує результат у сучасній інсталяції. Усе, що перевищує мегабайт, потрібно виправляти в таблиці опцій, а не в Redis.

Після перезапуску весь кеш очищується, тому протягом хвилин після systemctl restart redis-server усі запити є промахами кешу й спричиняють звернення до бази даних. Перезапускайте сервіс, коли трафік низький. Кеш об’єктів також не перешкоджає запуску wp-cron.php під час завантаження сторінок відвідувачами. Це окреме джерело повільних запитів: скористайтеся перенесенням WP-Cron до звичайного завдання system cron, поки ви вже працюєте над цим.

Прибирання

Після розгортання, яке змінює параметри або код теми, очистьте кеш за допомогою wp cache flush. Виконайте wp redis update-dropin після оновлення плагіна, якщо drop-in не оновився автоматично. Drop-in від старої версії плагіна, що використовується з новішою версією, часто спричиняє непередбачувану поведінку. Спостерігайте за робочим сервером за допомогою redis-cli --stat. Команда виводить один рядок на секунду. redis-cli monitor виводить кожну команду та створює помітне навантаження на CPU на завантаженому екземплярі. Тому використовуйте її кілька секунд під час відтворення проблеми, а потім зупиніть.

Є ще одне важливе число: redis-cli info clients показує connected_clients. PHP-FPM підтримує одне з’єднання для кожного worker, тому це значення має відповідати вашому pm.max_children, а не перевищувати його на порядок. Якщо це не так, певний компонент відкриває з’єднання й не закриває їх.

FAQ

Чи потрібен мені page cache, якщо я використовую Redis object cache?

Так, для анонімного трафіку. Page cache віддає збережений HTML без запуску PHP, що завжди дешевше, ніж запускати WordPress із прогрітим object cache. Object cache обробляє запити, які page cache має пропускати: авторизованих користувачів, кошики, оформлення замовлення та wp-admin. Для магазину або membership-сайту варто використовувати обидва механізми. На сайті, де відвідувачі ніколи не авторизуються, page cache виконує майже всю роботу.

Скільки пам’яті виділити Redis для WordPress?

Розраховуйте обсяг для власного сервера, а не копіюйте готове значення. Візьміть загальний обсяг RAM, відніміть buffer pool MySQL і буфери окремих з’єднань, відніміть pm.max_children, помножене на resident size одного worker PHP-FPM, а також кілька сотень мегабайт для ядра та веб-сервера. Виділіть Redis частину залишку, потім через день роботи під навантаженням перевірте used_memory_human у redis-cli info memory і скоригуйте значення. Один сайт WordPress зазвичай використовує десятки мегабайт, тому 256 MB maxmemory — це значний початковий обсяг для сервера з 4 GB RAM.

Чому сайт став повільнішим після ввімкнення Redis object cache?

Зазвичай причина — переповнений інстанс, який використовує політику noeviction. Redis відхиляє нові операції запису та повертає OOM command not allowed when used memory > 'maxmemory'., тому WordPress звертається до бази даних за кожним значенням і додатково витрачає час на непотрібний round trip до Redis. Перевірте redis-cli config get maxmemory-policy, задайте allkeys-lru і переконайтеся, що maxmemory не має надто малого значення. Інші поширені причини — Redis-сервер на віддаленому хості, де сотні round trip для одного запиту сумарно створюють значну затримку, і autoloaded options розміром у кілька мегабайт, які передаються через з’єднання під час кожного запиту.

Чи можуть кілька сайтів WordPress спільно використовувати один Redis-сервер?

Так, якщо налаштувати це правильно. Задайте для кожного сайту унікальний WP_REDIS_PREFIX, щоб назви ключів не конфліктували, і окремий індекс WP_REDIS_DATABASE, щоб очищення одного сайту не видаляло дані іншого. Спільним залишається обсяг пам’яті: maxmemory та eviction застосовуються до всього інстансу, тому активний сайт може видаляти ключі менш активного сайту. Для сайтів, які не повинні впливати один на одного, потрібні окремі інстанси Redis із власними обмеженнями.

Чи безпечно видаляти wp-content/object-cache.php?

Так. Це drop-in, а не частина ядра WordPress. Після його видалення WordPress повертається до вбудованого кешу в межах окремого запиту. Сайт продовжує працювати, але виконує більше запитів до бази даних. Перевагу слід надати wp redis disable, яка коректно видаляє файл і повідомляє Object cache disabled.. Ручне видалення — правильний аварійний крок, якщо Redis не працює або працює некоректно і ви не можете відкрити адміністративну панель.