Эффективность core Joomla - Joomla 3.x: Установка, обновление и настройка

Хостер начал жаловаться на повышенную нагрузку сервера моим сайтом. Сперва грешил на сторонние расширения, а потом залез в Дебаг Консоль и обалдел.
Свыше 90% времени запросов к БД сжирал модуль "Последние статьи категории". При четырех категориях и 40000 статьях он отрабатывал секунду, при выборке из 8 категорий (больше никаких фильтров) - почти 4 секунды.
Немало времени занимал модуль "Самые читаемые" - выборка 5 самый читаемых статей из всех категорий.
И немерянное число секунд сжирал модуль "Связанные материалы", когда показывался. Как я понял, он при каждом запросе шерстит всю базу на ключевые слова безо всяких индексов. Это же вообще идиотизм.

Я понимаю, что 40000 статей это много, но все-таки...
Поискал в консоли SQL запрос для "Последние статьи категории" - пятнадцатиэтажное выражение.
Что теперь, свои простые модули писать с прямым доступом к БД, что ли?
Joomla только для средних сайтов?

Можно побольше конкретики и без обобщенных пафосных возгласов?

безо всяких индексов.

С чего вы взяли?

Что теперь, свои простые модули писать с прямым доступом к БД, что ли?

А что, прямого доступа к БД не было?

С чего вы взяли?

И где они? И если есть, почему запрос так долго выполняется?

А что, прямого доступа к БД не было?

Вы поняли, что я написал? Я спросил, почему простые (по своей логике) запросы к БД в Joomla выполняются через пятнадцатиэтажную SQL жопу с дикими тормозами.

Еще вопрос производительности - таблица SESSION у меня за несколько дней вырастает до 500Мб (половина все базы). Почему мне вручную нужно ее очищать?
500 пользователей в сутки.

40к материалов? небось в стандартном менеджере материалов? Тогда сайт обречён )

Я спросил, почему простые (по своей логике) запросы к БД в Joomla выполняются через пятнадцатиэтажную SQL жопу с дикими тормозами.

Что честно? Простые? ну ок.. увы всё это происходит потому что запросы далеко не простые...

Еще вопрос производительности - таблица SESSION у меня за несколько дней вырастает до 500Мб (половина все базы). Почему мне вручную нужно ее очищать?
500 пользователей в сутки.

Какое время жизни сессии стоит в админке?

40к материалов? небось в стандартном менеджере материалов? Тогда сайт обречён )

Поясните, пожалуйста.
Особых проблем кроме тормозящих стандартных модулей на фронтэнде не наблюдаю из-за объема материалов.

Какое время жизни сессии стоит в админке?

Большое. Какое это имеет отношение в незалогиненным пользователям?
Зарегистрирован только один аккаунт.

Какое это имеет отношение в незалогиненным пользователям?

самое что ни на есть прямое. сессии и залогиненые пользователи - это две абсолютно разные вещи. сессии создаются для всех, а залогинен пользователь у вас или нет для php вообще все равно

Что честно? Простые? ну ок.. увы всё это происходит потому что запросы далеко не простые...

select * from content where cat_id in (2,4,6) order by id desc limit 10

Что сложного?
Есть еще фильтры по published, access  и прочее, но это ерунда.

---
С сессиями понятно, поэкспериментирую.
Хотя в подсказке ясно написано про залогиненные сессии:

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

Поясните, пожалуйста.
Особых проблем кроме тормозящих стандартных модулей на фронтэнде не наблюдаю из-за объема материалов.

Проблема в дереве ACL (Списки управления доступом), из-за которых и идёт тормознутость.. при чём наверно оптимизация какая то была небольшая, у меня раньше на 20к материалов начинались серьёзные тормоза...

Большое. Какое это имеет отношение в незалогиненным пользователям?
Зарегистрирован только один аккаунт.

вот по тому у вас и получается база по 500 метров в день что вы не понимаете что и гостевой аккаунт заносится в в базу!

С сессиями понятно, поэкспериментирую.
Хотя в подсказке ясно написано про залогиненные сессии:

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

Вы же смотрели таблицу сессий, что ли не заметили такие поля:

Хотя в подсказке ясно написано про залогиненные сессии:

честно говоря не вижу в подсказке чего либо, что указывало бы на залогиненого пользователя

вот по тому у вас и получается база по 500 метров в день что вы не понимаете что и гостевой аккаунт заносится в в базу!

Уходим с сторону от темы, но чтобы закончить - а какой смысл хранить гостевую сессию, скажите, пожалуйста.
Для системы и для админа.
Зачем?

честно говоря не вижу в подсказке чего либо, что указывало бы на залогиненого пользователя

Безопасность и гости - как связаны?

select * from content where cat_id in (2,4,6) order by id desc limit 10

Что сложного?
Есть еще фильтры по published, access  и прочее, но это ерунда.

Честно? вот прямо такой запрос: select * from content where cat_id in (2,4,6)
и нет ни одного джойна для проверки прав доступа к категории, ни одного джойна для проверки прав доступа к материалу (К таблице #__assets)

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

где вы такое нашли без понятия, у вас может какая то не официальная сборка?

Уходим с сторону от темы, но чтобы закончить - а какой смысл хранить гостевую сессию, скажите, пожалуйста.
Для системы и для админа.
Зачем?

Видели когда нибудь в инет магазинах систему когда вы покупаете товар будучи неавторизированым пользователем, а потом можете закрыть сайт и через несколько часов зайти, а ваш товар по прежнему висит в корзине?

вот только что
Время: 7.03 ms / 890.09 ms Память: 0.327 MB / 6.35 MB Application: afterRenderModule mod_articles_category (АШ)
Время: 0.11 ms / 890.20 ms Память: 0.000 MB / 6.11 MB Application: afterRenderModule mod_dinamods (Последние новости)
Время: 0.86 ms / 891.06 ms Память: 0.064 MB / 6.17 MB Application: beforeRenderModule mod_articles_popular (Самое популярное)
Время: 6292.26 ms / 7183.31 ms Память: 0.225 MB / 6.40 MB Application: afterRenderModule mod_articles_popular (Самое популярное)



Ну не должно быть такого, ну не должно же.

Уходим с сторону от темы, но чтобы закончить - а какой смысл хранить гостевую сессию, скажите, пожалуйста.
Для системы и для админа.
Зачем?

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

Что теперь, свои простые модули писать с прямым доступом к БД, что ли?
Joomla только для средних сайтов?

Интересно посмотреть на запрос к БД, а именно на условия выборки.
Для уменьшения нагрузки на БД и уменьшения времени отдачи ответа сервера, используется кеширование . В Joomla и Битрикс так написано в ман.

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

Да, мне они не нужны. Кроме того, сессии обрабатываются не только БД (куки, url-rewriting etc.).
Я отключил обработку сессий базой данных ( "Обработчик сессий" => нет), но в эту таблицу все равно продолжает писаться информация о сессиях.

Интересно посмотреть на запрос к БД, а именно на условия выборки.
Для уменьшения нагрузки на БД и уменьшения времени отдачи ответа сервера, используется кеширование . В Joomla и Битрикс так написано в ман.

Вот самый "простой", видимо - последние статьи из определенной категории:

SELECT c.id, c.asset_id, c.access, c.alias, c.checked_out, c.checked_out_time,
         c.created_time, c.created_user_id, c.description, c.extension, c.hits, c.language, c.level,
         c.lft, c.metadata, c.metadesc, c.metakey, c.modified_time, c.note, c.params, c.parent_id,
         c.path, c.published, c.rgt, c.title, c.modified_user_id, c.version,
  CASE WHEN CHAR_LENGTH(c.alias)!= 0 THEN CONCAT_WS(':', c.id, c.alias) ELSE c.id END as slug

  FROM jos_categories as c

  LEFT JOIN  (SELECT cat.id as id
  FROM jos_categories AS cat JOIN jos_categories AS parent
  ON cat.lft BETWEEN parent.lft
  AND parent.rgt
  WHERE parent.extension = 'com_content'
  AND parent.published != 1
  GROUP BY cat.id) AS badcats
  ON badcats.id = c.id

  LEFT JOIN jos_categories AS s
  ON (s.lft <= c.lft
  AND s.rgt >= c.rgt) OR (s.lft > c.lft
  AND s.rgt < c.rgt)

  WHERE (c.extension='com_content' OR c.extension='system')
  AND c.access IN (1,1,2,3,6)
  AND c.published = 1
  AND badcats.id is null
  AND s.id=15

  GROUP BY c.id, c.asset_id, c.access, c.alias, c.checked_out, c.checked_out_time,
          c.created_time, c.created_user_id, c.description, c.extension, c.hits, c.language, c.level,
          c.lft, c.metadata, c.metadesc, c.metakey, c.modified_time, c.note, c.params, c.parent_id,
          c.path, c.published, c.rgt, c.title, c.modified_user_id, c.version



Ну а по поводу кэша - в мануале все красиво, а я не смог заставить модули кэшироваться - и прогрессивное стоит, и время, а все равно по консоли каждый раз в базу они лезут.

Кроме того, сессии обрабатываются не только БД (куки, url-rewriting etc.).

куки, url-rewriting etc. - это способ передать с клиента (браузера) идентификатор сессии. а хранятся сессии все равно на сервере, либо в базе либо в файлах. иных вариантов нет и не будет наверное никогда.

Я отключил обработку сессий базой данных ( "Обработчик сессий" => нет), но в эту таблицу все равно продолжает писаться информация о сессиях.

у меня нет. какая версия Joomla?

Ну а по поводу кэша - в мануале все красиво, а я не смог заставить модули кэшироваться - и прогрессивное стоит, и время, а все равно по консоли каждый раз в базу они лезут.

потому что нужно стандартное, а не прогрессивное.

а я не смог заставить модули кэшироваться - и прогрессивное стоит,

Вот же ведутся на название кеширования. А почитать про различие между прогрессивным и стандартным, которое предпочтительнее .

Вот самый "простой", видимо - последние статьи из определенной категории:

Я хочу посмотреть на составленный вами запрос. Я ваш пост цитировал.
Запросы Джумла и расширений я знаю,когда в логе медленных запросов к БД, встречаю время более 5 сек.

Вот самый "простой", видимо - последние статьи из определенной категории:

только это что то не то, там выборка только категорий, из таблицы content (материалов) ничего не выбирается...

У меня пока только одно предложение
написать самому подобный модуль упустив работу с ACL и Access (скорее всего для вашего сайта это не нужно)
и запрос будет тогда реально простой, в стиле: SELECT id, title, alias, catid, introtext, images, ctreated FROM #__content WHERE catid in (2,4,6) ORDER BY hits DESC LIMIT 0,5

где вы такое нашли без понятия, у вас может какая то не официальная сборка?

У меня 3.6.5 официальная. Но "Общих сессий" нет.

Честно? вот прямо такой запрос: select * from content where cat_id in (2,4,6)
и нет ни одного джойна для проверки прав доступа к категории, ни одного джойна для проверки прав доступа к материалу (К таблице #__assets)

Это понятно, что чем большее количество возможностей хочется предусмотреть, тем сложней получается конструкция, и в итоге гвозди приходится забивать микроскопом. Но возможна же оптимизация/компиляция. Если мне не нужно, например, по определенным категориям проверять ACL, то это нужно предусмотреть. Если этот фаервол - основной тормоз.


Итак, вывод: стандартная Joomla для сайтов с 10К+ статьями особо не предназначена.

только это что то не то, там выборка только категорий, из таблицы content (материалов) ничего не выбирается...

да, вот он

написать самому подобный модуль упустив работу с ACL и Access (скорее всего для вашего сайта это не нужно)

Да, я понял. Правда есть еще вариант - уменьшить БД.

А почитать про различие между прогрессивным и стандартным, которое предпочтительнее .

? Стандартное кэширует страницу, прогрессивное - модули по отдельности. Или не то? Пробовал оба, кэширования не заметил.

Вообше, идеальное кэширование (для моего случая) должно быть активным - кэш модулей меняется по триггеру (добавление нового материала в категорию, например). Предусмотреть ивенты и в настройках модуля явно указывать, когда обновлять кэш. В остальном - статика. Это будет самый оптимальный вариант. А иначе или изменения упускаешь, или нагрузка.

Стандартное кэширует страницу, прогрессивное - модули по отдельности. Или не то?

не то. вам нужно стандартное.

Пробовал оба, кэширования не заметил.

значит вы его просто напросто вообще не настроили.

кэш модулей меняется по триггеру (добавление нового материала в категорию, например)

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

потому что нужно стандартное, а не прогрессивное.

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

куки, url-rewriting etc. - это способ передать с клиента (браузера) идентификатор сессии. а хранятся сессии все равно на сервере, либо в базе либо в файлах. иных вариантов нет и не будет наверное никогда.

Насколько я знаю, не так. Сервер может отправлять каждый раз клиенту информацию через куки или url, клиент ему обратно - сервер прочитывает это, анализирует и так держится сессия без хранения данных на сервере.

ну так чтобы узнать есть ли новый материал, надо лезть в базу

Неправильно. При сохранении материала срабатывает триггер. Автоматически обновляется кэш модулей, висящих на этом триггере.
Обновлять весь кэш при каждом добавлении - затратно. Кроме того, материалы могут добавляться автоматически или еще как.

Поставил стандартное, обновляю страницу - все равно эти модули столько же примерно каждый раз времени занимают при запросе к БД

значит кеширование у вас не работает.

Насколько я знаю, не так

вы знаете неверно. в нормальной реализации сессии никогда так хранится не будут, ибо в сессиях хранится то, что не должно попадать на клиента. они должны хранится только на сервере. то, что вы описали, конечно технически возможно, но ни один нормально думающий программист так делать не будет.

Неправильно

ну так все ж в ваших руках, сделайте правильно. логику вы описали какая вам нужна, осталось реализовать.

Вообше, идеальное кэширование (для моего случая) должно быть активным - кэш модулей меняется по триггеру (добавление нового материала в категорию, например). Предусмотреть ивенты и в настройках модуля явно указывать, когда обновлять кэш. В остальном - статика. Это будет самый оптимальный вариант. А иначе или изменения упускаешь, или нагрузка.

Можете попробовать Jotcache настроить - исключите динамические модули, остальное пусть кешируется.

ну так все ж в ваших руках, сделайте правильно. логику вы описали какая вам нужна, осталось реализовать.

Вы мне предлагаете по сути писать расширение, в то время, как для меня Joomla - просто орудие, которое я пытаюсь правильно использовать для своей работы, а не тратить немалое время на его усовершенствование.

вы знаете неверно. в нормальной реализации сессии никогда так хранится не будут, ибо в сессиях хранится то, что не должно попадать на клиента. они должны хранится только на сервере. то, что вы описали, конечно технически возможно, но ни один нормально думающий программист так делать не будет.

У меня есть простенький форум без регистрации, но с никами пользователей, которые хранятся в куках. И пароли тоже, при желании, включаются. При заходе во второй раз пользователь сразу видят свое имя в поле "Ник". Это сессии? Сессии. Я на сервере что-то храню? Нет. Пользуюсь $_SESSION? Нет. Может я и не нормально думающий, но форум работает как нужно. Не всё же уперлось в онлайн-магазины и банки с их безопасностью.

Можете попробовать Jotcache настроить - исключите динамические модули, остальное пусть кешируется.

Спасибо, попробую. Хотя динамические модули и дают 90% загруженности сервера.