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

[Ивано++]

И еще все таки интересно раз уж тут тема про кэширование идет...
Посмотрел и прикинул вообще по коли-во оращений к БД у 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]

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

[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

Вот-вот.

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

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

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

COA_GO - не использовал, т.к. она для старых версий TYPO3...
И в 4.7. - уже по моему не работает...


---------------------------------------------
И одну очень интересную особенность у TYPO3 - нашел.
Допустим у нас есть страница
http://company.ru/about/

Она весит в закешированном состоянии...
Ради интереса изменяем информацию на странице (таблица pages) - через phpMyAdmin - просто меняем название страницы

Заходим сюда:
http://company.ru/about/ - изменений не видим

Заходим сюда:
http://company.ru/about/?no_cache=1 - изменения видим!
Как знаем, no_cache - параметр можно заблокировать

Заходим сюда!!!!
http://company.ru/about/?blablablablalb=1231123 - изменения видим!!!
Что довольно странно!!!

Получается, что добавляя всякую ерунду к url-адресу, TYPO3 показывает ее с просто с выключенным кэшем... - интересно!

[Ивано++]

Т.е. по идее любой бы пораметр который бы не добавили к url

&print=1
&print=-1
&print=blablabla
&blablabla=print

- это будет аналогично добавлению no_cache=1