Повторюсь с предыдущего поста:
Новое ТЗ – предоставлен сайт с временем открытия “морды” 10 секунд (в не авторизованном режиме).
В рамках этого ТЗ подразумеваю будет не один пост 🙂
Что понравилось – лицензия активна и актуальна, а движек не обновлялся с 2012года 🙂

Теперь к делу:
Пока у меня чистится БД приступлю к анализу загрузки странички – 10 сек это много!
Сначала решил глянуть FireBug-ом визуально в онлайн режиме в режиме Сеть – собственно, тормозит именно сам скрипт первый же GET отдаётся с кодом 200 размером 12кб и временем 10 секунд!
а в авторизованном режиме 16 сек!
Едем далее – авторизация, врубаем дебаг режим и обновляем страничку

Ради интереса замерил производительность конфигурации чтобы сразу исключить железо из вариантов тормознутости сайта – индекс 9, маловато конечно, но явно не причина столь медленной отдачи, к тому же хостинг специально под Битрикс – железо отметаем.
Далее пробежался по компонентам и посмотрел обращения к БД и время загрузки.
Нашел

идём в настройки и моя догадка подтверждается – время кэширования 0 – явно неоправданно, думаю смело можно поставить час т.к. врят ли категории товаров будут так часто обновляться

Обновляем разок и картина кардинально меняется!

Остальные 2 секунды ушли на 3 вызова компонента yenisite:catalog.section.all

yenisite:catalog.section.all: 1.5538 с; Запросов: 37 (0.7377 с); кеш: 59 КБ
yenisite:catalog.section.all: 0.6714 с; Запросов: 17 (0.6426 с); кеш: 4 КБ
yenisite:catalog.section.all: 0.7575 с; Запросов: 5 (0.7391 с)

в которых кэширование включено, но видимо не работает – скорее всего компонент тоже сильно устарел и требует обновления (yenisite очень сильная студия – не раз сталкивался по работе)
Для проверки предположения я временно вырубил все 3 компонента и обновил в режиме дебага страничку

Да – предположение оказалось верным!
И судя по названию catalog.section.all – сильно похоже на то, что yenisite просто скопировали стандартный catalog.section.all для внесения каких то правок (который устарел на 4 года, т.к. обновления движка на скопированные компоненты не влияет), накосячив при этом с кэшем (а может косяк и был уже – компонент то ещё от 12й версии унаследовался).
Как вариант – не влезать в суть компонента, просто подключить механизм кэширования на выход компонента (не есть гуд, но работать будет).
Либо поковырять компонент и шаблон компонента – сильно подозреваю, что напихали вызовов к БД прямо в шаблон.
Этим и займусь – для тестирования врубаем назад вызов компонент и смотрим шаблон
(дак вотты какой Битроник! воскликнул я роясь в шаблонах 🙂 оказывается магазин – это готовое решение для интернет магазина “Битроник” от Енисайт-а которое по-хорошему тоже не помешало бы ИМХО обновить до актуального)
Никаких обращений к БД в шаблоне не заметил (Енисайт – молодца! держим марку!), но проблему это не решило 🙂
На всякий случай я template.php и result_modifier.php обнулил и ещё раз дёрнул страничку – да, время генерации и кол-во SQL запросов на компонентах не изменилось, значит дело в компоненте либо его параметрах – вернём назад шаблон и займёмся анализом компонента.
Чуток посмотрев компонент на предмет CACHE параметров, обнаружил СACHE_FILTER (“Кэшировать при установленном фильтре” который прятался в “дополнительных настройках” компонента) – врубаем, обновляем (тут следите чтоб в адресной строке не было clear_cache=Y – иначе все компоненты будут без настроек кэширования отрабатывать) и о чудо!

Запросов к БД минимальное кол-во, а время генерации думаю сократиться если выйти из режима администрирования.
Выходим – смотрим время FireBug-ом.

844 милисекунды !
Вуаля!
Ещё меня captcha.php заинтересовала – посмотрел в шаблоне, висит на заказе обратного звонка, а кнопочку для сего действа на морде я хоть убей не нашел!
Если ещё этот вызов убрать – общее время загрузки сайта ещё ускорится, но это уже может повредить функционалу – если я не нашел вызова, не значит что его нет 🙂
Да и оптимизировать уже смысла не вижу – время загрузки очень даже очень 🙂
Задачу считаю выполненной!

P.S. Енисайт – сорри за плохие предположения в вашу сторону 🙂