Глобальный кеш

Всем привет!
Уже несколько месяцев не дает покоя одна идея. Сделать что-то(хак, компонент...), который позволял бы управлять отображением и параметрами страниц. Виной всему то, что где то услышал про вордпресс и его id страницы. Впоследствии, правда оказалось, что это просто статистические страницы, которые можно создать в вордпрессе. Но идея уже появилась и не дает покоя.
Итак, вкратце, какой бы компонент или модули на странице не работал — в результате имеем уникальную страницу. Уникально по крайней мере uri. И на выходе каждую страницу заносить в отдельную базу. И сделать так, чтобы можно было для этой страницы переопределять seo-параметры. Кроме того, иметь возможность для каждой страницы назначать показ модулей(индивидуально для страницы).
То есть, дать возможность индивидуализировать каждую страницу.
В какой-то мере, подобное уже реализовывал в seo-pages.
К тому же сегодня оценила мысль. Сделать глобальный кеш. Вот накидал на коленке. В прикрепленном файле слегка видоизменный индексный файл под эту задачу. Суть — кэшировать не отдельно компоненты и модули, а полностью страницу. Потестируйте на локалхосте. Не советую ставить на рабочие проекты. Там нужно ещё многое доработать. Служебные страницы(добавление статей, постов...) тоже кэшируется. Задача, отсечь кэширование служебных страниц и в привязке к вышеуказанным id страниц, дать возможность управления кэшированием. Файл при грубом испытании уменьшает нагрузку на БД и время генерации страницы уменьшается в 5 раз. Интересно однако.
Помнится SJen занимался кэшированием, суть может быть была такая же. Не знаю.
Общей картины в голове пока нет. Поэтому хотелось бы услышать мнения заинтересованных и просто критиков. Стоит ли и нужно ли?

Как то странно подходите к кешу. С перебором что ли. CMS нужны для управления генерацией динамического контента, а если потом его опять делать статичным зачем вообще CMS? Статические сайты можно по шаблону в блокноте делать. Утрирую конечно, но и Вы тоже. Это все касательно глобального кеша. А по индивидуализации страниц идея хорошая, только архитектурный подход к этой задаче должен быть не в виде хака. Подобные возможности нужно изначально закладывать в системе.

Марат, а то что одна и та же страница может выглядеть по разному не просто у разных групп юзеров и просто юзеров, а конкретно у каждого отдельно взятого гостя, вы учитываете?

Как то странно подходите к кешу.

Не соглашусь.
Подход может быть странный, но важнее результат. Главная страница без кэша модулей — запросов к БД — 55, время генерации — 2с. С кэшем модулей — запросов 48, время генерации — 0,7 с. И с приложенным индексным файлом — запросов 8, время генерации -0,07с. Впечатляет? Это я сейчас потестировал немного тщательнее. Тут выигрыш и не 5(как писал) раз, а гораздо более. А как важно время генерации, тут думаю, объяснять не нужно. Я уж не говорю о нагрузках на БД и письмах счастья от хостера.

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

Ну, это вы сильно утрируете. Тут ведь не полностью статичный контент. А временно статичный, в общем задача любого кэша в этом и заключается.
Вдобавок, приложенный вариант без лишних запросов к бд. Но можно добавить 1 запрос и дать для каждой страницы возможность задать время жизни кэша.
Но, спасибо за участие. Истина рождается в споре

Марат, а то что одна и та же страница может выглядеть по разному не просто у разных групп юзеров и просто юзеров, а конкретно у каждого отдельно взятого гостя, вы учитываете?

Да, вот об этом я не подумал ) Но можно обойти, думаю. Генерировать отдельные страницы для разных групп. А вот разный вид для разных пользователей и гостей — это вы о геолокации? Или о чем то другом?

А сайт реально летает

можно добавить 1 запрос и дать для каждой страницы возможность задать время жизни кэша

Это можно и без запроса делать, достаточно проверить дату последнего изменения файла в котором хранится кеш.

Это можно и без запроса делать, достаточно проверить дату последнего изменения файла в котором хранится кеш.

Вы неправильно поняли. В файле так и сделано. Имел ввиду, чтобы можно было задать для каждой страницы отдельное время жизни кэша. По умолчанию, допустим 1 час. Но можно для каждой страницы определить отдельное время. Для страниц, где контент часто меняется — 10 минут, где вообще не меняется — 7 часов. Пример. Для этого нужно писать в БД.
Файлы кэша пишутся в ту же папку, куда и остальной кэш. И можно просто при добавлении контента обновлять кэш целевой страницы. Где то в системе даже вроде видел сброс кеша при добавлении чего-то.

Сложность в том что у каждого пользователя своя страница. Например у Вас сейчас даже ссылки на профиль кешируются и т.п. Это перебор. А если кешировать страницы с учетом сессии то смысла в таком глобальном кеше вообще нет.

Считаю что оптимально кешировать на уровне модулей и компонентов. Глобальный кеш утопичен и не масштабируем.

Но можно для каждой страницы определить отдельное время

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

даже ссылки на профиль кешируются

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

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

… в общем глобальный кеш не айс. Сливаюсь с темы.

у Sjen кеш работает еще до запуска всех классов движка, это для его сайта дает супер ускорение… но и
минусы свои есть… Например стандартными средствами уже невозможно подсветить текущий пункт меню… вывести случайный текст и тп. Только через гору костылей ))

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

Я так думаю, что решение Марата, отлично подойдет для проектов с выдачей контента который не ежеминутно обновляется, например блоги или каталог предприятий.

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

KS, хорошая идея, разделять гостей и пользователей.
В общем, как и говорил, четкой картинки в голове пока нет. Но есть цель, к которой нужно стремиться. Результат в прикрепленном файле.
Мемкэш, конечно, хорошо. Но не у каждого есть возможность воспользоваться им. Особенно для вирт. хостингов.
Будем думать. Может со временем что-то и получится.
Кто что имеет сказать, отписывайтесь пожалуйста.

нового добавить то нечего😥все уже сказано выше. в большинстве движков кеширование двух уровневое, первый уровень для не залогиненого, они генерируют 80% нагрузки, это гости, поисковые боты, парсеры контента и тд. Тут кешируется все, целиком страница. Второй уровень кеширования более слабый, для зарегистрированных, страница бьется на блоки по модулям вывода информации и кешируются сами блоки. Например страница со статьей имеет закешированное тело статьи и отдельно обновляемый блок с комментариями и тд… Как то так, на взгляд теоретика :)