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 для systemd unit не дасть неправильно налаштованому Redis вивести сервер із ладу. Установіть його вище за maxmemory, а не рівним йому, оскільки обмеження cgroup завершує процес, а не видаляє ключ. Якщо Redis працює в контейнері поруч із WordPress, те саме значення потрібно вказати в обмеженнях пам’яті у вашому Compose-файлі, а вибір запускати базу даних у Docker чи на host ґрунтується на тих самих міркуваннях.

Вибирайте політику витіснення свідомо

Нова інсталяція 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.

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

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

Збереження даних: вимикайте, якщо немає конкретної причини

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

Знімки також споживають ресурси. BGSAVE створює fork процесу, а механізм 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.

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

save ""

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

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

Встановіть плагін і зрозумійте призначення 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-сокета задайте схему та шлях. Параметри host і port у такому разі ігноруються.

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 наведено цю формулу. Інтерпретуйте його з урахуванням двох застережень. Лічильники охоплюють весь інстанс від моменту останнього перезапуску, тому в них змішані дані всіх сайтів і застосунків, які ним спільно користуються. Крім того, коефіцієнт одразу після очищення кешу або перезапуску нічого не показує, оскільки кеш ще наповнюється. Залиште систему працювати протягом звичайного дня з типовим мережевим трафіком.

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

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

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

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

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

Redis на іншому хості — друга проблема. WordPress виконує сотні викликів кешу об’єктів за один запит. Якщо запит містить 500 викликів, а кожен обмін даними займає 1 ms, це дає пів секунди очікування, якого не було б під час роботи через локальний сокет. Залишайте Redis на тому самому сервері або в приватній мережі з латентністю меншою за 1 ms. Наскільки робота на тому самому сервері виграє завдяки ядру, — окреме питання: планування з урахуванням кешу, додане в Linux 7.2, намагається розміщувати процеси з інтенсивним обміном даними, такі як PHP-FPM і Redis, на ядрах зі спільним кешем, а гостьова система VPS використовує цю перевагу меншою мірою, ніж bare metal.

Величезна таблиця параметрів із автозавантаженням — третя проблема, і на старих сайтах вона трапляється часто. 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', занижує результат у сучасній інсталяції. Якщо обсяг перевищує 1 megabyte, проблему потрібно виправляти в таблиці параметрів, а не в Redis.

Перезапуск очищає все, тому хвилини після systemctl restart redis-server — це суцільні промахи кешу та запити до бази даних. Перезапускайте сервіс, коли трафік низький. Кеш об’єктів також не перешкоджає виконанню wp-cron.php під час завантаження сторінок відвідувачами, а це окреме джерело повільних запитів: перенесіть WP-Cron до справжнього завдання системного 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, якщо я використовую object cache на Redis?

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

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

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

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

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

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

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

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

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