Re: Анонс: статья "Подводные камни при использовании кэширования в nginx"

[Noon es Shadow]

Спасибо за статью!!!

16 октября 2009 г. 8:29 пользователь Igor Sysoev <is at rambler-co.ru> написал:

> On Fri, Oct 16, 2009 at 03:41:23AM +0400, Dmitry Koterov wrote:
>
> > Я тут статью черканул: http://dklab.ru/chicken/nablas/56.html
> > Если есть мысли/замечания/комментарии/уточнения, буду рад внести
> изменения.
>
> > fastcgi_cache_valid: кэшируем код ответа 304 тоже
> >
> > fastcgi_cache_valid 200 301 302 304 5m;
> >
> > В директиве fastcgi_cache_valid<
> http://sysoev.ru/nginx/docs/http/ngx_http_fastcgi_module.html#fastcgi_cache_valid
> >мы
> > заставляем кэшировать не только стандартные коды 200 ОК, 301 Moved
> > Permanently и 302 Found, но также и 304 Not Modified. Почему? Давайте
> > вспомним, что означает 304. Он выдается с пустым телом ответа в двух
> > случаях:
> >
> >    - Если браузер послал заголовок "If-Modified-Since: date", в котором
> date
> >    больше либо равна значению заголовка ответа "Last-Modified: date".
> Т.е.
> >    клиент спрашивает: "Есть ли новая версия с момента date? Если нет,
> верни мне
> >    304 и сэкономь трафик. Если есть, отдай мне тело страницы".
> >    - Если браузер послал заголовок "If-None-Match: hash", где hash
> совапдает
> >    со значением заголовка ответа "ETag: hash". Т.е. клиент спрашивает:
> >    "Отличается ли текущая версия страницы от той, что я запросил в
> прошлый раз?
> >    Если нет, верни мне 304 и сэкономь трафик. Если да, отдай тело
> страницы".
> >
> > В обоих случаях Last-Modified или ETag будут взяты, скорее всего, из кэша
> > nginx, и проверка пройдет очень быстро. Нам незачем "дергать" PHP только
> для
> > того, чтобы скрипт выдал эти заголовки, особенно в свете того, что
> клиентам,
> > которым уйдет ответ 200, он будет отдан из кэша. fastcgi_cache_key:
> > внимательно работаем с зависимостями
> >
> > fastcgi_cache_key
> >
> "$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri";
> >
> > Особого внимания заслуживает значение в директиве
> > fastcgi_cache_key<
> http://sysoev.ru/nginx/docs/http/ngx_http_fastcgi_module.html#fastcgi_cache_key
> >.
> > Я привел минимальное рабочее значение этой директивы. Шаг вправо, шаг
> влево,
> > и вы начнете в ряде случаев получать "неправильные" данные из кэша. Итак:
> >
> >    - Зависимость от $request_method нам нужна, т.к. HEAD-запросы в
> Интернете
> >    довольно часты. Ответ на HEAD-запрос никогда не содержит тела. Если
> убрать
> >    зависимость от $request_method, то может так совпасть, что кто-то до
> вас
> >    запросил главную страницу HEAD-методом, а вам потом по GET отдастся
> пустой
> >    контент.
> >    - Зависимость от $http_if_modified_since нужна для того, чтобы кэш с
> >    ответом 304 Not Modified не был случайно отдан клиенту, делающему
> обычный
> >    GET-запрос. Иначе клиент может получить пустой ответ из кэша.
> >    - То же самое и с $http_if_none_match. Мы должны быть застрахованы от
> >    выдачи пустых страниц клиентам!
> >    - Наконец, зависимость от $host и $request_uri не требует
> комментариев.
>
> Спасибо. Комментарий по поводу 304 и HEAD:
>
> 1) HEAD должен отрабатываться нормально без дополнительных настроек:
>   fastcgi_cache_key  "...$request_method...", то есть, у бэкенда всё равно
>   запрашивается GET, полный ответ кэшируется и отдаётся только заголовок.
>
> 2) 304, $http_if_modified_since, $http_if_none_match, etc.:
>   Строки If-Modified-Since, If-Range, Range, etc. вырезаются из запроса
>   к бэкенду, поэтому всегда кэшируется полный ответ. Клиенту же
>   возвращется то, что он попросил.
>
>
> --
> Игорь Сысоев
> http://sysoev.ru
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20091016/0d87878c/attachment.html>