Кэширование сохраняет результат работы, чтобы повторный запрос не выполнял те же вычисления заново. В PHP-проекте кэшировать можно разные вещи: скомпилированный код, данные, результаты запросов или готовый HTTP-ответ. Эти уровни решают разные задачи. Поэтому сначала нужно найти источник задержки и определить, насколько допустимы устаревшие данные.
Начните с измерения
Выберите медленный сценарий: открытие каталога, формирование отчёта или обращение к внешнему сервису. Замерьте время и выясните, где оно расходуется. Если приложение долго ждёт ответ сторонней системы, включение кэша кода не устранит эту задержку. Если проблема в неэффективном запросе к базе, сначала стоит проверить сам запрос и индексы.
Сравнивайте одинаковые сценарии, нагрузку и исходные данные. Запишите результат до изменения и после него. Не обещайте ускорение в определённое число раз без фактических измерений именно вашего проекта.
Какие уровни кэша различать
- OPcache. Сохраняет скомпилированный байткод PHP. Он не является кэшем результатов запросов к базе.
- Кэш данных. Хранит подготовленные значения: например, результат расчёта или ответ внешнего сервиса.
- Кэш страницы или ответа. Позволяет повторно использовать готовый результат при подходящих условиях.
- Кэш браузера и промежуточных узлов. Управляется в том числе HTTP-заголовками и требует учитывать приватность ответа.
Назначение OPcache описано в руководстве PHP. Для кэширования пользовательских данных существует, например, APCu. Выбор хранилища зависит от архитектуры: локальный кэш одного процесса или узла нельзя автоматически считать общим для всех серверов приложения.
Определите ключ и срок жизни
Ключ должен учитывать все параметры, от которых зависит результат. Для списка товаров это могут быть фильтр, сортировка, страница, язык и права пользователя. Если забыть один параметр, разные запросы начнут получать одинаковый ответ. Для персональных данных особенно важно исключить смешивание пользователей.
Срок жизни, или TTL, ограничивает время хранения. Короткий срок увеличивает число пересчётов, длинный повышает вероятность устаревшего результата. Решение принимают по смыслу данных: расписание, остаток товара и справочная информация могут требовать разных правил актуальности.
Продумайте обновление и отказ кэша
Есть несколько подходов: удалить запись при изменении данных, дождаться окончания TTL или использовать версию ключа. У каждого есть последствия. Например, при массовом одновременном истечении записей множество запросов может начать выполнять дорогую операцию одновременно. Для такого сценария заранее рассматривают блокировку пересчёта, распределение сроков или другой подход, подходящий архитектуре.
Приложение должно понимать, что делать при недоступности хранилища: выполнить расчёт напрямую, вернуть контролируемую ошибку или использовать допустимый устаревший результат. Это часть проектирования, а не деталь, которую стоит оставлять на момент аварии.
Что проверить перед выпуском
- Первый запрос без записи и повторный запрос с записью.
- Изменение исходных данных и удаление устаревшего значения.
- Разные пользователи, языки и параметры запроса.
- Недоступность кэша и одновременные обращения.
- Рост памяти и результат при реальной для проекта нагрузке.
Для HTTP-кэширования отдельно изучите руководство MDN. Не кэшируйте персональный ответ как общедоступный. Ускорение не должно нарушать разграничение доступа или правильность данных.
Если нужно разобрать конкретное приложение, подготовьте описание сценария, замеры и обезличенный фрагмент кода. На Digital Mentoring можно подобрать специалиста по профилю задачи. Предметом разбора должен быть измеренный источник задержки и правила актуальности, а не абстрактный совет «добавить Redis».
