Статья вот тут: http://vingrad.ru/PHP-ART-003003
Обсуждение ниже.

Mal Hack, 
Мало, ни memcache, ни Pear:Cache толком ничего нету  

Это несколько другое. PEAR я не воспринимаю в принципе. 

Не мог бы малость просветить по этому поводу?!

Mal Hack, такой подход естественно не имеет смысла. Имеет смыл когда контент генерится блоками, и затем эти блоки кэшируются... Лично у меня такой подход... 

Да, это хороший подход. Но не сразу люди видят, как все на блоки разбить, а статья должна дать в данном случае общий алгоритм.
Кстати на счет блоков, не всегда факт.. К примеру есть блок верхней панельки, который зависит от пользователя. Как быть в таком случае?
Да, можно разбить  все на более мелкие блоки, но ИМХО, это не удобно. 

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

-=Ustas=-, 
http://ee.php.net/memcache
Если коротко: хранение данных в памяти, может использоваться как кеширование. Подробнее по ссылке выше.

Туда же:
http://ee.php.net/apc
http://ee.php.net/shm
http://pear.php.net/package/Cache
http://pear.php.net/package/Cache_Lite 

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


Ну это смотря как посмотреть, и смотря какой подход использует сам программист. Например у меня свой класс шаблонов (простой, но работает так как мне надо), он у меня работает с html-шаблонами, в которых хтмл и дескрипторы вида {PANEL}. Т.е. у меня идет блочное формирование, поэтому проблем и запутывания абсолютно нет, все ясно и понятно  В кратце, допустим есть страница:

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


Конечо, такой подход может показаться на первый взгляд немного муторным, но я уже привык и практически не замечаю этого 
Зато сервак разгружает очень даже заметно! 

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

Добавлено @ 08:26 
Виноват, не страница а блок. 

Я же упомянул об этом  Такие блоки в кэш не помещать просто напросто.

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

Сейчас появилась интересная тема использования перенаправляющих легких HTTP серверов типа nginx. Советую почитать по этой теме. 

Форумчане, по поводу кеширования, скажите пожалуйста, можно ли перехвотить вывод в стандартный поток в php? Ну тоесть перехватить данные которые уходят при помощи вызова функций print и echo ? 

Empirik, а я о чем в статье писал???

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

Стандартный процесс кеширования


А хотелось бы что бы кеширование производилось следующим образом 

Empirik, читай статью внимательно. Я писал именно о том, КАК ПЕРЕХВАТИТЬ САМ ВЫВОД...
Никаких переменных у меня там нет.

Empirik, читай про
ob_start();
ob_end_flush();
ob_list_handlers(); например еще