Думаю уже второй день над тем как устроить кеширование страниц в своей CMS. Мне пока на ум приходят лишь несколько возможных путей решения поставленной задачи.

Одна из этих задач реализуема довольно просто, но мне кажется что в данном случае могут появиться подводные камни.
Алгоритм стостоит в том чтобы вычислять уникальные URL и на их основе сохранять скомпилированные шаблоны страниц, потом при запросе данного URL выдавать пользователю уже сохраненную в кэш страницу. Правда при таком подхоже могут возникнуть проблемы. Например при активном использовании динамических модулей, таких например, как пользователи. URL может оставаться одинм и тем же, если конечно не пустить в дело ссылку на сессию пользователя, что не очень удобно при использовании mod_rewrite, а имена пользователей, например, не будут меняться
Еще один камень на нашем пути - "баннеромешалка" (правда нелепо звучит?). Каждый раз может выдаваться разный код для показа - в этом случае закешировав страницу мы будем вынужены отказаться от динамического показа баннера. Хотя, если к примеру сделать линк на динамический показ баннера, типа http://www.example.com/get_random_banners.php, то эта проблема будет решена. Но это все же не луччший выход, ИМХО.
В данном случае я вижу такой путь решения проблемы: использовать спец. вставки в скомпилированных шаблонах в которые будут подставляться динамический данные за которыми сложно уследить. Это конечно не полное кеширование, но согласитесь что это не весь тот процесс, от выборки из базы, исполнения бизнес логики программы и компилировнаия шаблона
Однако стоит выразить свое недоверие к тому факту, что в данном решении, обновление шаблонов будет происходить либо по заданному графику, либо при выполнении сценария, который будет указывать в конф. файле на то что страницы необходимо обновить.

MM: Так же необходимо учесть и то, что при кешировании шаблонов желательно отречься от кеширования страниц, на которые передаются данные методом POST.


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

ММ: Как строить алгоритм использования сегментов шаблонов содержащихся в кеше, каждый наверное для себя представит по своему, но суть остается таже (поправьте если я ошибаюсь).
Так же смотрим на первый ММ.

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

Всем спасибо за внимание.

насчет первого варианта: а что если сохранять не html, а php страницы? т.е. делаем статичным все кроме определенных блоков (напр. блоков баннеров, там оставляем php)

IZ@TOP
Zend Optimizer разве не это делает?? он кеширует запросы и сохраняет их в памяти, чтоб быстрей отдавать результат пользователю. Плюс скрипты весят в оперативке и не обрабатываются интерператором каждый раз. Памяти жрет больше, зато в итоге работает быстрей. Да еще и код от чужих глаз спрячет.

Я вот тоже думал над этим...
Для себя самое оптьимальное решение такое.
Шапка и низ - хранятся отдельно в html'ках. А на место контента подставляем данные из кэша. УРЛ - страница.
При этом когда динамически страница изменяется, то обновляем кэш.
При этом, к примеру индивидуальная страница пользователя (как тут к примеру Профиль) не подлежат кэшу.

Mal Hack, я наверное буду использовать второй вариант. ИМХО удобно, пусть немного и сложновато, но как я понял большинство пришло примерно к той же концепции что и я

IZ@TOP, а стоит ли вообще овчинка выделки?

Есть более простые способы ускорения работы сайта: например, гзипование, оптимизация графики, оптимизация хтмл-кода.

Дело в том, что кэширование имеет смысл только тогда, когда время генерации страницы сопоставимо с интервалом между посещениями. Разумеется, в предположении, что это время находится в разумных пределах - ну, скажем, меньше 10 секунд. Я думаю, реально оно у тебя гораздо меньше. Вот и посуди. Если трафик равномерно распределен по времени, то даже при такой черепашьей скорости сы сможешь обслужить 86400 / 10 = 8640 запросов в день. Учитьвая, что в пиковые часы нагрузка может значительно превышать среднесуточную, делим грубо на поправочный коэффициент 2, и получаем приведенную нагрузку 4000+ хитов в день - это такое количество посещений, при котором даже в пиковые часы у нас при заданном времени выполнения скрипта не будет накапливаться очередь.

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

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

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

По идее можно ещё запросы SQL кешировать