ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re[3]: purge



Здравствуйте.

>>> IS> Я  пару  лет  назад планировал ленивую инвалидацию большого объёма
>>> IS> ответов  таким  образом: в ответ добавляются заголовки с ключами в
>>> IS> виде md5-хэшей:
>>> 
>>> IS> X-Accel-Depends: XXXXX...md5...XXXXXX  YYYYY...md5...YYYYYY ...
>>> 
>>> IS> Ключи хранятся в той же зоне, что и мета-данные кэша.
>>> IS> Если  в  запрашиваемом  ответе  есть  такие  ключи, то проверяется
>>> IS> существование этих ключей. Если ключей нет, то ответ валидный.
>>> IS> Если  же  есть  и  хотя  бы  один  ключ  моложе  ответа,  то ответ
>>> IS> невалидный.
>>> IS>  Если  же ключи есть, но старше ответа, то ответ валидный - он
>>> IS> получен уже после получения инвалидирующих ключей.
>>> 
>>> IS> Инвалидирующие ключи получаются тоже в ответах
>>> 
>>> IS> X-Accel-Invalidate: XXXXX...md5...XXXXXX  YYYYY...md5...YYYYYY ...
>>> 
>>> IS> Допустим, есть страница со списком каментов john'а и bill'а,
>>> IS> у неё есть такие зависимости
>>> 
>>> IS> X-Accel-Depends: XXX...john...XXX  YYY..bill...YYY
>>> 
>>> IS> Если теперь bill запостит камент, то в ответе будет
>>> 
>>> IS> X-Accel-Invalidate: YYY..bill...YYY
>>> 
>>> IS>  nginx  создаёт  такой ключ в зоне и следующий запрос к списку
>>> IS> обнаружит, что список уже невалиден.
>>> 
>>> Мне   кажется,   что   подобной   логике  место  в  коде  бэкенда.
>>> закэшированным  данным  -  в  мемкешеде  ну или в кэше nginx-а, из
>>> которого  можно  удалять  через  PURGE.  А чтобы удалить несколько
>>> закэшированных  кусочков,  пишется  на  libev либа, которая делает
>>> нужное  количество  http-запросов  параллельно.  А ещё лучше, если
>>> веб-сервер позволит делать мульти-запросы для PURGE, когда в одном
>>> запросе несколько url-ов на удаление из кэша. Подобное ещё было бы
>>> полезно для веб-дава сделать, а то порой досить nginx кучей DELETE
>>> приходится.

IS>> Тут управляет именно бэкенд: он устанавливает зависимости.

ММ> Неудобно  генерить  подобные  htpp-заголовки, ибо информация о них
ММ> известна  лишь  в  середине выполнения генерящего страницу кода. А
ММ> заголовки  хочется  выплюнуть  как  можно  раньше,  и не держать в
ММ> памяти  уже сгенерённый к тому времени html. Это я конечно упрощаю
ММ> и  всё  применительно  к  себе  говорю,  но  наверное  так  многие
ММ> поступают. Чистка кэша в мемкешеде тут вне конкуренции.

Сейчас  ещё  раз  подумал.  С мемкешедом чайлд апача будет обслуживать
запрос  дольше,  поэтому да, через заголовки схема лучше, хоть и менее
удобна при программировании.

-- 

С уважением,
Михаил Монашёв
mailto:postmaster@xxxxxxxxxxxxx
ICQ# 166233339
http://michael.mindmix.ru/
Без бэкапа по жизни.


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


 




Copyright © Lexa Software, 1996-2009.