ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: nginx-1.1.12



Hello!

On Wed, Dec 28, 2011 at 10:57:02PM +0400, Михаил Монашёв wrote:

> Здравствуйте, 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.

Maxim Dounin

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


 




Copyright © Lexa Software, 1996-2009.