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
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@xxxxxxxxx
***************************
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru
|