On 07.01.2014 18:08, S.A.N wrote:

>> Торг здесь не уместен. Можно написать статью и без ревалидации по
>> ETag.
...
> Я не планировал торговаться, дело в том что я программист не администратор и
> хотел бы написать статью в первую очередь для программистов, в статье
> раскрыть проблемы создания эффективных валидаторов кеша, на данный момент
> самый эфективный валидатор это ETag, мы его используем не только как
> валидатор, но как прелоадер ключей к Memcache, но это разговор на целую
> статью.

Было бы очень интересно почитать и о том, как это все
сейчас делается на backend`е, без участия nginx. Потому что
я пока что не могу понять что в этом php-скрипте на 200 строк.

> Без ETag статья про кеширования будет просто не интересна, писать шпаргалки
> для амдинов на тему как настроить кеширования Nginx на временной интервал, с
> последующей ревалидацией по IF-Modified-Since, как-то совсем грустно потому
> что на дворе уже 2014 г.

Понятно. Но ведь валидацию по ETag в любом случае делает backend,
потому что тот php-скрипт на 200 строк в любом случае не сможет
выполняться внутри nginx. Модуль mod_perl - экспериментальный,
лучше не включать его на production без крайней необходимости.
А mod_lua судя по всему еще более экспериментальный чем mod_perl.

Да и блокировать это будет nginx worker запросами к memcached,
даже если бы модули mod_perl и mod_lua работали бы без глюков.
Общая производительность системы от этого упадет а не вырастет.

Теоретически, есть вариант - удалять из кеша nginx устаревшие
записи с помощью fastcgi_cache_purge, но "This functionality
is available as part of our commercial subscription only".

Хотя судя по документации, fastcgi_cache_bypass будет делать
почти то же самое, обновляя кеш nginx ответом на запрос клиента.

>>> Но это далекое будущее, сейчас меня больше интересует почему тот же
>> Squid
>>> прокси не удаляет клиенские заголовки кеширования и сам не кешит
>> ответ в 304
>>> статусе и это все без спец конфига под каждый сайт :)
>>
>> squid - это forward proxy, а nginx - web server. что ж тут не
>> ясного...
>
> Для меня как для разработчика, важен момент прозрачной работы всех звений
> между приложением и клиентом, когда одно звено (Nginx) начинает удалять
> клиентские заголовки кеширования, это уже не прозрачное проксирования, это
> уже магия хаков, возможно оправданных, потому что таким образом Nginx
> форсирует наполнения своего кеша и защищает себя от проблемы кеширования 304
> статуса, но то что это исключает возможность бекенда работать с клиенским
> кешированиям во внимания никто не брал, наверно дело в том что не многие
> одновременно на одном server{} используют Nginx кеширования и клиентское
> кеширования.

Кстати, похоже, что есть вариант еще проще, используя директиву
fastcgi_cache_bypass для запросов с If-Modified-Since и If-None-Match
и выставляя в ответе заголовок X-Accel-Expires: 0
если статус ответа backend`а будет 304.

А если статус ответа 200 - то этот же ответ
на запрос If-Modified-Since/If-None-Match
будет автоматически обновлять и кеш nginx,
на время X-Accel-Expires или max-age из Cache-Control.

А если backend вдруг понимает, что ответ в кеше nginx устарел -
тогда он может сам и сгенерировать запрос, который благодаря
директиве fastcgi_cache_bypass уйдет на backend и обновит кеш.

Управлять одновременно и кешем на стороне клиента/браузера
и кешем nginx средствами backend`а можно, было бы желание.

--
Best regards,
Gena

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru