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

Ивано++ · 02.10.2013, 00:03

Цитата:

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

С левыми id проблем не вижу.

Вы же делаете как:
1. Строите cache_key
2. Проверяете в кэше
3. Если нет, то делаете запрос в БД
4. Если нет записи - выдаете 404
5. Если есть в БД, формируете контент и пишете в кэш

Логично что ответы 404 в кэш писать не нужно.

К сожалению - это очень сложный механизм...
Возможно нашел решение - более простое - по поводу разрешить/запретить кэширование - но оно связанно с useCashHash - и не знаю насколько оно будет уместно ... И сейчас не совсем пойму - почему useCashHash так плох?

Цитата:

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

Это я к тому, что бы не использовать тривиальные ключи вроде table_name+id, или просто id. Если добавить к ключу $GLOBALS["TSFE"]->id, а еще можно и domain, то уникальность между сайтами гарантирована.

Может это замечательная функция позволит уж точно не запутаться на разных проектах:

PHP код:


			
md5(t3lib_div::getIndpEnv('TYPO3_SITE_URL') ... // текущий url-страницы

?

Ивано++ · 02.10.2013, 01:08

Это то, что так долго искал - наверное не 1-и месяц:
самое странное что в тему useCashHash valid - на оффициальном форуме typo3.org - мне ничего не ответили, вернее ответили, но как-то расплывчато было сказано - что это не возможно - и это ответ от Core...!!!... Странно что там, даже PHP-код вставить нет возможности....

Теперь из t3lib_div::cHashParams и t3lib_div::calculateCHash стало понятно, как можно проверить ... useCashHash - оказывается - это просто md5 - всех _GET-параметров....

PHP код:


			
//////////////////////////////////////////////////////////////////////
    // Определяем тип страницы
    //////////////////////////////////////////////////////////////////////
    $cHash_array = t3lib_div::cHashParams( t3lib_div::implodeArrayForUrl('', $GLOBALS['_GET'])  );
    $cHash_calc = t3lib_div::calculateCHash($cHash_array);
    
    // обычные // "1" Обчыная страница
    if ($GLOBALS['TSFE']->getHash() != null) {
            
        // кэшировать можно
    }
    // useCashHash = 1 // "2" виртуальная страница 
    if ($GLOBALS['TSFE']->cHash != null){ 
            
        // кэшировать можно
                
    }
    // Не для кэширования // "3" запрещенная к кэшированию - виртуальная страница
    if (($GLOBALS['TSFE']->cHash != null && $GLOBALS['TSFE']->cHash != $cHash_calc)
    OR ($GLOBALS['TSFE']->cHash == null && $cHash_calc != null)){ 
    
        // кэшировать запрещено!
    
    }

А с тэгами - наверное - если в memcache - ничего не получится - то останусь на БД

Т.к. по тэгам хочется иметь что - то вроде

Код HTML:

//[prefixProject][domainName][pageId/Alias][typeNum][L][useCashHash][commendId]...
//[prefixProject][domainName][pageId/Alias][typeNum][L][useCashHash][newsId]...

ТЭГИ ::: https://code.google.com/p/memcached-...seMemcachedTag
Пока как-то так.

Ивано++ · 07.10.2013, 22:28

Использую memcache - тэги можно хранить в БД.

Ивано++ · 03.12.2013, 11:12

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

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

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

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

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

dmartynenko · 06.12.2013, 13:49

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

Ивано++ · 06.12.2013, 21:23

Цитата:

Сообщение от 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 страница, на которой эти плагины работают...
откуда мильёон?

Ивано++ · 07.12.2013, 15:37

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

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

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

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

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

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

02.10.2013, 01:08	#2
Ивано++ Senior Member Регистрация: 18.01.2013 Адрес: Russia , Moscow Сообщений: 796	Это то, что так долго искал - наверное не 1-и месяц: самое странное что в тему useCashHash valid - на оффициальном форуме typo3.org - мне ничего не ответили, вернее ответили, но как-то расплывчато было сказано - что это не возможно - и это ответ от Core...!!!... Странно что там, даже PHP-код вставить нет возможности.... Теперь из t3lib_div::cHashParams и t3lib_div::calculateCHash стало понятно, как можно проверить ... useCashHash - оказывается - это просто md5 - всех _GET-параметров.... PHP код: ////////////////////////////////////////////////////////////////////// // Определяем тип страницы ////////////////////////////////////////////////////////////////////// $cHash_array = t3lib_div::cHashParams( t3lib_div::implodeArrayForUrl('', $GLOBALS['_GET']) ); $cHash_calc = t3lib_div::calculateCHash($cHash_array); // обычные // "1" Обчыная страница if ($GLOBALS['TSFE']->getHash() != null) { // кэшировать можно } // useCashHash = 1 // "2" виртуальная страница if ($GLOBALS['TSFE']->cHash != null){ // кэшировать можно } // Не для кэширования // "3" запрещенная к кэшированию - виртуальная страница if (($GLOBALS['TSFE']->cHash != null && $GLOBALS['TSFE']->cHash != $cHash_calc) OR ($GLOBALS['TSFE']->cHash == null && $cHash_calc != null)){ // кэшировать запрещено! } А с тэгами - наверное - если в memcache - ничего не получится - то останусь на БД Т.к. по тэгам хочется иметь что - то вроде Код HTML: //[prefixProject][domainName][pageId/Alias][typeNum][L][useCashHash][commendId]... //[prefixProject][domainName][pageId/Alias][typeNum][L][useCashHash][newsId]... ТЭГИ ::: https://code.google.com/p/memcached-...seMemcachedTag Пока как-то так. Последний раз редактировалось Ивано++; 02.10.2013 в 01:35

03.12.2013, 11:12	#4
Ивано++ Senior Member Регистрация: 18.01.2013 Адрес: Russia , Moscow Сообщений: 796	Немного по поводу сброса по тэгам... Есть 1-страница - к примеру... На ней работают два плагина: Плагин А) - список новостей Плагин Б) - список статей Каждый из плагинов создает виртуальные страницы с useCachHash... И добавим такой сложный элемент как постраничная навигация для каждого из плагинов. При добавлении новости или статьи - нам же придется все равно сбрасывать весь кэш страницы с useCachHash - что бы заново пересчитать постраничную навигацию - или же делать так, что бы сбрасывался конкретный планиг - что думаю приведет в последствии к немалой путанице при поддержке проекта... __________________ Иван Литовченко http://iv-litovchenko.ru/

Похожие темы
Тема	Автор	Раздел	Ответов	Последнее сообщение
Cлишком сложно показалось?	carlos	Вопросы выбора CMS	5	04.07.2007 16:37

07.10.2013, 22:28	#3
Ивано++ Senior Member Регистрация: 18.01.2013 Адрес: Russia , Moscow Сообщений: 796	Использую memcache - тэги можно хранить в БД.

06.12.2013, 13:49	#5
dmartynenko Senior Member Регистрация: 20.07.2007 Адрес: Беларусь, Минск Сообщений: 957	Вот поэтому я всегда рекомендую встраивать кэширование внутрь плагина. Потому что в таком случае может получиться следующая картина: 1000 записей (страниц) в одном плагине, 1000 в другом. В итоге в худшем случае имеем 1000х1000 = 1 000 000 записей в кэше. Если не живые люди, то роботы поисковиков сканируя все ссылки на сайте это обеспечат. При том что реально уникальной информации 1000 + 1000 = 2000 единиц. И столько же будет в кэше, если делать кэширование внутри плагина.

09.12.2013, 13:34	#8
dmartynenko Senior Member Регистрация: 20.07.2007 Адрес: Беларусь, Минск Сообщений: 957	Если можно ходить по страницам одного плагина, и другого независимо. И при этом запоминаются обе позиции. То есть плагины учитывают piVars друг друга, то получиться 15 * 25 возможных вариантов записей в кэше со списками. Или вы открываете single одного плагина, и при этом остается виден список другого с постраничной навигацией. Это не совсем реальный случай конечно. Но вот более реальный. Берем список tt_news + плагин календаря к нему + список категорий tt_news на той же странице. Календарь может генерировать очень большое число страниц сам по себе - отдельная страница на каждый день + на каждый месяц. Категории служат фильтрами внутри дня, месяца - поэтому в piVars категории добавляется дата. Получаем на каждый день у нас число уникальных url (страниц) равно числу категорий. Плюс возможная постраничная навигация внутри всего этого. Тут тоже не совсем то, но дело плохо. При таком варианте забьется и кэш страниц, и внутренний (если делать через него), и кэш RealURL. Оптимальное решение в таком случае - вообще не кэшировать. И не давать поисковикам индексировать все этого. Так как уникального контента в этих тысячах страниц 0%.