Я уже давно думаю ввести в своем движке кэширование некоторых данных выбираемых модулями. Вот думаю, если например есть у нас страничка, на которой выбираются некоторые данные из БД. Потом из них генерируется XML... вот я думаю, если кэшировать XML, а потом просто читать его из кэша если данные не менялись... мне кажется тут много чего можно сэкономить?

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

Wowa, это пройдет в том случае, если на странице нету меняющегося контента (типа голосования и т.п.).

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

А дальше? Интерактивность-то всё равно существенно понизится!
Я сейчас тоже CMS пишу. У меня такая мысль.
Для каждого модуля делать в его конфиге значение, определяющее его степень интерактивности. Скажем, N секунд. Допустим, юзер зашёл на страницу. Output модуля ложим в его кеш-файл. Заходит другой юзер. Смотрим, когда создавался кеш. Если это время + N > текущего времени, то берём данные кеша. Если нет, опять выполняем и кеширеум.

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

Других путей я и не вижу.

На чем можно сэкономить:
1. Кеширование запросов к базе (если используется способ хранения MyISAM, то можно держать время последнего изменения для каждой таблицы).
2. Кеширование шаблонов. Будет список модулей, для которых это разрешается (уже отпарсеный HTML будел лежать в файлах).
3. Кеширование на клиенте (выдавать выдавать и принимать в заголовках ETag).

http://xpoint.ru/know-how/Articles/SlezhenieZaKontentom

В свое время писал клас абстрактной БД, требовалось чтобы приложение работая через этот клас вообще не заботилось о том с какой БД оно работает. Требовалось поддерживать MySQL, PostrigeSQL, XML, XLS и еще пару специфических.

Но теперь к сути: также решил организовать некую систему кеширования.

Идея состояла вот в чем: при обращении к класу по методу select и указанием параметров клас проверял наличие скешированого запроса и отдавал его исключением был запрос с рандомайзеной сортировкой он вновь обращался к БД (но возможно лучше будет и его кешировать, а точнее кешировать результат без сортировки и рандомайзить его). Но при изменении данных (Insert Update) кеш затрагиваемых таблиц просто удалялся, что гарантировало последующее обращение к БД за обновленной информацией.


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

rMaveric, 
Какими методами использовалось кеширование?
Интересно было бы взглянуть на класс.

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


А насчёт кэширования страниц я подумал, что прикольно было бы кэшировать узлы дерева, которые не меняются. Хотя думаю, что с ДОМом будет при этом заморочка. Там легче обьекты напрямую собирать. ХМЛ вообще очень удобно кэшировать. Вопрос только где, в памяти, или базе.