proxy cache stampede

[Vladimir Stavrinov]

On Wed, Sep 21, 2011 at 08:29:47PM +0300, Alex Vorona wrote:

> Либо вместо редиректа - проксирование на backend без буфферизации.

То есть кэш в топку? И зачем тогда мне такой прокси? Я и так могу всех
клиентов направить прямо на backend без всякого посредника.

> Это уже как вы сделаете. Можно и nginx научить закачивать, например потанцевав вокруг
> post_action, можно анализировать access_log и тп.

Это конечно круто.

> - запросы будут обслужены

Так они и сейчас обслуживаются, по морде никого не бьют.

> - подтянется в локальное зеркало/кэш файл и после этого запросы к нему будут обслужены
> фронтендом.

Опять же, так оно и сейчас происходит.

> Альтернатива - подождать реализации busy locks в nginx, как заметил

Ожидание - это не альтернатива, по определению.

> Максим или ускорить её вложением некоторой суммы.

Я поговорю с начальством, но не уверен что меня правильно поймут.

> cron+find+sort+rm удаляют некоторое число файлов с самым старым atime по достижении
> нужного % заполнения хранилища.

Это так я поступал с логами, которые logrotate не обрабатывал.

Подводя итоги: весь этот фейерверк решений оставляет в силе главное
условие: так или иначе, но одни и те же данные многократно закачиваются на
сервер, создавая паразитный трафик, даже если эти данные не сохраняются
на сервере, а прямотоком идут к клиенту. Тогда как предназначение
кэширующего сервера ровно обратное - балансировка нагрузки.

> А c range-запросами(как раз для больших файлов актуально) и
> стримингом это совместить будет нетривиально.

Если я правильно, понимаю и сейчас range запросы обслуживаются из файла и
если теперь это будет временный файл, то это мало что изменит. Во всяком
случае пока с этим нет проблем, мы специально это тестировали. А насчёт
стриминга не знаю, но думаю не обязательно всё совмещать - могут быть 
разные решения в разных случаях.


***************************
###  Vladimir Stavrinov
###  vstavrinov на gmail.com
***************************