Всетаки - кэширование с использованием БД - это очень не удобно!

[Ивано++]

Немного по поводу сброса по тэгам...

Есть 1-страница - к примеру...
На ней работают два плагина:

Плагин А) - список новостей
Плагин Б) - список статей

Каждый из плагинов создает виртуальные страницы с useCachHash...
И добавим такой сложный элемент как постраничная навигация для каждого из плагинов.

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

[dmartynenko]

Вот поэтому я всегда рекомендую встраивать кэширование внутрь плагина.
Потому что в таком случае может получиться следующая картина: 1000 записей (страниц) в одном плагине, 1000 в другом. В итоге в худшем случае имеем 1000х1000 = 1 000 000 записей в кэше. Если не живые люди, то роботы поисковиков сканируя все ссылки на сайте это обеспечат. При том что реально уникальной информации 1000 + 1000 = 2000 единиц. И столько же будет в кэше, если делать кэширование внутри плагина.

[Ивано++]

Сообщение от dmartynenko

Вот поэтому я всегда рекомендую встраивать кэширование внутрь плагина.
Потому что в таком случае может получиться следующая картина: 1000 записей (страниц) в одном плагине, 1000 в другом. В итоге в худшем случае имеем 1000х1000 = 1 000 000 записей в кэше. Если не живые люди, то роботы поисковиков сканируя все ссылки на сайте это обеспечат. При том что реально уникальной информации 1000 + 1000 = 2000 единиц. И столько же будет в кэше, если делать кэширование внутри плагина.

Не совсем сообразил в плане рассчетов по умножении и получению 1 000 000 записей в кэше.

1 страница - на ней два плагина:

первый плагин генерирует 1000 виртуальных страниц через useCachHash
генерирует 15 постраничных страниц (к примеру)
typolink = index.php?id=95&tx_my_ext_1[record_detail]=1&useCachHash=1
typolink = index.php?id=95&tx_my_ext_1[pagination]=1&useCachHash=1


второй плагин генерирует 1000 виртуальных страниц через useCachHash
генерирует 25 постраничных страниц (к примеру)
typolink = index.php?id=95&tx_my_ext_2[record_detail]=1&useCachHash=1
typolink = index.php?id=95&tx_my_ext_2[pagination]=1&useCachHash=1

1000 + 15 + 1000 + 25 = 2035 виртуальных страниц, ну и + 1 страница, на которой эти плагины работают...
откуда мильёон?

[Ивано++]

И еще все таки интересно раз уж тут тема про кэширование идет...
Посмотрел и прикинул вообще по коли-во оращений к БД у TYPO3 - и в сравнении с другими CMS...

Вот есть такое (с других форумов):

Сильно удивился по поводу 25 запросов... поставил с нуля OpenCart 1.5.1.3.1
Главная страница
SEO выкл. - 105 запросов
opencart1531_home.png
SEO вкл. - 176 запросов

Проверил сейчас у себя сколько запросов с главной страницы:

totalProcessTime - 0.11311507225037 sec
Queries - 98.
Queries time - 0.01339316368103.

Мне кажется отличный результат. На главной странице выводится:
8 последних товаров
5 рекомендуемых товаров
Аккордеон меню с 15 категориями (без счетчика количества товара)
Стена категорий (плагин)
1

У меня на одном из сайтов на TYPO3 - получается при

генерации главной ~ 125 - запросов
в закэшированной состоянии ~ 50 запросов


А у чистых версий TYPO3 (например inducation c realurl без ***_INT), так и вообще получается наверное где-то 10-15 запросов через exec_SELECTquery()

[dmartynenko]

Если можно ходить по страницам одного плагина, и другого независимо. И при этом запоминаются обе позиции. То есть плагины учитывают piVars друг друга, то получиться 15 * 25 возможных вариантов записей в кэше со списками. Или вы открываете single одного плагина, и при этом остается виден список другого с постраничной навигацией.

Это не совсем реальный случай конечно.

Но вот более реальный.

Берем список tt_news + плагин календаря к нему + список категорий tt_news на той же странице. Календарь может генерировать очень большое число страниц сам по себе - отдельная страница на каждый день + на каждый месяц. Категории служат фильтрами внутри дня, месяца - поэтому в piVars категории добавляется дата. Получаем на каждый день у нас число уникальных url (страниц) равно числу категорий. Плюс возможная постраничная навигация внутри всего этого.

Тут тоже не совсем то, но дело плохо. При таком варианте забьется и кэш страниц, и внутренний (если делать через него), и кэш RealURL. Оптимальное решение в таком случае - вообще не кэшировать. И не давать поисковикам индексировать все этого. Так как уникального контента в этих тысячах страниц 0%.

[Ивано++]

Сообщение от dmartynenko

Если можно ходить по страницам одного плагина, и другого независимо. И при этом запоминаются обе позиции. То есть плагины учитывают piVars друг друга, то получиться 15 * 25 возможных вариантов записей в кэше со списками. Или вы открываете single одного плагина, и при этом остается виден список другого с постраничной навигацией.

Это не совсем реальный случай конечно.

Но вот более реальный.

Берем список tt_news + плагин календаря к нему + список категорий tt_news на той же странице. Календарь может генерировать очень большое число страниц сам по себе - отдельная страница на каждый день + на каждый месяц. Категории служат фильтрами внутри дня, месяца - поэтому в piVars категории добавляется дата. Получаем на каждый день у нас число уникальных url (страниц) равно числу категорий. Плюс возможная постраничная навигация внутри всего этого.

Тут тоже не совсем то, но дело плохо. При таком варианте забьется и кэш страниц, и внутренний (если делать через него), и кэш RealURL. Оптимальное решение в таком случае - вообще не кэшировать. И не давать поисковикам индексировать все этого. Так как уникального контента в этих тысячах страниц 0%.

Т.е. получается примерно

Плагин А)
tt_news[detail] = 1-1000
tt_news[page_number] = 1-10
tt_news[page_number] = 1-10 &(+) tt_news[detail] = 1-1000
tt_news[calendar_data] = 10-10-2010 &(+) tt_news[page_number] = 1-10 &(+) tt_news[detail] = 1-1000
и все это суммируется

Плагин Б)
аналогично...

Да... так получается очень много.
Тогда ясно о чем речь.

Ну решение (может быть):
1) кэшировать в другие таблицы, скажем как это делает tt_news (в его cf_tt_news_cache) - хотя если на всем сайте (caching framework) - перевести на другой дравйвер, например Memcache - то не вижу смысла плодить кэш-таблицы cf_***...
2) кэш можно вырубать скажем на тех стран которые с большой долей вероятности не будут посещены пользователем... Например
- а) календари старых дат (кэшируем только тридцать последних 90 дней - к примеру, а то и меньше),
- б) page_number > 10
- в) news_detail > 100

--
И все кэша уже не будет так много.
А по этим страницам всеравно будут ходить больше всех наверное боты.

[Ивано++]

3) и пожалуй пока сложно реализуемое средствами typo3 и typoscript
если взять практически любой сайт - то - (по моим наблюдениям) - основную долю веса (приерно 20-30-400-500 а то и больше %) страницы в кэше составляет условно говоря "горизонтальное , вертикальное" меню... ну скажем классика сайта... Соответственно если кэшировать это меню 1 раз... То весь кэша уменьшается на порядок...

[dmartynenko]

Сообщение от Ивано++

3) и пожалуй пока сложно реализуемое средствами typo3 и typoscript
если взять практически любой сайт - то - (по моим наблюдениям) - основную долю веса (приерно 40-50 а то и больше %) страницы в кэше составляет условно говоря "горизонтальное , вертикальное" меню... ну скажем классика сайта... Соответственно если кэшировать это меню 1 раз... То весь кэша уменьшается на порядок...

Вот-вот.

Грубо говоря, если меню сделать USER_INT с внутренней логикой кэширования, то мы сильно разгрузим кэш.

И этот велосипед уже изобрели http://forge.typo3.org/projects/extension-coago и благополучно забросили. Не все там работает так, как заявлено.

А потом снова переизобрели http://docs.typo3.org/typo3cms/Typos...che/Index.html
Последний я еще не пробовал. Возможно, это решение многих проблем прямиком через TS.

[dmartynenko]

Решения сложных случаев конечно можно найти. Но оно будет чаще всего не универсально
И технология "cHash" в случае сложных сайтов скорее минус, чем плюс.