Статья вот тут: 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(); например еще 

Можешь привести код работы функций ob_start() и ob_end_flush() и как я понял, строку 
Print $content; - ты просто написал для примера?

Добавлено @ 12:22 
Всем спасибо разобрался

Да. Это любой вывод в STDOUT.

добавлю свои 5 копеек


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

Это же касается "частичного" кеширования страницы ("Тут надо несколько усложнять, и делать кэш частичный, т.е. все что было описано выше надо проделать только над той частью, которая генерирует основной контент").


Ну и главное:
есть тот же Смарти, который замечательно решает все эти вопросы. Как кеширование отдельных шаблонов, так и запрет на кеширование отдельных частей закешированных шаблонов.

Mal Hack, ИМХО для твоего уровня статья слабенькая... все очень поверхносно, не описаны механизмы кеширования в Smarty, PEAR Cache, PEAR Cache Lite. еще было бы очень интересно посмотреть на сравнение производительности при использовании различных инструментов кеширования...

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

где статью-то можно почитать?
Ссылка перенаправляет на http://forum.vingrad.ru/faq/topic-82069.html , где одни комментарии.

Блин, опять админы со ссылками мутят...
http://base.vingrad.ru/view/2854-Psevdo-ke...anie-na-servere
http://www.base.vingrad.ru/view/2854-Psevd...anie-na-servere

может не к теме немного но вот мой велик на кеш данных:



как пользоватся:


Минусы и плюсы в этом методе решать вам. 

Это сообщение отредактировал(а) Sanchezzz - 30.6.2009, 07:44

а где статья?