Стратегия кеширования страниц
Я мало разбираюсь в ngnix кешировании. Сейчас ,как я понял, прокси настроен так, что не пропускает заголовки if_modified ,в том числе для динамических страниц. Отдача ответа 304 Not modified, как я понимаю, осуществляется следующим образом : ngnix запрашивает страницу, сверяет длину страницы с длиной страницы из предыдущей отдачи и соответственно отдает нужный ответ. Вроде бы неплохо - прокси взял на себя всю работу по кешированию. Однако есть вопросы. Я пытаюсь разработать высоконагруженный сайт. И такая стратегия кеширования не кажется оптимальной. Фактически каждый раз движку сайта приходится формировать целую страницу, чтобы сверить кеш. Понятно, что можно легко и быстро проверить актуальность страницы с помощью легковесного скрипта перед началом формирования страницы. Это сэкономить время и ресурсы сервера. Для высоконагруженного сайта c динамическими страницами с часто меняющейся информацией это очень актуально. Правильно ли я рассуждаю ,что посоветуете и что мне сделать, чтобы все же запросы if-Modifed прорывались через прокси?
Ответы (1 шт):
В первую очередь нужно отключить no-cache режим кеширования в php установив опцию session.cache_limiter = ''.
При генерации страницы сохраняйте время последнего изменения контента где-нибудь в key-value базе (например в Редисе или Мемкэше) и отдавайте заголовоки ответа Last-Modified и Cache-Control
При получении заголовка ответа клиент (браузер или прокси) будут сохранять полученную дату и в последующем делать запрос с заголовком If-Modified установленным в значение полученной ранее от вас даты Last-Modified.
Получив такой запрос вы извлекаете дату из key-value БД и сверяете. Если они у вас разные, то действуете в соответствии с п.1, а если одинаковые отдаете статус 304 Not Modified.
при обновлении контента сохраняете новую дату в key-value БД