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

И ещё: система не должна ничего делать для кэширования сама, она должна лишь дать класс, модули компоненты и плагины должны сами себя кэшировать. Модуль меню например, его же нельзя кэшировать, иначе:

невозможно подсветить текущий пункт меню

Значит в кэше должен лежать массив пунктов меню, а не тело модуля. А для модулей нового и популярного можно положить и тело (хтмл). Но при этом сам модуль должен разделять области видимости для разных групп юзеров и сам решать, делать ему один общий кэш или несколько. Так же и компоненты.
Про тэгирование. Нельзя просто присвоить тэг "комменты", иначе юзер, изменивший о4епятку в своём древнем комментарии сбросит нам кэш всего, где есть тэг "комменты" — не просто модуль с комментами и списки, а всё, где так или иначе они задействованы, включая счётчики их количества к контенту.

Задача не из лёгких, да и вообще не особо то и острая — на нормальных хостингах страницы и с сотней запросов открываются за сотые доли секунды. Если это кто то и реализует, то оставит себе любимому, ну а если вдруг это появится во всеми долгожданной двойке когда нибудь, то значит медведь в лесу сдох))

имхо, проще и разумнее внедрить поддержку memcached.
Что будете делать, если у вас база будет под пол гигабайта и десятки тысяч страниц? Все из "летает" превратится в "ползает".

опять же имхо:

для php — xcache;
для выборок из базы — memcached.

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

весь лес с медведями вымер по всей видимости, ибо там memcached из коробки.

весь лес с медведями вымер по всей видимости, ибо там memcached из коробки.

Я не про просто кэширование, а про умное кэширование

Fuze, спасибо за наводку. memcached, как вариант, интересен. Но смущают 2 варианта. Не знаю, как обстоит дело с мемкашем на вирт. хостингах. Второй, memcached кеширует в оперативной памяти. С последним обычно хуже, чем с дисковым пространстом. И при недостаточной оперативной памяти(если не хватает, под мемкашед придется выделить мало) и при большом количестве страниц может появиться обратный эффект.

Что будете делать, если у вас база будет под пол гигабайта и десятки тысяч страниц? Все из "летает" превратится в "ползает".

В БД хранится минимум информации по странице(id, урл и для кеша — время кеширования), ну и сео-параметры для других целей. Эта информация из БД достается простым запросом. Весь кеш хранится обычным способом в файлах и вычищается обычной очисткой кеша.
lokanaft, модульное кеширование, класс для кеширования — что-то уже есть в системе, а для реализации другого — придется очень сильно видоизменять систему. Вопрос же стоит не в большом хаке или изменениях офф. сборки. Вопрос, как с меньшими потерями добиться большого эффекта.
Пока склоняюсь, к варианту предложенному KS — кеш только для гостей, для юзверов — без кеша. Попробую потестирую. ID страниц и прочее, привязку времени кеша к страницам — пока не буду рассматривать. Может на будущее.
А вопрос на самом деле актуальный. Время генерации — 0,7 с. и 0,07 с. имеют большую разницу. Поисковики это понимают и обращают внимание. Особенно Гоша любит быстрые сайты. К тому же они любят постоянное обновление — но это уже другой вопрос ) Да и нагрузка на сервак тоже актуальна. Постоянно проскакивают подобные темы.
Всем спасибо! Мозговой штурм считаю удался Надо поэксперементировать.

Марат а вы могли бы замерить вот этот параметр: Общая оценка PageSpeed для страницы. Если не пробовали то для Хрома установите расширение PageSpeed, хотелось бы узнать каковы параметры. У меня в среднем внутряки 90-92, главная 80-90. Вот интересно, как кеш дает результат.

letsgo, потестирую. Если функционал будет рабочим, поставлю на сайт, проверю, отпишусь.

Fuze, а в 1.10 планируется ввести мемкешд опционально?

Я не про просто кэширование, а про умное кэширование

думаю что в 2.0 достаточно умное кеширование

во-первых, там поддержка и файлов и memcached (с тегированием в обоих случаях)
во-вторых, обращение к кешу при выборке из базы производится скрытно и без лишних условий

например, метод получения списка комментариев в модели (условный пример):
метод get() модели автоматически определит есть кеш или нет и вернет данные либо из него, либо из базы.

Также бывает что запрос может меняться (например при выдаче комментариев от конкретных пользователей)
Система кеширования автоматически отслеживает это и создает подмножество запросов в кеше, при этом для программиста ничего не меняется, например:

то есть как был один вызов useCache для тега 'comments.list', так он и остался, а запрос для каждого $user_id будет кешироваться отдельно от остальных

при изменении списка комментариев кеш соответственно сбрасывается:

r2, уже хорошо. Но про тегирование я и сказал, что нельзя ставить тег 'comments' для всего, где они используются и сбрасывать его каждый раз, в таком случае от кэша толку 0, при высокой активности.

Ну что? Любой опыт, даже с отрицательным результатом, что-то дает. Итак, что получилось?
Кеширование в индексном файле переделал. Для пользователей обычная страница, для гостей кеш. При тестировании выяснилось, что не выводятся сессионные сообщения и не работают фильтры. Ввел проверку и теперь работает корректно.
В плане SEO эффект нулевой. Объясню почему. При тесте на реалхостинге выяснилось. Что, допустим время генерации страницы без кеша в среднем 0,15 сек. С кешем — 0,007 сек(грубый тест). Проверяем скорость загрузки сайта различными сервисами — колебания идут 0,5- 0,8 c. В результате, выигрышный эффект гасится.
Но есть очевидный плюс. Количество запросов в БД на любой странице 7-8. Что, конечно же, сильно снизит нагрузку на сервер. Для себя применения не нахожу пока, ибо сервак пашет на 10% своей мощи. Ну а те, чьи сайты работают на пределе пика, можете поставить и потестировать.
Скачать архив
В архиве главный индексный файл. Сделайте бэкап своего файла и перезалейте файл из архива. Время жизни кеша устанавливается на 88 строке
Первая цифра — время жизни(по умолчанию 10 мин.). Можете изменить как нужно.
Ещё один нюанс. Пример, добавили статью — вначале был общий доступ. Затем закрыли доступ гостям. И чтобы, гостям статья стала недоступной, нужно очистить системный кеш. Иначе статья будет доступна из кеша. Надеюсь поняли суть.
В общем всё. Кому интересно, попробуйте.

В плане SEO эффект нулевой. Объясню почему. При тесте на реалхостинге выяснилось. Что, допустим время генерации страницы без кеша в среднем 0,15 сек. С кешем — 0,007 сек(грубый тест). Проверяем скорость загрузки сайта различными сервисами — колебания идут 0,5- 0,8 c. В результате, выигрышный эффект гасится.

картинки, файлы стилей, скрипты и тд. пока все в одной очереди прогрузится — вот и эффект.

картинки, файлы стилей, скрипты и тд. пока все в одной очереди прогрузится — вот и эффект.

А какая разница? Что с кешем, что без — в окончаловке сервер отдает одинаковый html код страницы. Это уже браузер на основе кода решает, что раньше подгружать, что позже. Кеш на это не влияет.

На одном из проектов пришлось выводить статику на отдельные 2 поддомена чтобы распаралелить загрузку в браузер. Оно время загрузки хорошо уменьшило, но подобные извраты только на нгинхе замутить можно более менее просто.

Подсмотрел про это на крупном сайте, там фотки грузятся не с одного домена а с поддоменов различных, а-ля icf65td.s34.site.com/fg.gif Так, если фоток много, браузер получает их шустрее. Ну и настройки кеша в нгинхе на статику жесткие очень.

Чего не сделаешь чтобы новые сервера не покупать ))

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

картинки, файлы стилей, скрипты и тд. пока все в одной очереди прогрузится — вот и эффект.

А какая разница? Что с кешем, что без — в окончаловке сервер отдает одинаковый html код страницы. Это уже браузер на основе кода решает, что раньше подгружать, что позже. Кеш на это не влияет.

И что? Боту подай страницу и как можно быстрей. Картинки, скрипты и прочая хня на странице его мало интересует.