Высоконагруженные сайты на WordPress часто страдают от чрезм��рной нагрузки на базу данных MySQL, вызванной многократным выполнением запросов, динамическим поиском метаданных записей и записью сессий WooCommerce без кэширования. Перенос сложных SQL-запросов в объектный кэш Redis в оперативной памяти с использованием постоянных доменных сокетов Unix и тонко настроенных политик вытеснения позволяет снизить задержку выполнения запросов к базе данных со 0 мс до менее чем мс на запрос.
1. Доменные сокеты Unix против задержки TCP-петли
Большинство стандартных настроек Redis используют подключение через локальный сетевой интерфейс обратной связи (127.0.0.1:6379). Хотя это функционально, TCP-петля создает накладные расходы на стек TCP ядра, инкапсуляцию пакетов и переключение контекста.
Подключение WordPress к Redis через доменный сокет Unix (/var/run/redis/redis-server.sock) полностью обходит сетевую маршрутизацию, используя прямые буферы общей памяти для снижения задержки на 25–30%:
// wp-config.php
define('WP_REDIS_SCHEME', 'unix');
define('WP_REDIS_PATH', '/var/run/redis/redis-server.sock');
define('WP_REDIS_DATABASE', 0);
define('WP_REDIS_TIMEOUT', 1.0);
define('WP_REDIS_READ_TIMEOUT', 1.0);
2. Определение размера памяти & Стратегия вытеснения: allkeys-lru
Когда Redis достигает установленного лимита памяти (maxmemory), его политика вытеснения определяет, как будут приниматься новые ключи. Политика по умолчанию (noeviction) выдает критические ошибки при заполнении памяти, что приводит к сбоям при записи в WordPress.
Для высоконагруженного хостинга WordPress настройка allkeys-lru гарантирует, что ключи, которые использовались реже всего, будут безопасно вытеснены, чтобы освободить место для результатов активных запросов к базе данных без простоев:
# /etc/redis/redis.conf
maxmemory 512mb
maxmemory-policy allkeys-lru
save "" # Disable unnecessary disk persistence on pure cache instances
Почему стоит отключить сохранение на диск (RDB/AOF) при использовании только кэша?
Когда Redis используется исключительно как объектный кэш вместе с постоянной базой данных MySQL, отключение фоновых снимков (save "") устраняет тяжелые операции ввода-вывода на диск (fork), освобождая IOPS сервера для операций с базой данных.
3. Непостоянные группы & Оптимизация WooCommerce
Определенные группы данных WordPress (такие как временные токены, сессии корзины и счетчики ограничения частоты запросов) не должны храниться в памяти бесконечно. Определение непостоянных групп предотвращает раздувание кэша и устраняет устаревшие данные об инвентаре:
// wp-config.php
define('WP_REDIS_IGNORED_GROUPS', [
'counts',
'plugins',
'themes',
'wc_session_id'
]);
4. Показатели производительности
Влияние объектного кэширования Redis на пропускную способность запросов WordPress приведено ниже:
| Метрика нагрузки | Стандартный стек MySQL | Стек WinWinHost Redis | Прирост производительности |
|---|---|---|---|
| Запросов к БД / страница | 75 – 140 запросов | 2 – 6 запросов | сокращение запросов на 95% |
| Средняя задержка запроса | мс – мс | < 0 мс | поиск в раз быстрее |
| Использование CPU сервера | 65% – 90% | 12% – 25% | в раза выше параллелизм |
5. Резюме
Внедрение объектного кэширования Redis через доменные сокеты Unix с политикой вытеснения allkeys-lru является наиболее эффективной оптимизацией для масштабирования высоконагруженных магазинов на WordPress. Управляемые тарифы WordPress от WinWinHost поставляются с предварительно настроенными выделенными NVMe-экземплярами Redis.