Оптимизация БД: что такое Application: afterDispatch

  • 11 Ответов
  • 756 Просмотров

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

*

ensonar

  • Захожу иногда
  • **
  • 12
  • 1
Мой сайт имеет много страниц свыше 50000, страницы грузятся по времени 1.5 сек. Включил режим debug и увидел что собственно все время уходит на Application: afterDispatch

Время: 0.0 ms / 0.0 ms Память: 0.748 MB / 0.75 MB Application: afterLoad
Время: 84.6 ms / 84.6 ms Память: 4.496 MB / 5.24 MB Application: afterInitialise
Время: 30.5 ms / 115.2 ms Память: 0.913 MB / 6.16 MB Application: afterRoute
Время: 1322.1 ms / 1437.3 ms Память: 3.159 MB / 9.32 MB Application: afterDispatch
Время: 6.5 ms / 1443.8 ms Память: 0.185 MB / 9.50 MB Application: beforeRenderModule mod_custom (ЛИ)
Время: 2.8 ms / 1446.6 ms Память: 0.039 MB / 9.54 MB Application: afterRenderModule mod_custom (ЛИ)
Время: 0.2 ms / 1446.8 ms Память: 0.000 MB / 9.54 MB Application: beforeRenderModule mod_sj_flat_menu (Меню)
Время: 9.8 ms / 1456.5 ms Память: 0.087 MB / 9.63 MB Application: afterRenderModule mod_sj_flat_menu (Меню)
Время: 0.1 ms / 1456.6 ms Память: 0.000 MB / 9.62 MB Application: beforeRenderModule mod_custom ( реклама)
Время: 0.7 ms / 1457.4 ms Память: 0.007 MB / 9.63 MB Application: afterRenderModule mod_custom (реклама)
Время: 0.2 ms / 1457.5 ms Память: 0.000 MB / 9.62 MB Application: beforeRenderModule mod_custom (адсенс )
Время: 0.7 ms / 1458.2 ms Память: 0.007 MB / 9.63 MB Application: afterRenderModule mod_custom (адсенс )
Время: 0.2 ms / 1458.5 ms Память: 0.000 MB / 9.63 MB Application: beforeRenderModule mod_menu (Main Menu)
Время: 4.3 ms / 1462.8 ms Память: 0.061 MB / 9.69 MB Application: afterRenderModule mod_menu (Main Menu)
Время: 6.6 ms / 1469.4 ms Память: 0.170 MB / 9.86 MB Application: afterRender

Использование памяти 9.89 MB (10 374 856 Байт)
25 SQL-запросов зафиксировано

В оптимизации несилен, это я так понимаю Application: afterDispatch идет поиск по таблице нужного материала? А так как их много в таблице с контентом то выходит много времени?  А можно что то сделать что бы уменьшить это время? Кеширование не предлагать)

*

b2z

  • Support Team
  • *****
  • 7450
  • 741
  • Разраблю понемногу
afterDispatch - это значит, что прошёл полный цикл и компонент обработан. И да, скорее всего проблема в кол-ве материалов.
Что показывает SQL профилирование?

*

ensonar

  • Захожу иногда
  • **
  • 12
  • 1
Где это посмотреть конкретно? та много чего показывает дебаг

Выбрал самый долгий запрос:

Время запроса: 765.06 ms После последнего запроса: 7.56 ms Память запроса: 0.353 MB Память до запроса: 7.886 MB Выбрано строк: 21499

SELECT b.rules

  FROM #_assets AS a

  LEFT JOIN #_assets AS b
  ON b.lft <= a.lft
  AND b.rgt >= a.rgt

  WHERE (a.name = 'com_content.article.60294')

  GROUP BY b.id, b.rules, b.lft

  ORDER BY b.lft
« Последнее редактирование: 19.02.2016, 14:07:17 от ensonar »

*

ensonar

  • Захожу иногда
  • **
  • 12
  • 1
Блин капец) только что определил опытным путем что влияло на такую загрузку Application: afterDispatch.
Оказалось что так загружал стандартный плагин Joomla "Контент - Навигация по страницам" , который дает навигацию "вперед - назад"  между материалами категории. Отключил его и время упало до 150 миллисекунд. Наверное придется жить без постраничной навигации)

*

b2z

  • Support Team
  • *****
  • 7450
  • 741
  • Разраблю понемногу
Да, это самое узкое место и есть - таблица #_assets. Я думаю, что тут надо долждаться ответа спецов по оптимизации базы данных.

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

Вот здесь все изменения, которые нужно внести для улучшения. По сути всё в одном файле libraries/joomla/access/access.php.
Сделайет бэкап Вашего файлика libraries/joomla/access/access.php и замените его содержимое на это.

Обязательно отпишитесь, помогло или нет.

*

ensonar

  • Захожу иногда
  • **
  • 12
  • 1
сделал:

Время с включенным плагином и новым acces.php в дебаге ~ 400 миллисекунд


Зато если проверять через https://developers.google.com/speed/pagespeed/insights/
Время с включеным плагином и новым acces.php ~ 1000 миллисекунд

Без плагина в этом сервисе показывает время около 300 милисекунд
Без плагина в дебаге 150 миллисек
« Последнее редактирование: 19.02.2016, 15:12:02 от ensonar »

*

b2z

  • Support Team
  • *****
  • 7450
  • 741
  • Разраблю понемногу
Странно, что Google так реагирует. По сути дебаг - это то место, на которое нужно полагаться. Но всё равно видно, что этот патч реально работает. Спасибо за тест. Другим будет полезно.

*

ensonar

  • Захожу иногда
  • **
  • 12
  • 1
С новым acces.php стало быстрее но все равно не так как по сравнению с отключенным плагином навигации. Без плагина все просто летает)
Хочу попробовать поставить альтернативный плагин на навигацию например PAGE NAVIGATION WITH TITLES

*

ensonar

  • Захожу иногда
  • **
  • 12
  • 1
Хотя не) с альтернативным плагином еще дольше грузиться))))

*

ensonar

  • Захожу иногда
  • **
  • 12
  • 1
появился еще вопрос.  А есть ли подобное решение для более быстрого вывода например похожих материалов. На большом сайте генерация похожих материалов вызывает проблемы.

*

ensonar

  • Захожу иногда
  • **
  • 12
  • 1
А есть ли возможность закешировать каждый модуль похожих материалов для каждой страницы отдельно, то есть не кешировать всю страницу а только модуль на странице, ибо кешировать все страницы требует очень много места на хостинге.