nginx-1.1.12

[Михаил Монашёв]

Здравствуйте, Maxim.

>> >> >> >     *) Добавление: директивы
>> >> proxy/fastcgi/scgi/uwsgi_cache_lock,
>> >> >> >        proxy/fastcgi/scgi/uwsgi_cache_lock_timeout.
>> >> >> 
>> >> >> А где можно почитать по эти новые директивы?
>> >> 
>> >> > Пока тут:
>> >> 
>> >> > http://trac.nginx.org/nginx/changeset/4386/nginx
>> >> 
>> >> > Скоро опишем в документации.  In short: если включена директива
>> >> 
>> >> >     proxy_cache_lock on;
>> >> 
>> >> > то при наличии нескольких запросов к конкретному незакешированному
>> >> > ресурсу - на бекенд пойдёт только первый, остальные будут ждать
>> >> > вплоть до proxy_cache_lock_timeout каждый.
>> >> 
>> >> Полезная вещь.
>> >> 
>> >> Почитал
>> >>
>> http://mailman.nginx.org/pipermail/nginx-devel/2011-December/001576.html
>> >> Странная реализация. Зачем на каждый ожидающий запрос вешать отдельный
>> >> таймаут, если достаточно одного на первый запрос, пошедший к бэкенду?
>> 
>> > Таймаута   -   одного  недостаточно,  т.к.  proxy_cache_lock_timeout
>> > ограничивает  время, которое *один конкретный запрос* может провести
>> > в  ожидании лока (т.е. дополнительное время ожидания, которое увидит
>> > клиент).  У  каждого запроса начальное время ожидания своё (да и сам
>> > таймаут теоретически может быть не таким, как у других).
>> 
>> А зачем снова долбиться на бэкенд, который не смог ответить? Почему бы
>> всем  запросам  в  очереди  не выдать тот же ответ, что получил первый
>> запрос? Они ведь не зря в очередь выстроились и ждут.

> В общем случае мы не знаем, смог бекенд ответить или нет.  Ответ 
> может занять существенно большее время, чем время 
> proxy_cache_lock_timeout.  В худшем случае - ответ будет через 
> заметное время, и при этом его нельзя будет кешировать (и 
> соответственно отдать другим ожидающим клиентам).  Если таймаутов 
> не будет - то в такой ситуации все запросы будут отправляться на 
> бекенд по одному, и с большой вероятностью части ответов клиенты 
> просто не дождутся.

> Директива proxy_cache_lock_timeout позволяет ограничить время, 
> проводимое запросом в ожидании лока, и соотвтетственно определяет 
> максимально возможную задержку, вносимую этим механизмом.  Т.е. в 
> худшем случае время ответа будет <как было> + _cache_lock_timeout.

Идею понял. Она даже лучше, чем изначально казалась :-)

-- 
С уважением,
 Михаил                          mailto:postmaster at softsearch.ru