Кэширование

2. Сами подумайте, как часто вы будете менять дизайн.

ну я не спец по высоконагруженным системам но свое мнение выскажу=))

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

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

Или как вариант еще на стадии проектирования продумать модульную сетку, вычленить из нее блоки в которых присутствуют объемные операции с базой, и далее кешировать только эти блоки.

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

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

Еще замечу, если есть доступ к настройкам MySQL, то он тоже самостоятельно способен кешировать запросы. :)

я пробовал и так и так,

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

если есть динамика - то вариант кешить целиком страницу не прокатит. и тогда кешить именно кусками прийдется. можно совместить 1 и 2

хотя, все это очень индивидуально, зависит и от вижка, и от рук, и от железа.

...сейчас у меня баннерокрутилка+посещаемый сайт около 3х млн обрщений в сутки динамики ,которую нельзя закешить , - не напрягаясь без всяких кешей отстреливаетя нгинкс +пых без апача

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

_savit добавил 16.12.2008 в 14:57

да в том то и дело что обычно я часто что-то меняю ж)))

у меня есть один сайт где страницы полностью кэшируются и их реально очень много ... захотел вчера поставить на сайт Google Analitycs, но как подумал что придется весь кэш убить чтобы вставить в код кусок яваскрипта сразу расхотелось ;)

а может кешировать резалт от запроса? =)

ну это и есть вариант №1 про который я писал ... кэшируется только результат запроса

что-то типа такого

$result=array();



if ( $data = $cache->get('result') ) 

{

   $result=unserialize($data);

}

else

{

   $query=" ... ";



   $r=mysql_query($query);



   for($i=0; $i<mysql_num_rows($r); $i++)

   $result[]=mysql_fetch_array($r);



   $cache->save(serialize($result),"result");



}

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

Кєширование страниц / блоков дает дополнительную экономию, нет повторной генерации самого html, здесь основной вопрос - сколько будет создаваться файлов. Смотрите в сторону memcache.

я сделал похоже - высоконагруженные куски кода внутри страниц кешируются в отдельные файлы.

т.е. например на главной блок новостей кешируется в один файл, а блок анонсов в другой.

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

при этом можно разбить кеш по другому: например закешировать header и footer в отдельные файлы (всего 2 файла будет), а контент страниц в отельные свои файлы и собирать их при генерации страницы. И, например, если в шапке что то изменили - просто удаляем cache/header.html, либо он сам перепишется через какое то время (если изменения не критичны).

Я выбрал бы второй вариант. Не думаю что дизайн придется так часто менять.