Курс 2016 года “Разработка на UMI.CMS от 0 до готового сайта”
Статическое кэширование и мобильная версия сайта

Автор CubesРаздел Настройка системы и модулей

Ответов: 1
Просмотров: 233
Последний ответ 15 Марта 2016, 10:55:29
от aghigay
Кэширование протокола usel?

Автор muldyРаздел Custom макросы

Ответов: 17
Просмотров: 4200
Последний ответ 13 Августа 2013, 19:08:00
от muldy
Кэширование и фильтры каталога

Автор andreyРаздел Настройка системы и модулей

Ответов: 4
Просмотров: 1779
Последний ответ 02 Июля 2014, 18:29:15
от e.ioffe
Статическое кэширование

Автор DZHETIGAPAРаздел Шаблоны XSLT

Ответов: 5
Просмотров: 2812
Последний ответ 23 Марта 2012, 11:19:38
от DZHETIGAPA
Кэширование UMI

Автор akarihРаздел Настройка системы и модулей

Ответов: 5
Просмотров: 3264
Последний ответ 20 Марта 2012, 23:58:12
от akarih

0 Пользователей и 1 Гость просматривают эту тему.

*

Rodogor

  • ***
  • 189
  • +24/-0
    • Просмотр профиля
Оптимизация, кэширование.
« : 21 Февраля 2013, 09:49:27 »
Здравствуйте.
Что-то начал делать очень тяжелые сайты, грузится всё очень долго. Почти всё кастомное, и походу косячу именно я, но анализируя структуру БД и как устроено понимаю, что таки не только мои косяки там. Стандартное я стараюсь оптимизировать - задаю либо более конкретное условие (в определённых ситуациях по большому количеству полей быстрее отфильтровать), стараюсь упростить многие места.

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

Я понимаю, что к примеру в интернет-магазине много время занимает поиск товаров, которые выводятся на главную, затем для каждой странице upage и т.п. - короче время, это можно сохранить в файл с готовым html и вывести, я так уже делал.. От множественного вызова upage я давно отказался, почти всё делаю на php - так работает быстрее.

А можно ли закешировать на уровне хостинга, сервера ? К примеру, выполняется один и тот же запрос... Чем кроилово в коде - может кэшить именно этот запрос, точнее ответ на запрос ?

XSLT кэширование запросов - я смотрел через ?showStreamsCalls, получалось так, что те макросы, которые вызываются два раза на странице (ну мало ли) вызываются только один раз. После обновления браузера запросы снова полностью повторяются.

Я вообще представляю, что должно работать так:
1)без кэша - запрос, выполнение кода, запрос к базе, ответ.
2)с кэшем - если нет кэша: поиск данных по хэшу,  не нашли, выполняем запросы, сохраняем кэш, выводим ответ. если есть кэш - поиск по хэшу, проверка на модификацию, вывод.


Смотрю как работают некоторые сайты, к примеру key.ru:
<streams-call total-time="0.065534">
<call generation-time="">upage://35.minMode</call>
<call generation-time="0.000291">udata://custom/current_mode</call>
<call generation-time="0.000185">udata://custom/count_compare_good</call>
<call generation-time="0.000175">udata://custom/getCityList/</call>
<call generation-time="0.000338">udata://system/listErrorMessages</call>
<call generation-time="">upage://67187</call>
<call generation-time="0.006832">udata://users/getLoginzaProvider</call>
<call generation-time="0.047968">udata://custom/emarketCartLite/</call>
<call generation-time="0.000167">udata://custom/show_last_showed_count</call>
<call generation-time="0.001737">udata://catalog/category_list_html/</call>
<call generation-time="0.001492">udata://custom/recommendedItem/1063</call>
<call generation-time="0.001426">udata://custom/banners_list/(vendor_banner_1)</call>
<call generation-time="0.000175">udata://custom/banners_list/(main_vendor_banner)</call>
<call generation-time="0.000646">udata://custom/primary_slider/</call>
<call generation-time="0.001858">udata://custom/special_offers_list/</call>
<call generation-time="0.000970">udata://custom/novinki_list/</call>
<call generation-time="0.000613">udata://custom/lastlist/37/1063/7</call>
<call generation-time="0.000565">udata://custom/lastlist/3505/1063/7</call>
<call generation-time="0.000096">udata://custom/text_messages</call>
</streams-call><!-- This page generated in 0.21666 secs -->

Столько, сколько у них грузится весь сайт - у меня столько выполняется один единственный upage. Видно, что у них upage запросы возвращаются без времени - у меня так возвращаются запросы, которую грузятся из файло. Как это можно сделать ?

В некоторых запросах у них возвращается готовый html код. Интуитивно и постепенно я начал отказываться от мега-кроилова на XSLT, но неужели на столько всё плохо ? К примеру, udata://catalog/category_list_html/

Тестирую хостинг -
Производительность: 14.97 - результат ниже нормы
Данный показатель измеряет, сколько раз выполняется генерация пустой страницы за одну секунду. Чем больше этот показатель, тем лучше.
Показатели load average: 0.27, 0.38, 0.58

Походу реально мало.... у кого как ?... Что посоветуете ?..

*

Rodogor

  • ***
  • 189
  • +24/-0
    • Просмотр профиля
Re:Оптимизация, кэширование.
« Ответ #1 : 21 Февраля 2013, 10:56:09 »
походу психанул - грузилась страница максимально 40 секунд, в среднем 8-12, теперь 0.6.
Всё же послушать чьё-то мнение по этому поводу я бы хотел.
Какое время производительности и т.п..
На хостинге, где тяжелые сайты - производительность описана выше.

На vds-ке с 10-тком визиток:
Цитировать
Производительность: 28.65 - стабильный средний показатель

Данный показатель измеряет, сколько раз выполняется генерация пустой страницы за одну секунду. Чем больше этот показатель, тем лучше.
Демо-сайт на umi-cms:
Цитировать
Производительность: 35.22 - отличная производительность

Данный показатель измеряет, сколько раз выполняется генерация пустой страницы за одну секунду. Чем больше этот показатель, тем лучше.
Показатели load average: 0.18, 0.06, 0.01

Ещё момент - к примеру, на сайте много страниц, на которые делаются ссылки. Сайт не мультиязычный, поэтому для того, что бы сделать ссылку я привязываюсь по id страницы. Соответственно, каждый раз я выполняю upage для получения link. Я могу уйти от upage и запихнуть всё в один кастом, но а как разрулить эту ситуацию правильно ? :)
« Последнее редактирование: 21 Февраля 2013, 11:07:01 от Rodogor »

*

admin

  • *****
  • 2419
  • +172/-1
    • Просмотр профиля
Re:Оптимизация, кэширование.
« Ответ #2 : 27 Февраля 2013, 09:50:53 »
сейчас тоже стал проводить занимательные эксперименты с производительностью и на данный момент вижу 3 пути сокращении времени загрузки

1. практический и наверное самый громадный момент, это оптимизация не генерации html системой, а подгрузка всего остального.
Проблемные места:
  - бездумно подключенные css и js пачками,
  - вывод кучи не оптимизированных картинок товаров,
  - вывод кучи скрытых блоков, которые по хорошему надо генерить через ajax,
  - не оптимизированная верстка самого шаблона (сплит мелких картинок),
  - запрос всех ресурсов с одного хоста (что приводит к задержки загрузки, так как параллельные запросы имеют ограниченны определенным числом),
  - вбивание многих декоративных элементов в html (а надо бы в css)

2. шаблонизатор
   - чистота шаблонов (чем меньше суммарно весят ваши xslt шаблоны, тем лучше),
   - работа с данными одинаковых запросов через переменную (то есть если нам надо 2 раза вызывать emarket/cart то лучше это сделать через переменную, которую после и использоваться для всех apply-templates),   
   - кеширование udata запросов через параметр  ?expire.
   - отказ от лишних upage обращений для доп поле используя параметр получения расширенных полей или групп полей при вызове макроса

3. работа макросов
  - чистота логики (убирать и оптимизировать все лишнее , все доп вызовы, которых можно было бы избежать... например использовании demodizzy call-template для вывода уменьшенной картинки на странице товара, там происходит передача id страницы и название поля и последующее получение через upage ссылки на картинку, но она нам изначально была известна, ведь мы на странице товара)
  - иногда делаю переписывание стандартных макросов в сторону вывода доп информации, которую иначе пришлось бы получать доп запросами из xsl шаблона
  - включенный кеш в самой umi (правда уже после тестов корректной работы сайта с точки зрения тз)
  - использование html кеширования результатов для особо прожорливых блоков, которые не меняются (многоуровневое меню, выборки и прочие блоки на главной, вывод боковой колонки с кучей банеров или слайдеров... иногда даже вывод дерева разделов и подразделов можно пропустить через html кэширование)

*

Rodogor

  • ***
  • 189
  • +24/-0
    • Просмотр профиля
Re:Оптимизация, кэширование.
« Ответ #3 : 27 Февраля 2013, 11:34:13 »
1. практический и наверное самый громадный момент, это оптимизация не генерации html системой, а подгрузка всего остального.
Проблемные места:
  - бездумно подключенные css и js пачками,
  - вывод кучи не оптимизированных картинок товаров,
  - вывод кучи скрытых блоков, которые по хорошему надо генерить через ajax,
  - не оптимизированная верстка самого шаблона (сплит мелких картинок),
  - запрос всех ресурсов с одного хоста (что приводит к задержки загрузки, так как параллельные запросы имеют ограниченны определенным числом),
  - вбивание многих декоративных элементов в html (а надо бы в css)

С этим у меня вроде нормально. Использую ajax и json, где это можно. Автокомплиты, рейтинги, голосовалки.... Для голосовалок и рейтинговом формирую на смеси xslt и javascript  массив, затем после загрузки страницы формирую результат уже. Код выглядит очень стрёмно, но я специально искал - народ так делает, так что ничего страшного. Для примера кусок кода:
var select = $('#cuselFrame-<xsl:value-of select="@prop_id"/>');
select.removeClass('classDisCusel').find('.cuselText').html('<xsl:value-of select="@value_name"/>');
select.find('span.cuselActive').removeClass('cuselActive');
select.find('span[val=<xsl:value-of select="@value"/>]').addClass('cuselActive');


2. шаблонизатор
   - чистота шаблонов (чем меньше суммарно весят ваши xslt шаблоны, тем лучше),
   - работа с данными одинаковых запросов через переменную (то есть если нам надо 2 раза вызывать emarket/cart то лучше это сделать через переменную, которую после и использоваться для всех apply-templates),   
   - кеширование udata запросов через параметр  ?expire.
   - отказ от лишних upage обращений для доп поле используя параметр получения расширенных полей или групп полей при вызове макроса

Тут интереснее....

Шаблоны у меня весят не мало, но часто из-за разных вариантов развития событий. К примеру, может использоваться несколько вариантов каталогов и т.п... Соответственно в зависимости от object-type разные варианты.
Я как только начал изучать umi и xslt сильно накосячил, сделав дико нагруженные xslt шаблоны, очень криво всё сделал - работало медленно и тупо. В итоге пришлось разбираться и вникать.. Вообщем с этим вроде разобрался, сейчас пишу хороший код (на мой взгляд).
Переменные я использую очень активно. В xpath ../../ так же часто использую - возвращаюсь вверх по дереву, а не делаю запрос.
Кэширование запросов через ?expire... Пробовал смотреть как оно работает. Работает так: к примеру, на старнице дважды вызывается тот самый emarket/cart - вот второй раз он вызываться не будет. Если обнавляем страницу - всё по новой, первый запрос улетает, второго нет....Я немного иначе предствалял работу кэширования (не, ну корзину ясное дело кэшировать не стоит)... К примеру, запросили меню многоуровневое, указали кэшу день или час. Первый пользователь зашёл, закэшировалось всё, теперь остальным будет отдаваться кэш....
Отказ от лишних upage - я вообще почти отказался от манипуляций в xslt, я стараюсь всё готовить на api, на xslt лишь забираю готовые результаты. Написал кастомы, которые гуляют со мной от проекта к проекту - к примеру getEditForm, который выводит только выбранный item для field типа relation, а не весь справочник. Ну и так много чего такого, что вроде облегчает.. Постарался уйти от узконаправленности и стараюсь выводить всё как в формате umiDump - потом проще будет разбриаться.

3. работа макросов
  - чистота логики (убирать и оптимизировать все лишнее , все доп вызовы, которых можно было бы избежать... например использовании demodizzy call-template для вывода уменьшенной картинки на странице товара, там происходит передача id страницы и название поля и последующее получение через upage ссылки на картинку, но она нам изначально была известна, ведь мы на странице товара)
  - иногда делаю переписывание стандартных макросов в сторону вывода доп информации, которую иначе пришлось бы получать доп запросами из xsl шаблона
  - включенный кеш в самой umi (правда уже после тестов корректной работы сайта с точки зрения тз)
  - использование html кеширования результатов для особо прожорливых блоков, которые не меняются (многоуровневое меню, выборки и прочие блоки на главной, вывод боковой колонки с кучей банеров или слайдеров... иногда даже вывод дерева разделов и подразделов можно пропустить через html кэширование)
call-template стараюсь не использовать. У меня как правило задачи достаточно сложные - куча связанных товаров, выбор цветов-размеров-видов (и уже вообще любого числа любых модификаций, привязка к фото и т.п..), там всё кастомами и на api, результатом приходят готовые массивы с фотками, id-шниками свойств и т.п...
Стандартные макросы вообще уже почти не использую... Как минимумум перепишу для того, что бы не рухнуло после обновления (всегда надеюсь, что обновляться будет, но после меня ещё ниодин сайт не остался с такой возможностью :) )
Кэш в umi - сколько не пытался его тыкать, так нормальную работу и не увидел. Какие-то мутные алгоритмы, всё реально дольше начинает работать.... Как им правильно-то пользоваться ?
HTML кэширование - активно юзаю. Если нужно выводить на главной к примеру последние поступления/новинки/акции и т.п., то кэширую их, а потом на js делаю рандом, что бы разные моргали....

*

Rodogor

  • ***
  • 189
  • +24/-0
    • Просмотр профиля
Re:Оптимизация, кэширование.
« Ответ #4 : 14 Марта 2013, 11:24:25 »
В кодэ от ю*исофтовцве часто встречается такой момент...
Возьмём рассылки.
Тип данных - рассылка
Тип данных - выпуск рассылки
Тип данны - сообщение рассылки.
Рассылка существует всегда, выпуск рассылки - меняется каждый раз при рассылке, сообщения привязываются к выпуску

Я бы всё это связал полем типа "выпадающий список", а они связывают тупо полем "строка" в котором записывают стройко id объекта. Я так понимаю, что это лучше для БД - меньше записей, ибо походу структура cms говяная, всё фигачится всего в пару таблиц и для записи одного объекта создаётся просто нереальное количество строк в таблице(-ах).

Вы как связываете объекты в подобных ситуациях ?


*

admin

  • *****
  • 2419
  • +172/-1
    • Просмотр профиля
Re:Оптимизация, кэширование.
« Ответ #5 : 15 Марта 2013, 07:40:56 »
Вы как связываете объекты в подобных ситуациях ?

в каких именно?

*

Vladimir

  • ****
  • 271
  • +46/-0
    • Просмотр профиля
Re:Оптимизация, кэширование.
« Ответ #6 : 15 Марта 2013, 14:53:47 »
Для БД это все равно, потому что в обоих случаях есть только одна пара "id поля" - "значение поля".
Разница м.б. для административного интерфейса: если предполагается человеческий фактор - то список. Если для внутреннего использования - число нагляднее.