Re: Re[2]: Что-то типа cache db планируется?

["Trurl" <nginx-forum@xxxxxxxx>]

Михаил Монашёв Wrote:
-------------------------------------------------------
> Здравствуйте, Trurl.
> 
> > У меня вообще одна голая практика... ферма (много апачей и не только
> > их)  живет  в  штатах,  а узлы CDN раскиданы по Европе и все это под
> > контролем  ДНС с геобалансингом (+мониторинг состояния с отключением
> > упавших  узлов). Например две точки в Москве (на разных провайдерах)
> > -  между  ними перекинуть видео весом в 2ГБ куда выгоднее чем тащить
> > со  штатов,  учитывая что "внешний" траффик зачастую лимитируется, в
> > отличии от проброса по М9/М10. Даже с Киевского узла его перегнать -
> > и то на порядок выгоднее.
> 
> Вопрос  не  в  том,  чтобы перекинуть, а в том, чтобы потом эти данные
> как-то  использовать.  Чтобы  использовать  быстро,  их  хорошо  бы  в
> оперативке держать. Если такие данные приходят от нескольких серверов,
> то  они съедят много оперативки и их хорошо бы не дублировать в разных
> местах.
> 
> У  Вас,  как  я  понимаю,  2  параметра,  по которым можно производить
> оптимизацию: время и стоимость доставки контента.

Стоимость доставки включает в себя и внутреннюю доставку между узлами.

> 
> Если говорить про время, то отдавать контент надо с ближайшего кэша по
> геобалансингу  (а  лучше  не  по  географии,  а  по rtt до подсети, из
> которой  браузер  сделал  запрос), а проксировать запрос до ближайшего
> хранилища  и параллельно до ближайших кэшей (если они ближе хранилища,
> работают  и  недогружены)  и  использовать того, кто первый ответит, а
> остальные  соединения  дропать. Или по таймауту как-нить останавливать
> передачу  данных,  а  tcp-соединение оставлять для следующих запросов.
> Или  tcp-соединения  до  возможных  бэкендов  заранее  открывать     в
> достаточном количестве и поддерживать их.

Ну у меня сейчас геобалансинг и есть, на основе IP запрашивающего ДНС (для
гугля пришлось делать EDNS subclient и с ними договариваться). Точность не
ахти, но достаточная.
Понятия хранилищ нету, весь контент работает по стандартам кеширования и
разницы между страничкой сайта, сгенеренной на 2 минуты для всех, странички
форума - для одного на 10 сек, или статики видео - на месяц как бы нет, в
любом объекте написано как и на сколько его кешировать.
Сквиды на узлах у меня сейчас обмениваются базами и по UDP шлют запросы всем
соседям и апстримам на предмет "у кого есть данный объект". Само собой что
соседи, если у них есть в кеше такой объект, ответят быстрее. Если нет -
пытаюсь запросить апстримы (их много, но все в одном месте), если они не
доступны (пингуются постоянно + проверка ответов) - пытаюсь получить объект
через соседа. Сосед при этом уже не имеет права спрашивать другого соседа -
только апстримы. Этот "загиб" в России весьма востребован, ибо узлы у меня
на разных внешних провайдерах сидят и это сильно спасает.

nginx у меня сейчас только использует один оконечных узлов (на соседнем
компе с прямым линком) в качестве апстрима (+бекапом другой узел, тоже в
Москве). Такой изврат после того как nginx 2 заза полностью забил канал
апстримов (со сквидами такого не было никогда, видать они тормознутые в этом
плане ;).

А вообще за nginx взялся только потому, что в сквиды под сильной нагрузкой
частенько валятся по совершенно идиотским поводам и вообще странно глючат
(например, как-то теряют название протокола и получается что-то типа
(null)://www... ). Nginx под такой же нагрузкой нарягает только меня своими
приколами, а не юзеров.

> 
> -- 
> С уважением,
>  Михаил                          mailto:postmaster@xxxxxxxxxxxxx
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@xxxxxxxxx
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

Posted at Nginx Forum: 
http://forum.nginx.org/read.php?21,235074,235145#msg-235145

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