Добрый всем день!

Постараюсь понятно объяснить суть вопроса.

При записи нового кэш фаила его название состоит из закодированного уникального имени или же урл... 
При следующем обращении проверяется не истек ли его срок, если да то удаляется и создается новый.
При апдэйте данных удаляется кэш фаил, например в зенде по определеным тэгам.


А можно ли кэш ид составить из данных которые передаются блоку?? 

Например:


ну и дальше проверяется если ли такой кэш фаил или нет, тоесть если данные изменятся то и фаила не будет.
Получается авто создание нового кэша сразу же после изменение данных, при этом избавляемся от удаление при изменения данных.
А удаление старых делать например через крон или как-то по другому по истечению их срока.


Буду рад услышать ваши мнения, советы... просьба ногами не бить =)) кэширование начал изучать недавно и вроде все понятно кроме этого вопроса... 

спасибо!


Это сообщение отредактировал(а) Shogun - 3.7.2010, 14:23

можно. Вот только осмысленность этого действия становится менее определенной ;)

Кэш нужен, чтобы не грузить лишний раз базу, а просто выдать по имени уже готовый результат. Если для получения имени закэшированной страницы придется сначала добывать данные - надобность в кэше становится не настолько очевидной   

я бы рекомендовал бы имя файла хранить кешем

имя файла складывать и стокового значения.
Допустим унас есть запрос к бд 

$cache_id = md5('select * from users'); 

этим мы получим уникальное значение хеша и имя файла.

Суть в следуйщем сперва делать перед запросом проверку если такой ид кеш файла в папаке проверять дату создания файла если она создана 3 дня назад то использовать бд и перезаписывать кеш файл.

$cache_id = md5('НЕКОЕ ЗНАЧЕНИЕ ПЕРЕМЕННОЙ');

 Искать этот $cache_id в папаке кеша если нашли то проверяем дату создания файла
 если не просрочен файл указаному лимиту то читаем файл получаем данные.

 Если файл просрочен то удаляем его и выполняем код программы скажем выборку БД
 Выбрали Все данные зделали serialize записали все в файл под именем $cache_id.
 Тем саммым при следуйщем обрашение такого цикла данные будут братся из кеша.

Добавлено через 1 минуту и 24 секунды
я кстати плюнул на каширования уже давно и не вижу в нем нечего полезного если данных с бд дергается мало.

Sanchezzz, ksnk - а разве кэширование делается только если используется БД?? 
Если делать $cache_id = md5('select * from users'); это тоже самое что использовать md5(урл). 

"Искать этот $cache_id в папаке кеша если нашли то проверяем дату создания файла
 если не просрочен файл указаному лимиту то читаем файл получаем данные." - да, и если кэш создан в 12:00 а данные изменены в 12:01 то обновленный вид придется ждать по окончанию лайф-тайма.

А если будет каш ид от параметров(которые кстати тоже можно получить от закэшированных запросов - но это уже другой вопрос) то обновление будет сразу и не придется самостоятельно удалять кэш при обновление данных.

понимаете о чем я??

При обновлении этот файл должен быть удалён.


Кто тебе сказал такую чушь? При обновлении этой темы у тебя в URL параметры какие-то меняются?

Если бы Вы прочитали перый пост то поняли что я от этого хочу избавится, а удалением займется отдельный скрипт.


URL - тут не причем так как кэшируются отдельные блоки.

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

Только нужно проводить получение рессурсов через какой-то центральный класс, чтобы выглядело поприличнее

imho, обычно, любой кэшируемый рессурс содержит список имен "зависимостей" - список используемых таблиц базы данных, файлов и т.д - простой массив строк. Отдельный класс хранит времена последнего изменения сущьностей из всего списка "зависимостей" приложения и умеет выдавать максимальное время изменения по списку. Время создания рессурса не должно быть меньше этого времени.
При любом изменение данных, одновременно обновляется время изменения по списку "зависимых" элементов. Так получается достаточно просто реализовать кэширование.


Это сообщение отредактировал(а) ksnk - 3.7.2010, 17:21

Я вижу, что ты кешируешь результат работы шаблонизатора (после подстановки всех переменных). Да, в таком случае это использовать можно. Только тут выиграть-то почти ничего не выйдет.

Во всех остальных случаях твой подход не работает. Поясняю ещё раз: ты видишь в URL thread id? Он меняется? Нет. Входные данные SQL-запроса для выборки сообщений меняются? Нет. А список сообщений меняется? Да.

ksnk
1.Сброс кэша - следить за этим и не придется, через крон например будет скрипт который этим и займется. 
2.Cписок имен "зависимостей" - так получается что каждый блок нужно добавить в этот список? а при большом проекте как быть?? и если я это правильно понял то получается чтото аля тэги в Зенд монстре?? 


Kano
1.Да не обязательно результат работы шаблонизатора, это определенный функционал.


Ну никак не могу понять что ты хотел этим сказать, точнее это то же самое что и я думаю. 
URL может менятся или нет это не важно, входные данные могут менятся или нет тоже самое, главное тут какие выходные данные будут, если они изменились то собственно и обрабатываем их и записываем в новый кэш, а если нет то ничего не делаем и выводим сразу из кэша.

тогда смысла нет в таком кэше. получение данных - самое узкое место в системе. Есл это не узкое место - надо менять шаблонизатор или не думать пока о кэшировании - и так все в порядке ;)

ksnk


Ну а Смарти тогда для чего кэширует??

Imho, смарти думает про себя, что он большая и умная система(достаточно хотя бы на размер дисрибутива глянуть). Ей не хватает разве что умения завязывать шнурки... 
Шаблоны смарти - свой собственный язык со своей собственной логикой. Шаблон, при должном умении, можно навернуть так, что он будет порождаться очень долго, так что кэширование страниц там было логичной, но несвойственной шаблонизаторам функцией.
А насчет точки принятия решения о кэшировании - для шаблонизатора не такой большой выбор этих точек. Либо по входящим данным до построения страницы, либо после построения страницы. Если внутри шаблона своя нетривиальная логика - остается только последняя точка. А в этой точке уже все время потрачено и больше экономить не на чем...

Откуда ты узнаешь, что выходные данные изменились? 

$cache_id = md5(serialize($params));

И если файла с таким кэш ид нет то понятно что изменились данные. элементарно ватсон... 

Тогда так: ты же сам сказал, что хочешь избавиться от удаления файла после обновления:

Откуда тогда твой "отдельный скрипт" узнает о том, что конкретный файл содержит неактуальную информацию?

Когда эта цепочка уже закончится?