Повторюсь с предыдущего поста:
Новое ТЗ — предоставлен сайт с временем открытия «морды» 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. Енисайт — сорри за плохие предположения в вашу сторону 🙂