3 января 2008 в 2:19
Создал свой вариант кеша. 
На файловой системе. Пока обкатываю на моем блоге. Принцип "кучи" подкаталогов аля сквид.
Не все отработано. та же cache_clear_all - но посмотрев исходники и рекомендации возможно сделаю полноценный модуль с "чисткой" кеша
Итак. Код:
<?php
class cache_cc{
var $data, $created, $expire, $headers;
function cache_cc($c){
$this->data = $c['data'];
$this->created = $c['created'];
$this->expire = $c['expire'];
$this->headers = $c['headers'];
}
}
function filecache_md5($key){
static $cache_arr;
if(isset($cache_arr[$key] ) ) return $cache_arr[$key];
$md = md5($key);
$cache_arr[$key] = $md;
return $md;
}
function filecache_md5path($table, $key){
static $cache_arr;
if(isset($cache_arr[$table . $key] ) ) return $cache_arr[$table . $key];
$md = filecache_md5($key);
$path = array($md{0}, $md{1}, $md{2}/*, $md{3}, $md{5}*/ );
$path = variable_get('filecache_path', 'files/cache') . '/'. $table . '/' . implode('/', $path);
$cache_arr[$key] = $path;
return $path;
}
function filecache_name($table, $key){
return filecache_md5path($table, $key) . '/' . urlencode($key);
}
function filecache_pmkdir($dir){
// FOR PHP 5 ONLY. PHP 4 SUCKS A COCK
if(is_dir($dir) ) return true;
return mkdir($dir, 0755, true);
}
// checks file exists and create path to them if not
function filecache_lockpath($table, $key){
if(!is_dir(filecache_md5path($table, $key) ) ){
filecache_pmkdir(filecache_md5path($table, $key) );
}
return filecache_md5path($table, $key) . '/' . 'lock';
}
function filecache_safefile_get_contents($table, $key){
$lck = filecache_lockpath($table, $key);
$src = filecache_name($table, $key);
$f = fopen($lck, 'w+');
if(flock($f, LOCK_SH) ){
$cnt = file_get_contents($src);
flock($f, LOCK_UN);
fclose($f);
return $cnt;
}
fclose($f);
return false;
}
function filecache_safefile_put_contents($table, $key, $cache){
$lck = filecache_lockpath($table, $key);
$f = fopen($lck, 'w+');
$src = filecache_name($table, $key);
if(flock($f, LOCK_EX) ){
$cnt = file_put_contents($src, $cache);
flock($f, LOCK_UN);
fclose($f);
return $cnt;
}
fclose($f);
return false;
}
function cache_get($cid, $table = 'cache') {
global $user;
$key = $cid;
if (!file_exists(filecache_name($table, $key) ) ) {
return 0;
}
$cache = unserialize(filecache_safefile_get_contents($table, $key) );
if (isset($cache->data)) {
// If the data is permanent or we're not enforcing a minimum cache lifetime
// always return the cached data.
if ($cache['expire'] == CACHE_PERMANENT || !variable_get('cache_lifetime', 0)) {
$cache['data'] = db_decode_blob($cache['data']);
}
// If enforcing a minimum cache lifetime, validate that the data is
// currently valid for this user before we return it by making sure the
// cache entry was created before the timestamp in the current session's
// cache timer. The cache variable is loaded into the $user object by
// sess_read() in session.inc.
else {
if ($user->cache > $cache->created) {
// This cache data is too old and thus not valid for us, ignore it.
return 0;
}
else {
$cache->data = db_decode_blob($cache->data);
}
}
return new cache_cc($cache);
}
return 0;
}
function cache_set($cid, $table = 'cache', $data, $expire = CACHE_PERMANENT, $headers = NULL) {
$cache = array(
'data' => $data,
'created' => time(),
'expire' => $expire,
'headers' => $headers,
);
$cache = serialize($cache);
$key = $cid;
filecache_safefile_put_contents($table, $key, $cache);
}
function cache_clear_all($cid = NULL, $table = NULL, $wildcard = FALSE) {
global $user;
// wildcard doesnotworks
// FOR FUTURE MAKE COMBINED WITH {cache} table
unlink(filecache_name($table, $cid) );
}
?>
Комментарии
ждём результатов, идея-то хорошая...
только лаконично как-то всё, может стоит рассказать, куда что вставлять и тд?
глядишь ещё кто-то присоединится...
О, В.Х, давно вас не видели
хех, да я-то здесь, а вот BBCode на Друпал.ру отключили... жаль...
Он самоотключился
Исправлено уже, хотя некоторые посты использующие тег code в полном виде по-прежнему отображаются пустыми. Не пойму, после апдейта на 5.6 это произошло или раньше.
Странно, почему-то codefilter после фильтра html перестал работать, хотя раньше в таком порядке работало. Пришлось поставить codefilter в начале цепочки фильтров, но в таком виде не проходят теги font (включать которые в фильтре html по понятным причинам не хочется).
оффтопик. сегодня добью cache_clear_all - чтобы делал очередь на удаление каталогов для крона. потом таки придется плагинчик делать для крона
rm -rf из php при чистке кеша - трудоемко. проще mv сделать
"Странно, почему-то codefilter после фильтра html перестал работать, хотя раньше в таком порядке работало."
там посмотри, версия кодефильтра обновилась по дате, хотя осталась такой же по названию... может пользуешься просто старой?
"оффтопик. сегодня добью cache_clear_all - чтобы делал очередь на удаление каталогов для крона. потом таки придется плагинчик делать для крона :)"
это у нас оффтопик, а это как раз по теме...
а никак нельзя, чтобы этот модуль начинал работать тогда, когда например база данных недоступна? то есть копировал чистые хтмл-файлы в папку и работал бы независимо от базы полностью?
можно опционально, но мне видится это прекрасным решением, не представляю какой должна быть нагрузка, чтобы не работал статический сайт... при этом можно ещё сделать и "полудинамическую" версию, когда статичный контент отдаётся при просмотре, а при добавлении материала, конечно же включается полная работа сайта...
нет нельзя. это всего лишь замена тормозному кешу друпала.
если вы ядро друпала глянете - то станет ясно, что не все там кешируется. посему не получится.
будет комбинированно полюбому.
"если вы ядро друпала глянете - то станет ясно, что не все там кешируется"
это понятно, что Друпалу оно не нужно кэшировать полную страницу, но вывод-то можно настроить, например, какую-нибудь "облегчённую версию", которая бы показывалась бы пока база данных недоступна...
в этом смысле, это конечно будет не замена кэшу как таковому, а что-то более альтернативное и универсальное... но вместе с файловым кэшем это бы работало, я думаю, превосходно...
mod_rewrite + статические копии страниц в отдельном каталоге. старый прием. только мертвость базы вне друпала как оценивать будете?
"только мертвость базы вне друпала как оценивать будете?"
очень просто, он ведь выводит страницу определённую при неработающей базе...
туда нужно включить перенаправление на статическую версию... а вот проверку из этой статической версии как сделать - затрудняюсь ответить...
наверное нужно, чтобы сохранялось всё в пхп, а туда при добавлении страницы в подобный кэш нужно вписывать инструкцию, которая бы проверяла "мёртвость базы данных"...
но тогда одним mod_rewrite не обойдёшься, именно поэтому нужен полноценный модуль, который бы взаимодействовал бы с Друпалом и вместе с тем, результаты его деятельности (статическая версия) были бы полностью автономны...
А как быть с поиском и регистрацией, а так же с другими не статичными вещами?
так ссылки-то сохраняются на подобные страницы и в статической версии... если база до сих пор не работает, то нужно будет перенаправлять на страницу с сообщением причины - почему нельзя добавить комментарий на сайт, также с поиском и со всем остальным...
главное, что информация будет доступна и её можно будет просмотреть... это ведь самое важное, сайт будет доступен 365 дней в году и даже закрываться на техобслуживание может, а пользователи смогут его всё равно посещать... удобно, разве нет?
насчёт динамической информации как таковой, было предложение от Акселя, сделать всё это через AJAX (например, блок рекламных ссылок от яндекса или сапе), а динамический контент от самого Друпала всё равно не будет работать без базы данных, так что это уже не к этому модулю надо обращаться...
Тема кеширования очень интересна. В 6ке добавили кеширование для блоков - если сделать вывод блоков через ajax, то можно их подтягивать достаточно легковесным скриптом и только в случае динамических блоков (можно тоже кешировать, но обновлять при вводе данных) и блоков со сложными правилами доступа поднимать друпал.
Интересно сравнить кеширование в базе и в файлах на большой посещаимости, файловый кеш тоже не резиновый, а база на соседнем сервере дает ощутимый прирост в скорости.
если кеш больших размеров... я бы поспорил... чето никто не делает squid с бекендом на SQL
именно сам кеш. слишком много промежуточных вещей...
если таблицы кеша большие - это жопа...
а при кешировании те же variables тянутся из кеша. уже один "тяжелый" запрос. не проще быстро из файла конфиг дернуть?
Так да... можно взять постгрес, инструменты созданные командой скайпа и линейно масштабировать сами БД и вебсервера. я как то схему рисовал для себя... при наличии мозгов и рук можно размазать и у друпала таблицы по куче машин
Со сквидом понятно, там нужна оперативная выдача результата, а из файла отдать в сокет - это один системный вызов, чем и радует нас nginx.
Кеширование переменных в файле сомнительное преимущество ибо этот файл будет меняться и парситься - тут нужно мерить.
Большие таблицы кеша - можно решить увеличением кэша mysql, но все относительно.
В любом случае наиболее эффективным будет гибридный кеш для статики и для динамики.
Статика как раз не вызывает проблем, а вот с динамикой пропущенной через права доступа (например меню) возникают грабли - в 6ке система меню несколько пограмотнее, но она один фиг отрабатывает в 2 этапа - формирование массива и проверка доступа (для текущего пути).
Вариантов решения действительно много, многие например любят жж-шный memcached - панацеи не существует.
пока что я видел в природе только один наиболее эффективный кеш - который построен на smarty и который не удаляет закешированные странички из кеша пока они не изменят свой контент - то есть кешировать надо все по отдельности или достаточно кешиировать только $node->body и $node->teaser, но не чистить кеш после какого-то промежутка времени - иначе скорость работы такого кеша будет в геометрической прогрессии зависеть от количества страниц сайта - а это уже грубейший дефект разработки
не кури больше
очень странно - почему php разработчики (?) упорно делают вид что не понимают столь очевидные, даже для дилетанта, вещей - скорость работы любой системы не должна в геометрической прогрессии зависеть от количества данных в ней! - Ведь в народе это называется халтура - сделали сайт - все летает - проект сдали, подписали, рассчитались - проект пожил несколько месяцев, статей стало чуть больше минимального порога - и все зависло - ну а с разработчика какой спрос - договор то подписан, расчет получен, - а теперь или платите второй раз уже за оптимизацию и новый сервер или идите лесом, ага? )))))
это не халтура... большие проекты заточенные под общее быстродействие - имеют другой порядок цен.
не 1000-2000 за сайт а на 1-3 порядка больше.
заплати $10000 вместо $1000 за портал города и все модули системы с запросами не по индексам будут заменены кастомными модулями - с несколько ИНЫМИ SQL запросами писанными под задачу....
Друпал по умолчанию имеет херовые выборки с filesort + temporary практически везде где дергается pager_query . Тормозит - пишите постраницные выборки свои. не вопрос. я вот знаю как ускорить... Ктото не знает. Скорость - стоит дорого.
kiev1 я лично сразу предупредил заказчиков что та или иная вещь стоят дороже. не знаю как вы, а я это делаю.
не - не о том я что дороже или нет - я вот о чем: падение быстродействия при линейном увеличении количества документов в базе есть принципиальный дефект разработки - если не умеем делать правильное кеширование - то лучше не делать никакого - тогда не будет этой зависимости
и нельзя-же вслепую рассуждать абстрактно - нужно хотя бы примерно определиться с порядком цифр: - если посещаемость ресурса 500 уникальных посетителей в сутки, добавим к ним то что один просматривает 3 странички, добавим еще проход всего сайта поисковыми роботами - получаем в сутки тысячи 2-3 запросов страничек - тогда при времени жизни кеша 2 часа - сколько может быть страничек на сайте для того что бы они были хоть раз запрошены повторно в интервале 2 часа? (возьмем для примера очень много - 2 часа - в друпале этот интервал начинается с 15-ти минут) - за 2 часа будет запрошено примерно 250 страничек - то есть что бы было запрошено повторно что то из кеша при условии равномерного распределения - а оно равномерно в отношении ботов поисковиков и тогда когда на сайт приходят по ссылкам - то на сайте должно быть не более 125 страниц (!!!) а если время жизни кеша 15 минут? ))) то не более 20-30-ти страниц? )))
таким образом эти способы кеширования подходят для сайтов с количеством страниц не более 125-ти )))) это много или мало? сайт с количеством 200 страниц будет стоить уже $10000 )))
что то тут принципиально не то и что я совершенно не понимаю - почему например этот сайт сделанный на самописной CMS кустарным способом с использованием smarty - не тормозит вообще никогда, а функционал у него как у среднего друпал сайта и более - публикация журналов, подписка пользователя на выбранные журналы, подшивки журналов, различные варианты выборок - по рубрикам, по журналам, форум, рассылка и т.д. - не понимаю - столько лет друпалу а так ничего в плане быстродействия не только не придумали, но и даже очевидно принципиальные вещи приходится объяснять - вон еще модуль boost тоже кеш на файлах уже третий (!!!) год делают и тоже сбрасывается ))) - я пытался объяснить разработчику - но увы - он сказал что правильно делать очень сложно по этому делает откровенную халтуру.
ты другое пойми. друпалы, жумлы. прочие - писаны для "общего" случая....
это как сравнивать почему белаз не ездит с той же скоростью что и феррари. ведь такой балшой и поездатый....
Если ты возьмешь друпал и на его базе напишешь ПОД задачу - это будет летать.
Я сейчас работаю над CMS. Увяз в концепции. Реально увяз. Но надеюсь в сентябре бетку выложу. И результаты тестов.
так вот я и пытался выяснить какой это "общий" случай - оказалось для сайтов с количеством страничек до 100 (!!!) очень грустно.....
эммммм.... эммм.
Друпал 5. Мой второй вариант кеша на файлах с "объектами"... Ноды и выборки ООООЧЕНЬ разнородные. Были ошибки в изначальной концепции изза которых дополнителные кеши были сделаны для модулей типа "афиша". Полет нормальный.
Не совсем я понял ваших расчетов по кешу и прочему... для меня это мистика.
Существую различные технологии кеширования, и приведенный здесь смарти - совсем не панацея, а скорее реальный тормоз. Рендер в смарти очень медленный, кеширование конечно спасает, но когда собирается сложная страница - все пропало... процессор занят парсингом.
Далее нужно понимать, что и зачем кешировать - для поисковиков можно и статику подсовывать, которую набрать в течении дня в отдельный кеш страниц.
Кешировать объекты и большие массивы весьма ресурсоемко - сериализация или парсинг с компиляцией тоже жрут камень.
К чему я это все - давайте лучше обсудим конкретные имплементации кеширования: цели и задачи и только в конкретных областях применения.
Опять же кеш - это не конь в космосе, а какой-то код, который с разными типами данных работает по разному.
Чистка кеша в разных бэках тоже ресурсоемкая операция - кеш страниц drupal.ru в мемкеше занимает 450 метров и по идее его нужно сбрасывать каждые Х часов или сбрасывать как прописано в оригинальной версии кеша - при публикации комента и нового типа материала?
Если админ добавил на сайт новый блок, который выборочно должен появляться, это разве не повод очистить весь кеш?
Публикация нового комента к материалу - разве не должны очиститься страницы трекера и все страницы, на которыч присутствует блок активные...
Проще очистить весь кеш страниц, чем выборочно перелопачивать какие страницы изменились, поэтому Илья и пишет, что от задачи плясать нужно.
Ilya1st - опять абстрактные рассуждения - ясно что не вопрос что как-то работать будет и с 1000 и более страниц - вопрос первый - в загрузке сервера при этом и вопрос второй - эффективность кеша, - если, например, у вас страниц с вложенностью 1 и 2 всего несколько и сайт с невысоким ТИЦ - от ТИЦ зависет то сколько будет заходов на внутренние страницы с вложенностью более 2-х, - то возможно для этих нескольких страниц которые анонсированы на главной и будет срабатывать кеш - то есть вероятность запроса странички из кеша будет выше нуля, а вероятность запроса из кеша для внутренних страниц будет тем меньше чем выше ТИЦ, но и при этом поисковики и спам роботы будут шерстить внутренние странички - обычно роботы грузят сайт раз в 5-10 больше чем просто пользователи - вот тут то вероятность запроса странички из кеша нулевая - так как он все равно сбрасывается раз в 15 минут и сервер должен кроме собственно построения странички - еще и запихнуть эту страничку в кеш - а это часто огромный массив данных - еще и myisam с блокировкой всей таблицы на чтение при этом пододвинут систему к общему затыку - так что кеш тут будет только мешать а не помогать.
у меня тоже на одном сайте - более 18 тысяч статей каждая на 2-х языках, на другом более 3-х тысяч - и тоже не тормозят, сервер отдает до десятка страниц в секунду, но это же не показатель работы кеша! показателем работы кеша будет только одно - отношение количества запросов страниц к количеству повторных запросов из кеша.
andypost@drupal.org - расчеты по кешу очень просты и умозрительны, на уровне простой логики, - если например ведро заполнять водой раз в час, а опустошать раз в 15 минут, то приходя к нему с периодичностью в один час - вы редко когда застанете его полным и сила потраченная на заполнение и опустошение ведра потратится впустую, ничего сложного...
и кешировать надо то что меняется очень редко и ни в коем случае не сбрасывать пока оно не изменится, а то что меняется часто - надо кешировать в зависимости от вероятности повторного запроса - например блоки если они показываются на всех страницах, очень нужно кешировать, но не сбрасывать при этом целые страницы - я последнее время думаю что как раз тщательно продуманное кеширование блоков и видов/таксономий (новостной ленты) - и достаточно для решения пожизненной тормознутости друпала, затыки случаются как раз на этом.
А в случае комментариев - тут все под вопросом - или системе легче вообще без кеша вытянуть все кучкой маленьких запросов или громоздить один гигантский для вытягиваня всей этой кучи из кеша... тут надо исследовать.
а кешировать страницы вместе с блоками и сбрасывание их при первом удобном случае - это принципиальная ошибка, благо в >5 друпале это догадались разделить, хотя я это еще не исследовал.
извините что пристаю - просто люблю когда все правильно там где это жизненно важно.
Поддерживаю дискуссию, ибо она мне не безразлична.
По поводу кеширования блоков - это есть в 6ке и виде модуля под 5ку, мне правда там не нравится реализация по очистке - например модуль кеширует блок персонально для каждого пользователя (предположим это какие-то его оповещения). Соответственно этот блок обновляется только при условии, что пользователь получает оповещение или очищает его (например прочитал входящую почту - нужно погасить оповещение о новой почте). По логике кеширования блока мы имеем сделущий код:
hook_block(op=view)
<?php $block[0]['cache'] = BLOCK_CACHE_PER_USER; ?>
в базе хранится кеш в виде
модуль-delta-theme-lang-uid
и при чисткев нужных местах
<?php cache_clear_all('custom', 'cache_block', TRUE); ?>
но что оно делает - чистит все DELETE WHERE cid LIKE 'custom%' а нуно чистить только для одного пользователя
Соответственно приходится хранитьт этот блок для разных тем, если на сайте позволено менять их, для разных языков
- получается, чтобы очистить блоки одного пользователя - нужно протись по всем доступным темам + доступным языка и все комбинации этих ключей очистить! весьма ресурсоемко!
Страницы кешируются иначе - там ключем является http://sitename.com/node/x причем вероятно из-за того, что для кеш для анонимов, а для них доступна только одна версия темы!
Далее при кешировании можно указать время жизни объекта, но можно сохранить и статически - тогда чистить придется вручную! Вот именно указание очистки раз 12 часов и гворит, что объект тупо будет лежать в базе пока не истечет время или не будет cache_clear_all
> но что оно делает - чистит все DELETE WHERE cid LIKE 'custom%' а нуно чистить только для одного пользователя
ну что я и говорил - элементарные вещи которые понятны любому умеющему логически думать - серьезным разработчикам приходится объяснять на пальцах, и доказывать что нужно или делать правильно или не делать халтуру вовсе что бы не вводить в заблуждение видимостью того что "кеширование" вроде как есть а разобравшись - выходит что вроде как его и нет - обидно ((( хотя конечно модуль boost спасет от дос атаки когда запрашивается одна и та же страничка, но в реальной обстановке когда поисковик шарит по всем страничкам подряд - он только усугубит ситуацию, кстати причиной того что поисковики ходят каждый день скачивать весь сайт целиком - это то что обычно в друпале игнорируется правильный вывод даты создания и изменения страницы - поисковики думают что все страницы меняются каждый день и упорно досят сайт, но тут опять таки все та же проблема - если выдавать правильную дату - то динамические блоки могут не меняться ввиду какого-нибудь кеширования по дороге - или в прокси сервере или в броузере... надо подумать...
пока я не знаю нужно ли кешировать динамические блоки пользователей - обычно на сайте и так полно блоков которые для всех одинаковы и которые можно безболезненно кешировать, с темами оформления - тоже проблема - получается для каждой тоже надо кешировать отдельно - скорее всего в таком тяжелом случае когда и тема для каждого своя и пользователей тысячи - наверно кешировать их не надо, короче - тоже проблема и нужно проявить интеллект в виде IQ...
блин. потому что идея кешировать сами страницы - говно как идея...
кешировать надо куски ДАННЫХ которые кидать уже в шаблон для данного URL
Основываясь на этом считать дату последнего обновления - по последнему обновлению кусочков - максимальную - и кидывать в хидер...
Еп. тут совсем ДРУГАЯ АРХИТЕКТУРА нужна. чем я и занимаюсь в данный момент. с осени мы уйдем с друпала для новых проектов В ПРИНЦИПЕ.
да, конечно куски данных - но тут возникает дилема что "куски данных" - это то что и так друпал берет из базы без всякого кеша, ну разьве что собирание CCK странички с многими полями, но и это не принципиально - то есть даже на drupal.org догадались что без кеша еще лучше чем с таким странным кешем и на этот случай модуль написали
http://drupal.org/project/cache_disable
Small module that disables all caches while enabled.
финиш )))
дату последнего обновления считать по дате смены любого блока - как раз и будет раз в 15 минут - например обновление RSS - то есть это ничего не даст, наверно для поисковиков надо придумать выдачу даты или последнего комментария или если их нет - то дату изменения страницы, хоть это и нарушение поисковых правил.
а другая архитектура это что, извините, означает? Вроде как то что в друпале - CCK - эта идея в последнее время и в комерческих CMS внедряется, и сделано грамотно и красиво - тут претензий нет.
Еще раз повторю - куски не имеют никакого отношения к дате последней модификации материала!
Кстати, никогда не обращал внимание на эти заголовки пока не поставил себе safari - когда возвращаешься в трекер из просмотра материала, то сафари проверяет, не обновился ли он и если что-то изменилось загружает новую страницу, причем это действие по кнопке Назад!
Илья, это мнние очень субъективно! Согласен, что для динамического сайта можно кешировать "кусочки" - темизированные или нет это отдельная песня, а вот для сайтов, которые не очень часто обновляются кешировать страницы целиком - лучше и не придумаешь.
Как я уже писал ранее - нужно указывать, какую стратегию кеширования для какого вида сайтов лучше применять. При проектировании сайта и должно определяться какие блоки, в каких контекстах показываются, когда обновляются. Но самое важное, что узел это и есть страница, а вся шелуха в виде блоков вторична! Ничего не мешает отключать блоки через throttle и кеширование для них не понадобится впринципе.
Для сайтов а-ля Д.ру анонимам и поисковикам вообще эти блоки не уперлись - так что можно их отключить впринципе!
А вот для сайтов представительств, которые меняются пару раз в неделю включаем кеш и отключаем минимальное время жизни - тогда будет сбрасываться весь кеш при добавлении нового материала и возникнет необходимость отрендерить все страницы.
ну у меня стратегия кеширования будет многоуровневая. потом покажу может...
+ при написании модулей - на уровне самих модулей программист будет решать как будут конкретные данные ложится в кеш.
Все хитрее и умнее
Кстати той проблемы что ты испытывал с динамически меняющимися блоками - а иногда это надо - не будет.
Только ради них кеш сбрасывать и тд - это извращение.
конечно на уровне модулей - иначе как система догадается что где обновилось и что где надо поменять.
я вот шел и думал - раз есть в друпале такое поведение кеша когда странички там себе лежат долго пока не добавится следующая, а потом кеш весь обновляется - а вот можно ли сделать еще одну доп опцию - что бы сбрасывался не весь кеш, а хотя бы только странички с вложенностью не более 2-х или хотя бы все что было за последние сутки, а остальные что бы так и были в кеше неизменные - ничего что блоки при этом будут не актуализированы, просто иногда лучше так чем никак или сбрасывать все подчистую, а сбрасывать все например раз в неделю.
и еще по ходу дела нашелся модуль http://drupal.org/project/advcache , интересно что он делает? и вот еще http://drupal.org/project/blockcache
Я об этом и писал, что складывая в кеш мы указываем время хранения (0 постоянное, -1 временное до следущей плановой чистки и можно указать дату, когда чистить)
Делее есть возможность сделать cid (cacheID) нужного нам формата, на примере блока я показывал как cid учитывает блок, тему и язык - для кастомного модуля можно написать свой способ построения ключа. Ну а далее по коду уже чистить то, что нужно!
PS: blockcache интегрирован в 6ку. Второй не смотрел, ибо мне понравился cacherouter
а я поставил http://drupal.org/project/memcache только он странный какой-то и для анонимусов данные обрабатывает и для зареганых что то грузит и запрашивает (видно по /var/log/memcached.log), хотя быстрее вроде не стало
в конфиг написал
$conf = array(
'cache_inc' => './sites/all/modules/memcache/memcache.inc',
'memcache_servers' => array('localhost:11211' => 'default'),
'memcache_bins' => array(
'cache_content' => 'default',
'cache_page' => 'default',
'cache_views' => 'default',
'cache_filter' => 'default',
'cache_menu' => 'default',
'locales_source' => 'default',
'locales_target' => 'default',
'url_alias' => 'default',
'sessions' => 'default',
'term_data' => 'default',
'term_node' => 'default',
'term_display' => 'default',
'term_hierarchy' => 'default',
'term_relation' => 'default',
'node_field_instance' => 'default',
)
);
правильно?
и еще там есть патчи внутри модуля для файлов ядра, а в инструкции не сказано что с ними делать - они вообще нужны?
о, раскочегарился - теперь сайт чуть быстрее работает вроде как...
в общем бросил я эту ерунду и поставил boost - теперь летает еще быстрее
... только вот неприятность - boost тупо делает из всех документов обычные html файлики - заходите например под админом - а видите закешированную главную страничку как буд то под анонимом и другие странички тоже - как 2 года назад он был глючный - так до сих пор более глючного и не работающего и глупо логически построенного модуля я не встречал...
в общем остановился на проверенном годами http://drupal.org/project/fastpath_fscache - он таблицы кеша просто переносит в файловую систему - по крайней мере это хоть какой то выход по разгрузке mysql на шаред хостингах где она часто не умеет даже innodb
Ilya1st - а чем ваше, приведенное в первом посте, решение отличается от модуля
http://drupal.org/project/fastpath_fscache
?
тем что при чистке кеша я не тру файлы... кстати задрали подымать эту ветку, когда я уже выпустил 2 других варианта - продолжение этого и вариант на базе зендовского концепта....
http://www.drupal.ru/node/11392 - это - рабочее продолжение этой ветки
http://www.drupal.ru/node/16554 - концептуально другой вариант кеша.
Это хорошо, что ты здесь ссылки собрал, я тут немного обновил cacherouter
eAccelerator единственный умеет делать правильные блокировки, ну и файловый кеш
для использования memcache лучше использовать для каждой таблицы свой инстанс иначе скорость на блокировках убдет падать
Все эти сложности из-за обсуждавшейся необходимости чистить таблицы по маске (wildcard=true)!