Re: proxy_no_cache / proxy_cache_bypass

[Maxim Dounin <mdounin@xxxxxxxxxx>]

Hello!

On Thu, Jul 08, 2010 at 07:14:57PM +0400, Igor Sysoev wrote:

> On Thu, Jul 08, 2010 at 06:23:39PM +0400, Maxim Dounin wrote:
> 
> > Hello!
> > 
> > On Thu, Jul 08, 2010 at 02:48:41PM +0400, Igor Sysoev wrote:
> > 
> > > On Thu, Jul 08, 2010 at 02:37:01PM +0400, Maxim Dounin wrote:
> > > 
> > > > Hello!
> > > > 
> > > > On Thu, Jul 08, 2010 at 01:12:58PM +0400, Igor Sysoev wrote:
> > > > 
> > > > > На данный момент proxy/fastcgi/uwsgi/scgi_no_cache игнорируют ответ
> > > > > в кэше и идут к бэкенду. Но полученный ответ может быть закэширован,
> > > > > если бэкенд это явно разрешил с помощью X-Accel-Expres, Expires или
> > > > > Cache-Control. proxy_cache_valid при этом не учитываются.
> > > > > 
> > > > > Есть идея ввести proxy_cache_bypass, при которой ответ в кэше 
> > > > > игнорируется,
> > > > > но полученный ответ может быть закэширован в зависимости от разрешения
> > > > > бэкнда _И_ директив proxy_cache_valid.
> > > > > 
> > > > > Какое поведение в этом случае оставить для proxy_no_cache - не 
> > > > > понятно:
> > > > > то ли вообще запретить кэшировать ответ, то ли оставить как есть.
> > > > 
> > > > По хорошему, нужны возможности гибкого управления в двух местах:
> > > > 
> > > > 1. Берём ли мы ответ из кеша.  Сейчас это делается через 
> > > > proxy_no_cache, что по моим ощущениям вполне достаточно.
> > > > 
> > > > 2. Кладём ли мы ответ в кеш.  Сейчас можно только либо полностью 
> > > > доверится бекенду, либо совсем не доверять и использовать 
> > > > proxy_cache_valid.
> > > > 
> > > > Если я правильно понял предлагаемую семантику proxy_cache_bypass, 
> > > > то предлагается управлять сразу и (1) и (2).  Мне не видится это 
> > > > хорошим решением.
> > > > 
> > > > Вот, например, use case: файлы лежат на бекенде и большие, нужно 
> > > > поддерживать Range к бекендам, при этом хочется кеширование для 
> > > > полностью скаченных файлов.  Решение - брать ответы из кеша в если 
> > > > они там есть, если нет - отправлять запрос на бекенд вместе с 
> > > > заголовком Range, и не кешировать 206 ответы.  Сейчас это можно 
> > > > сделать только отказавшись от учёта Cache-Control/Expires.  И 
> > > > proxy_cache_bypass в решении этой проблемы никак не поможет.
> > > > 
> > > > IMHO, правильно увеличивать именно возможности управления (2).
> > > > 
> > > > Что касается proxy_cache_bypass, то аналогичное поведение
> > > > может быть достигнуто с помощью proxy_no_cache и директивы, 
> > > > включающей семантику "в зависимости от разрешения бэкнда _И_ 
> > > > директив proxy_cache_valid".  Что будет логичнее и гибкости даст 
> > > > существенно больше.
> > > 
> > > Логично, тогда можно раздедить так: proxy_cache_bypass определяет,
> > > брать ли ответ из кэша, а proxy_no_cache - класть ли ответ в кэш,
> > > если он был в состоянии bypass.
> > 
> > Нет-нет-нет.  Не надо завязыватся на "если он был в состоянии 
> > bypass".
> > 
> > Посмотри use case ещё раз - там *не нужно* пропускать кеш.  Если 
> > ответ есть в кеше - его просто нужно отдать.  А вот если там 
> > ответа не нашлось - то нужно *не сохранять* в кеш ответы с 206, 
> > даже если заголовки кеширование разрешают.
> 
> Да, наверное, это имеет смысл. Тогда первое время при использовании
> proxy_no_cache без proxy_cache_bypass нужно будет выводить предупреждение
> о изменении директивы.

Мне не нравится идея изменять семантику proxy_no_cache (даже с 
учётом её недавнего появления), впрочем и сама директива не 
нравится - и семантика по названию не ясна, и из общего ряда 
proxy_cache_* выбивается.  Лучше уж прибить чем менять.

Для семантики "не отдавать ответ из кеша" определённо лучше будет 
proxy_cache_bypass.

Для "не класть в кеш" - мне пожалуй больше всего нравится вариант 
proxy_cache_noupdate.

Но в принципе всё равно каким цветом покрасить, да.

Maxim Dounin

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