proxy cache stampede

[Alex Vorona]

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-запросами(как раз для больших файлов актуально) и  стримингом это совместить
будет нетривиально.