Re: proxy_cache_key и fastcgi_cache_key

[Валентин Бартенев <vbart@xxxxxxxxx>]

On Friday 10 January 2014 23:10:17 Gena Makhomed wrote:
> On 10.01.2014 22:48, Валентин Бартенев wrote:
> 
> >> Разве много ли таких конфигураций, которые полагались
> >> на дефолтовое значение директивы proxy_cache_key ?
> 
> > Полагаю не мало людей используют кэш для одного хоста
> > и ключ по умолчанию у них нормально работает, а после
> > изменения перестанет.
> 
> Ok, но ведь при парсинге конфига nginx может посчитать

Это не так просто и ведет к довольно сильному layering violation.

Следует учесть, что в nginx:

 1. Директивы из разных модулей обычно ничего не знают о существовании
    друг-друга, а равно и значениях;

 2. Могут встречаться в конфиге в произвольном порядке, а директива
    server_name вообще несколько раз.  Такая конфигурация валидна:

    server {
       server_name example.org;
    
       location {
           proxy_pass backend;
       }

       server_name example.org;
    }

 3. Директива proxy_cache_key может быть задана также на уровнях http, server,
    и location-ах любой степени вложенности.

 4. Как отсутствие, так и наличие директивы proxy_cache_key, не означает,
    что кэш вообще включен и используется.  Для этого должно совпасть ещё
    минимум два условия:

    а) Наличие директивы proxy_pass в данном location-не, или на
       уровне server (неявный location-ой);

    б) Наличие директивы proxy_cache со значением отличным от off
       в этом же location, или унаследование такового с уровня выше.


> количество хостов в конфиге, и если там всего один хост
> и явно не задан в конфиге proxy_cache_key - выдавать warning
> но продолжать работать со старым дефолтовым значением,
> а если хостов больше одного - то переключать на новый
> дефолт и выдавать fatal error,

Типичный конфиг:

  server_name example.com www.example.com;


> если proxy_cache_key
> не определен - всеравно в такой конфигурации от
> proxy_cache_key $scheme$proxy_host$request_uri;
> будет больше вреда, чем пользы из-за перемешивания
> в кеше контента от разных virtual host`ов.
> 
> А если это highload, и это был отдельный location
> под общие элементы и/или ssi-инклуды -
> его админы в любом случае внимательно
> читают CHANGES и все варнинги от nginx.
> 
> В таком варианте ведь ничего не сломается?

Почему ни warning, ни error сделать не представляется разумным - пояснил в 
самом начале.

Опять же, ИМХО если что-то предпринимать в этом отношении, то лучше поступить 
следующим образом:

  1. Добавить второй параметр, задающий ключ, в директивы proxy_cache,
     fastcgi_cache, scgi_cache, uwsgi_cache;

  2. Отказаться от отдельных директив *_cache_key.

Причем возможно сделать с промежуточным этапом: параметр опционален и warning 
при его отсутствии или наличии *_cache_key директив в конфиге.

Либо разом: второй параметр обязателен когда значение первого отлично от off,
и соответствующие ошибки - не запускаемся пока не поправят конфиг.

Очевидные плюсы:

 1. Упрощается конфигурация, поскольку ИМХО от раздельного задания ключа и
    зоны никакой практической пользы, зато какое-то сложное условие включения
    кэша в location-е.

 2. Изменения потребуют явного вмешательства и принятия мер со стороны
    администратора, а не пройдут незамеченными в виде тихо переставшего
    работать кэша.

И очевидный минус: затронет всех, кто использует кэш.

--
Валентин Бартенев
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru