ПРОЕКТЫ 


  АРХИВ 


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: proxy cache stampede



21.09.2011 19:15, Vladimir Stavrinov wrote:
> On Wed, Sep 21, 2011 at 06:26:14PM +0300, Alex Vorona wrote:
> 
>> Отдавайте редирект туда, где файл существует, в то время как сами
> 
> А где же он ещё существует, если не на backend сервере? 
Либо вместо редиректа - проксирование на backend без буфферизации.
> 
>> закачиваете этот файл в
> 
> Это я не понял. Кто закачивает и как, если мы запрос уже куда - то
> перенаправили? Или я должен в ручную это делать?
Это уже как вы сделаете. Можно и nginx научить закачивать, например потанцевав 
вокруг
post_action, можно анализировать access_log и тп.
> И какой в этом смысл,
> если все такие запросы пойдут на backend сервер?
- запросы будут обслужены
- подтянется в локальное зеркало/кэш файл и после этого запросы к нему будут 
обслужены
фронтендом.

Альтернатива - подождать реализации busy locks в nginx, как заметил Максим или 
ускорить её
вложением некоторой суммы.
>> этой проблемы, proxy_store тут в помощь.
> 
> Я не вижу там никаких средств управления хранилищем. Как его чистить? По
> какому критерию?  Как ограничить объём? Или это опять нужно делать
> вручную? 
cron+find+sort+rm удаляют некоторое число файлов с самым старым atime по 
достижении
нужного % заполнения хранилища.

>> А по-вашему, что должен делать nginx, когда приходят ещё запросы на
>> один и тот же uri, отсутствующий в кэше на момент первого запроса и
>> уже тянущийся в 1 поток?
> 
> Я не знаю, но наверно как то можно было бы сначала брать первую часть
> данных из одного временного файла, а потом, после удаления временного
> файла продолжить подкачивать уже из кэша. Или же не удалять временный
> файл до тех пор пока не будет обслужен полностью последний такой запрос.
> Но как бы там ни было, закачивать многократно одни и те же данные - это
> в принципе, это в корне не правильно не зависимо от размера файлов.
А c range-запросами(как раз для больших файлов актуально) и  стримингом это 
совместить
будет нетривиально.

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


 




Copyright © Lexa Software, 1996-2009.