Russian TYPO3 community Форум больше не используется. Присоединяйтесь к каналу #community-ru в Slack for TYPO3 community  

Вернуться   Russian TYPO3 community > Тематические форумы > Разработка расширений / TYPO3 extension development

Ответ
 
Опции темы Опции просмотра
Старый 07.12.2013, 15:37   #41
Ивано++
Senior Member
 
Аватар для Ивано++
 
Регистрация: 18.01.2013
Адрес: Russia , Moscow
Сообщений: 796
По умолчанию

И еще все таки интересно раз уж тут тема про кэширование идет...
Посмотрел и прикинул вообще по коли-во оращений к БД у 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()
__________________
Иван Литовченко
http://iv-litovchenko.ru/
Ивано++ вне форума   Ответить с цитированием
Старый 09.12.2013, 13:34   #42
dmartynenko
Senior Member
 
Аватар для dmartynenko
 
Регистрация: 20.07.2007
Адрес: Беларусь, Минск
Сообщений: 957
Отправить сообщение для dmartynenko с помощью ICQ
По умолчанию

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

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

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

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

Тут тоже не совсем то, но дело плохо. При таком варианте забьется и кэш страниц, и внутренний (если делать через него), и кэш RealURL. Оптимальное решение в таком случае - вообще не кэшировать. И не давать поисковикам индексировать все этого. Так как уникального контента в этих тысячах страниц 0%.
dmartynenko вне форума   Ответить с цитированием
Старый 09.12.2013, 17:02   #43
Ивано++
Senior Member
 
Аватар для Ивано++
 
Регистрация: 18.01.2013
Адрес: Russia , Moscow
Сообщений: 796
По умолчанию

Цитата:
Сообщение от 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

--
И все кэша уже не будет так много.
А по этим страницам всеравно будут ходить больше всех наверное боты.
__________________
Иван Литовченко
http://iv-litovchenko.ru/
Ивано++ вне форума   Ответить с цитированием
Старый 09.12.2013, 17:07   #44
Ивано++
Senior Member
 
Аватар для Ивано++
 
Регистрация: 18.01.2013
Адрес: Russia , Moscow
Сообщений: 796
По умолчанию

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

Последний раз редактировалось Ивано++; 09.12.2013 в 19:18
Ивано++ вне форума   Ответить с цитированием
Старый 09.12.2013, 17:09   #45
dmartynenko
Senior Member
 
Аватар для dmartynenko
 
Регистрация: 20.07.2007
Адрес: Беларусь, Минск
Сообщений: 957
Отправить сообщение для dmartynenko с помощью ICQ
По умолчанию

Решения сложных случаев конечно можно найти. Но оно будет чаще всего не универсально
И технология "cHash" в случае сложных сайтов скорее минус, чем плюс.
dmartynenko вне форума   Ответить с цитированием
Старый 09.12.2013, 17:24   #46
dmartynenko
Senior Member
 
Аватар для dmartynenko
 
Регистрация: 20.07.2007
Адрес: Беларусь, Минск
Сообщений: 957
Отправить сообщение для dmartynenko с помощью ICQ
По умолчанию

Цитата:
Сообщение от Ивано++ Посмотреть сообщение
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 вне форума   Ответить с цитированием
Старый 23.12.2013, 22:47   #47
Ивано++
Senior Member
 
Аватар для Ивано++
 
Регистрация: 18.01.2013
Адрес: Russia , Moscow
Сообщений: 796
По умолчанию

Цитата:
Сообщение от 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 показывает ее с просто с выключенным кэшем... - интересно!
__________________
Иван Литовченко
http://iv-litovchenko.ru/
Ивано++ вне форума   Ответить с цитированием
Старый 25.12.2013, 05:29   #48
Ивано++
Senior Member
 
Аватар для Ивано++
 
Регистрация: 18.01.2013
Адрес: Russia , Moscow
Сообщений: 796
По умолчанию

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

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

- это будет аналогично добавлению no_cache=1
__________________
Иван Литовченко
http://iv-litovchenko.ru/
Ивано++ вне форума   Ответить с цитированием
Ответ


Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB code is Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход

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


Часовой пояс GMT +4, время: 01:39.


Работает на vBulletin® версия 3.8.1.
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Перевод: zCarot

Хостинг и техническая поддержка: TYPO3 Лаборатория