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

[SaveFrom.net]

благодарю!

16 октября 2009 г. 9:56 пользователь Noon es Shadow
<noonesshadow at gmail.com>написал:

> Спасибо за статью!!!
>
> 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/91b1f2e9/attachment.html>