Всем известно, что для снижения нагрузки на сервер принято использовать статичные странички. Но, в сложных проектах, где используется динамическое обновление контента (форумы, новостные сайты и т.д.) трудозатраты программиста на генерацию и обновление статических страниц очень высоки и, порой, эта технология не позволяет достигнуть "настоящей интерактивности".
Лень - двигатель прогресса, говорим мы и коллективным разумом пытаемся придумать системку, для снижения количества запросов к базе данных, открытий файлов и т.д.
Пока у меня созрела достаточно простая идея, как это все реализовать. Итак.
Условимся, что у нас есть основной скрипт, к которому, в зависимости от query_string подключаются различные модули и с этими модулями совершаются какие-либо действия (для ясности рассмотрим урл на дефоруме: http://deforum.ru/cgi-bin/ubb61/ultimatebb.cgi?ubb=newtopic&f=3 - здесь модуль - newtopic). При первом вызове этой страницы в папке с закэшированными страницами создается файл вида "ultimatebb.cgi?ubb=newtopic&f=3.tmp". Заходит второй пользователь на эту страницу и она уже берется из кэша. Если меняется что-то на этой странице (например дизайн всех страниц), то кэш просто-напросто очищается...и все идет по-новой.
Это достаточно простая схема, может у кого есть какие предложения по усовершенствованию?

Зачем это надо? Предположим, что у нас имеется достаточно мощная система типа пхп-нюки и нам нужны ее возможности, но не нужна её нагрузка на сервер. Если нужно реализовать всё на статичных страничках, то придется придумывать "правила" регенерации для каждого модуля и для каждого вида страницы, что достаточно муторно и скучно.

а апача сама не умеет разве ? [img]images/smiles/icon_wink.gif[/img]

хотя … погоди-погоди ….
а разве юбб не на файлах построен ?
тот , который на iXBT например …
он ведь именно так себя и ведёт - статичный файл .хтм обновляющийся по мере надобности скриптом.
просто дописывается и всё.
то есть, все клиенты к нему и обращяются при просмотре.
это у них называется оптимизация под тысячи юзеров.
а что если слегка упростить себе работу, имея инфу как в БД так и в файлах ?
то есть, после добавления в БД постинга, например, генерится хтм файл. и кладётся куда нить.
потом, когда приходит юзер, смотрит на файл, он мог обновиться, а мог и нет. то есть, мы используем его как кешь, поэтому нам не надо прописывать мету, на неокончаемый экспаир. то есть этот файл - всегда старый.
получается, что юзер его запрашивает каждый раз.
потом … генерить эти файлы можно по команде с администрации, в случае обновления дизайна например, это займёт часок, но - окупится с лихвой.
почему есть смысл в хранении инфы как в БД так и в файлах ?
что бы не парсить файлы при обновлении. просто генерить новые.
потом, что будет, если юзер придёт на ещё не закешированную пагу ? он попадёт на 404, который его перенаправит на скрипт, который пагу сгенерит, если надо. а если не надо - то на стандартную 404.

ну это всё мысли вслух, собственно - абстрактные, да ? [img]images/smiles/icon_smile.gif[/img]
если кто то уловит связь в них - надеюсь разьяснит тем кто не смог, и их тоже можно понять [img]images/smiles/icon_wink.gif[/img]

хммм …. интересно ….
я сегодня не вносил пароль на форуме … а вчера потёр куки …
хммм …. интересно [img]images/smiles/icon_smile.gif[/img]
щя ещё кой чё проверю [img]images/smiles/icon_wink.gif[/img]

Intelligent
а апача сама не умеет разве ?
Умеет, но плохо [img]images/smiles/icon_sad.gif[/img]
а разве юбб не на файлах построен ?
тот , который на iXBT например …
он ведь именно так себя и ведёт - статичный файл .хтм обновляющийся по мере надобности скриптом.
просто дописывается и всё.
то есть, все клиенты к нему и обращяются при просмотре.
это у них называется оптимизация под тысячи юзеров.
а что если слегка упростить себе работу, имея инфу как в БД так и в файлах ?
то есть, после добавления в БД постинга, например, генерится хтм файл. и кладётся куда нить.потом … генерить эти файлы можно по команде с администрации, в случае обновления дизайна например, это займёт часок, но - окупится с лихвой.
Цитирую себя любимого [img]love.gif[/img]
Предположим, что у нас имеется достаточно мощная система типа пхп-нюки и нам нужны ее возможности, но не нужна её нагрузка на сервер. Если нужно реализовать всё на статичных страничках, то придется придумывать "правила" регенерации для каждого модуля и для каждого вида страницы, что достаточно муторно и скучно.
Далее...
то есть, после добавления в БД постинга, например, генерится хтм файл. и кладётся куда нить.
Как я уже писал, надо предусматривать правила регенерации, а это может вызывать проблемы с перекрытием имен переменных и т.д., т.е. гимора - очень много.
потом, что будет, если юзер придёт на ещё не закешированную пагу ? он попадёт на 404, который его перенаправит на скрипт, который пагу сгенерит, если надо. а если не надо - то на стандартную 404.
Нет, ссылка имеет постоянный вид - http://deforum.ru/cgi-bin/ubb61/ultimatebb.cgi?ubb=newtopic&f=3 просто скрипт проверяет наличие файла кэша для этого значения query_string.
В этом - отличие настоящей статики от "псевдостатики". Прирост в производительности происходит только от того, что не происходит никаких операций с БД, с файлами на сервере и т.д. - только считывание файла кэша и выдача его браузеру.

Проблема в предложенном способе - "правила регенерации" слишком сложны.

Что значит "посмотреть не изменилась ли страница, пора перегенерировать"?

А как я собственно это узнаю без полной генерации страницы с нуля и сравнения результата с тем что лежит в кеше? Ответ "при изменении страницы установлю ключик где-нить или сразу создам новый экземпляр в кеше" не кататит, потому что данные используемые в странице могли быть изменены в десяти местах, и использоваться еще в сотне страниц, не менять же из-за этого сотню страниц, да и где хранить инфу что надо поменять? [img]images/smiles/icon_smile.gif[/img] Придется создавать матрицу сопоставления данных и страниц и по ней менять кеш. Представьте что этих абстрактных данных сотня другая, а страниц тысяча, хорошая матрица выходит [img]images/smiles/icon_smile.gif[/img]

Может меня глючит?

Griman, ты гонишь - "использоваться еще в сотне страниц", это тебе не БД, из которой делается выборка. Как раз наоборот ВСЕ страницы уже сгенерированны из БД. А обновление по ключу - правильное решение.
Только предложил бы "обратный" ход. Новая страница при генерации ложится в кэш. Пользователь запрашивает страницу, проверяется ее на обновление, если обновление было - мувту. и все..

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

"проверяется ее на обновление" - что это? [img]images/smiles/icon_wink.gif[/img]

Griman, ну это так сделанно сейчас. а почему бы не написать - собщение ..датое? короче все зависит от того, что потребно, как сформулировать задачу. я думаю, что совсем не обязательно знать, если я открою топик прошлогодней давности, что у меня сейчас 600 постингов. Тогда для меня постинг был 60, например... Короче, это не та инфа, которая нуждается в обновлении. Надо просто правильно ставить задачу и решать ее оптмальным образом.

Long
Вывод - кеш подходит только для простых страниц с минимальным набором динамических данных (например статья в онлайн СМИ), в противном случае "правила регенерации" сложны и их соблюдение может занять время большее чем непосрдественно генерация страницы "налету". [img]images/smiles/icon_smile.gif[/img]

Griman, я согласен только с одной твоей мыслью, которую и сам говорил всегда - для каждого случая свой выбор. Но на самом деле, что мешает тебе комбинировать методы? [img]images/smiles/icon_wink.gif[/img]
На примере этой же страницы - большую часть - посты - делаешь статикой (на постоение ее уходит больше всего времени), а динамические элементы в виде количества постов оставляешь. И еще раз - кому интересно читая прошлогодний мой пост, сколько у меня сейчас сообщений? На самом деле, интереснее, сколько постов я сделал к уже запощенному посту. Интересно, я сам понял, что сказал? [img]laugh.gif[/img]

Вообще, вы знаете, мне кажется кэширование гораздо интереснее, нежели статика.
Что касается этой конференции. Если вы заглянете в любую старую тему, то там вы увидите современное количество постов любого участника. Это связано с тем, что кэш конфы неоднократно чистился. А сама конфа устроена таким образом, что все данные пользователя берутся из его профиля, а не из БД для топика.
В чем плюс кэширования? Рассмотрим дефорум. Есть очень старые темы, которые практически никогда не просматриваются пользователями. При каждом изменении дизайна (а они происходят достаточно часто) в случае ЮББ 5.74 пришлось бы регенерировать абсолютно все топики, что достаточно муторно и может приводить к различным сбоям и ошибкам. Плюс излишняя нагрузка на сервер тоже скажется. В случае с кэшем необходимо только удалить файлы, что, несомненно, значительно быстрее.
Griman
Вывод - кеш подходит только для простых страниц с минимальным набором динамических данных (например статья в онлайн СМИ), в противном случае "правила регенерации" сложны и их соблюдение может занять время большее чем непосрдественно генерация страницы "налету".
Вы противоречите самому себе [img]images/smiles/icon_smile.gif[/img]
Все зависит от стиля программирования. Лично я собираю все в одну переменную и потом делаю вывод этой переменной на экран. Ничего мне не помешает записать это в файл. Таким образом при первом обращении к какому-то блоку программы происходит две операции: запись кэша и вывод на экран.
При повторном обращении уже происходит только чтение из кэша.
Вот и вся любовь [img]images/smiles/icon_smile.gif[/img]

Здается мне, что мы просто не понимаем друг друга [img]images/smiles/icon_smile.gif[/img]
Я лишь хочу определить, что понимается под фразой "повторное обращение". Почему-то никто ее не рассматривает подробней.

Давайте на примере:
Сайт "газета.ру"

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

Реализация?

Сходу могу предложить разбить страницу на блоки, каждому сопоставить свое включение SSI. Включения статичны и являются собственно кешом.

Страница статьи таким образом выглядит из набора независимых включений, и собирается быстро. Первых и повторных обращений нет, все равны. Меняются только блоки включения.

Предложите свой алгоритм.

на сегодняшний день, существует 3 вида кеша.
1) клиентский в бравзере, истекает по мете.
2) прокси, истекает по мете, или по просьбе ctrl+F5
3) apache-вый.

1-ый и 3-ий нас не устраивают. на нужно самим за этим следить. предлагаю обратить внимание на проксовый кеш.

страница собралась из ССИ, или базы или файлов.
у нас есть ХТМЛя, которую в принципе можно считать за кеш.
если она есть - то её клиент и забирает. если её нет - извените, надо новую делать и тогда забирать. если она устарела - надо её либо стереть что бы по новой собирать, либо сразу собирать. так ? это наша идея фикс ?

как реализовываем ? вариантов несколько.
начну с фантастического [img]images/smiles/icon_smile.gif[/img]
демон, следит за страничками. имеет собственную базу данных страниц существующих, и их срока годности. в случае истекания срока годности - мочит страничку. и серверу приходится её по новой собирать, и прописывать в базу демона, новый срок годности.

другой вариант :
таблица, простая и лёгкая, без демонов.
при запросе серверу о страничке - сначала лезем в базу.
истёк срок годности - стираем страничку, делаем новую страничку, записываем её срок годности в базе, и … отдаём клиенту собранную хтмлю.
ну и если срок годности не истёк - редирект [img]images/smiles/icon_smile.gif[/img]

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

плохая идея [img]images/smiles/icon_smile.gif[/img]
а как собственно устроен кеш апачи ?
может разгадка есть, но плохо реализованна ? может её надо добивать, а не решать кеш-вопросы скриптами, которые по определению не могут быть быстрее самих модулей апачи ? а только медленнее или столь же быстрыми.

Intelligent
Если мы используем понятие "истекания срока годности" то речь идет уже не о рилтайм сайте. Но как вариант использовать можно... [img]images/smiles/icon_smile.gif[/img]

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