Руководство по настройке серверного кеширования: Nginx FastCGI Cache, Redis, Memcached. Кеширование страниц, запросов к базе данных и сессий. Как ускорить отклик сервера и снизить нагрузку.
Введение
Вы настроили браузерное кеширование через Cache-Control. Включили сжатие Gzip. Оптимизировали картинки. Но TTFB всё равно под 800 миллисекунд, а сервер пыхтит под нагрузкой. Значит, пришло время серверного кеширования. В отличие от браузерного кеша, который хранит файлы на стороне пользователя, серверный кеш хранит готовые страницы и результаты запросов прямо на сервере. Когда приходит запрос, сервер не генерирует страницу заново с нуля, а отдаёт готовую из кеша. Разница в скорости — в десятки и сотни раз. В этой статье разберём три уровня серверного кеширования: Nginx FastCGI Cache для готовых страниц, Redis и Memcached для запросов к базе данных, и кеширование сессий. С практическими настройками для российских VPS.
Nginx FastCGI Cache: кешируем целые страницы
FastCGI Cache — это встроенный в Nginx механизм кеширования ответов от PHP. Когда пользователь запрашивает страницу, Nginx проверяет, есть ли она в кеше. Если есть и не устарела — отдаёт мгновенно, даже не дёргая PHP. Если нет — передаёт запрос PHP-FPM, генерирует страницу и сохраняет в кеш для следующих запросов. Настройка состоит из трёх шагов. Первый: в конфиге Nginx (обычно /etc/nginx/nginx.conf) добавляем директиву fastcgi_cache_path с указанием пути к кешу, максимального размера и времени хранения. Второй: в конфиге сайта добавляем fastcgi_cache с именем зоны и fastcgi_cache_key с ключом кеширования (обычно схема, хост и URI запроса). Третий: настраиваем исключения — что НЕ кешировать. Админку, корзину, личный кабинет, страницы с POST-запросами, страницы с куками авторизации. Для этого используем директивы fastcgi_no_cache и fastcgi_cache_bypass. Важный нюанс: инвалидация кеша. При обновлении контента кеш нужно сбрасывать. Это можно сделать через плагин CMS (например, Nginx Helper для WordPress) или скриптом, который удаляет файлы кеша по URL обновлённой страницы. Без инвалидации пользователи будут видеть старую версию страницы, пока кеш не истечёт по времени.
Redis: кеширование запросов к базе данных
FastCGI Cache кеширует готовые страницы. Но для динамических сайтов, где контент персонализирован или часто меняется, кеширование целых страниц не всегда подходит. Здесь на сцену выходит Redis. Это in-memory база данных, которая хранит результаты SQL-запросов в оперативной памяти. Когда CMS запрашивает данные (например, список последних постов), она сначала проверяет Redis. Если данные есть — отдаёт мгновенно. Если нет — идёт в MySQL, забирает данные и попутно сохраняет их в Redis для следующих запросов. Redis работает в сотни раз быстрее MySQL, потому что данные хранятся в RAM, а не на диске. Настройка Redis для WordPress или другой CMS. Первый шаг: установить Redis на сервер (apt install redis на Ubuntu). Второй: установить плагин для CMS (например, Redis Object Cache для WordPress). Третий: подключить плагин к Redis через параметры соединения. Четвёртый: проверить работу. Установите Query Monitor и сравните количество запросов к базе данных с Redis и без. Обычно количество запросов падает на 50-90 процентов. Для высоконагруженных проектов это означает снижение нагрузки на процессор и ускорение TTFB в 2-5 раз.
Memcached: альтернатива Redis
Memcached — это более старая и простая альтернатива Redis. Он тоже хранит данные в RAM и ускоряет запросы к базе данных. Отличия. Redis умеет сохранять данные на диск (персистентность), поддерживает больше типов данных (строки, списки, множества, хеши), работает как брокер сообщений. Memcached — только пары ключ-значение, данные теряются при перезапуске сервера, но зато он проще в настройке и потребляет меньше ресурсов. Что выбрать для типового сайта? Если вы просто хотите ускорить WordPress и не планируете использовать Redis как очередь или Pub/Sub — Memcached справится. Если у вас сложный проект с несколькими серверами, микросервисами, необходимостью хранить сессии централизованно — Redis даст больше возможностей. Подробнее о связке кеширования с CDN читайте в статье Кеширование и CDN для ускорения сайта.
Кеширование PHP-сессий
Сессии в PHP по умолчанию хранятся в файлах на диске. Для одного сервера это работает. Но если у вас несколько серверов за балансировщиком, сессии нужно хранить в общем месте, чтобы пользователь не терял авторизацию при переключении между серверами. Redis и Memcached решают эту проблему. Настройка: в php.ini меняем session.save_handler на redis или memcached и указываем путь к серверу. Сессии начинают храниться в RAM и доступны всем серверам в кластере. Даже для одного сервера хранение сессий в Redis ускоряет работу по сравнению с файловыми сессиями, особенно при высокой нагрузке.
Мониторинг серверного кеша
Кеш должен работать, а не создавать иллюзию ускорения. Что мониторить. Первое: hit ratio — процент запросов, обслуженных из кеша. Для FastCGI Cache это видно в заголовках ответа (X-FastCGI-Cache: HIT или MISS). Для Redis — в админке плагина или командой INFO в redis-cli. Хороший hit ratio для статического контента — 90-95 процентов, для динамического — 50-70 процентов. Второе: использование памяти. Redis и Memcached хранят данные в RAM. Если памяти не хватает, они начинают удалять старые записи, и hit ratio падает. Настройте maxmemory и политику вытеснения (allkeys-lru — хороший выбор для кеша). Третье: фрагментация памяти. Со временем Redis фрагментирует память. Команда MEMORY STATS покажет уровень фрагментации. Если он выше 1.5, возможно, нужно перезапустить Redis или сменить аллокатор памяти. Четвёртое: инвалидация кеша. После обновления контента новые данные должны появляться на сайте. Если они не появляются — кеш не сбрасывается. Проверьте логи плагина или скрипта инвалидации.
Часто задаваемые вопросы
Какой серверный кеш выбрать для начала? Nginx FastCGI Cache — самый простой и даёт максимальный эффект для статических и редко обновляемых страниц. Добавьте его первым. Затем подключите Redis для ускорения базы данных. Memcached оставьте на случай, если Redis по какой-то причине не подходит.
Совместимы ли серверный кеш и плагины кеширования WordPress? Да, но они работают на разных уровнях. Плагин кеширования (WP Super Cache, W3 Total Cache) генерирует статические HTML-файлы. FastCGI Cache кеширует ответы PHP. Они могут работать вместе, но лучше выбрать что-то одно, чтобы не усложнять инвалидацию кеша.
Нужен ли серверный кеш на shared-хостинге? На shared-хостинге доступ к настройкам сервера ограничен, и вы не сможете установить Redis или настроить FastCGI Cache. В этом случае используйте плагины кеширования для вашей CMS. Если сайт вырос и shared-хостинг не справляется — переходите на VPS, где доступна серверная оптимизация.
Как проверить, что серверный кеш работает? Для FastCGI Cache: откройте сайт в режиме инкогнито, затем проверьте заголовки ответа. Если видите X-FastCGI-Cache: HIT — кеш работает. Для Redis: используйте команду redis-cli INFO stats, смотрите на keyspace_hits и keyspace_misses. Если hits растут — кеш работает.
Что делать, если после включения кеша сайт сломался? Отключите кеш и очистите его. Проверьте исключения — возможно, закешировалась админка или страницы с персонализированным контентом. Настройте правила исключения корректно и включите кеш снова. Всегда тестируйте настройки кеширования на staging-окружении перед внедрением на боевой сайт.