proxy cache stampede

[Vladimir Stavrinov]

On Wed, Sep 21, 2011 at 11:58:42PM +0400, Dmitriy MiksIr wrote:

> кучи тяжелых файлов) nginx никогда не затачивался, ибо сама идея -
> прокачивать тяжелый файл через фронтент... немного не в духе nginx.

У меня никогда и не было такой идеи. Роль frontend здесь можно считать
сугубо формальной, но не по существу.

> Такие задачи решаются иначе - начиная от простых редиректов и

Эта задача уже решена, но не простым редиректом, а двухуровневой
системой распределения запросов по разным критериям, в том числе и по
нагрузке.

> файл должен отдавать клиенту тот сервер, на котором он расположен
> физически.

Именно так оно и происходит. Я уже писал: я решил использовать
proxy_cache как альтернативу полному зеркалу. Файлы в таком кэше могут
жить вечно (я нарисовал им 1 год жизни), потому что никогда не
обновляются. Смысл такой альтернативы, помимо очевидной экономии
дискового пространства,  ещё и в том, что бы не закачивать на зеркало
файлы, которые возможно никогда не будут востребованы и не тратить время
на синхронизацию, контролировать и прогнозировать это время, поскольку
теперь данные можно отдавать клиентам сразу после их публикации. Кроме
того, такая технология развязывает мне руки: я могу свободно размещать
такие сервера где угодно и когда угодно сразу, же запуская их в
эксплуатацию, тогда как для на заполнение полного зеркала ушло бы
несколько недель или же пришлось бы, как я это уже делал, высылать диски
по почте, но и это уже скоро станет не возможным в силу объёма и когда
первоисточник таких данных то же будет удалённым. 

Но вот теперь, в результате обнаружившейся проблемы множественных
запросов, время на "синхронизацию", точнее на заполнение кэша,
увеличивается многократно.  Правда до тех пор пока это ограничивается
отдельными запросами и касается как правило вновь опубликованных данных,
других преимуществ кэширующего сервера это не отменяет. Тем не менее я
теперь думаю о том, что бы заменить nginx чем нибудь другим, тем же
apache например, или как то прикрутить к нему squid. Но очень не хотелось
бы ставить крест на этом весьма достойном конкуренте.


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