Ускорить загрузку сайта - Joomla 3.x: Установка, обновление и настройка

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

Вот инфа из отладки:
Время: 0.0 ms / 0.0 ms Память: 0.585 MB / 0.58 MB Application: afterLoad
Время: 185.2 ms / 185.2 ms Память: 5.647 MB / 6.23 MB Application: afterInitialise
Время: 257.4 ms / 442.6 ms Память: 1.975 MB / 8.21 MB Application: afterRoute
Время: 1447.3 ms / 1890.0 ms Память: 7.763 MB / 15.97 MB Application: afterDispatch
Время: 41.9 ms / 1931.8 ms Память: 0.363 MB / 16.33 MB Application: beforeRenderModule mod_roknavmenu ()
Время: 100.5 ms / 2032.3 ms Память: 1.438 MB / 17.77 MB Application: afterRenderModule mod_roknavmenu ()
Время: 0.3 ms / 2032.6 ms Память: 0.000 MB / 17.66 MB Application: beforeRenderModule mod_roknavmenu ()
Время: 68.9 ms / 2101.5 ms Память: 0.290 MB / 17.95 MB Application: afterRenderModule mod_roknavmenu ()
Время: 13.2 ms / 2114.7 ms Память: 0.000 MB / 17.93 MB Application: beforeRenderModule mod_roknavmenu (Главное меню)
Время: 6.9 ms / 2121.5 ms Память: 0.129 MB / 18.06 MB Application: afterRenderModule mod_roknavmenu (Главное меню)
Время: 0.1 ms / 2121.7 ms Память: 0.000 MB / 18.03 MB Application: beforeRenderModule mod_login (Вход на сайт)
Время: 38.7 ms / 2160.3 ms Память: 0.513 MB / 18.54 MB Application: afterRenderModule mod_login (Вход на сайт)
Время: 0.2 ms / 2160.5 ms Память: 0.000 MB / 18.52 MB Application: beforeRenderModule mod_menu (Реклама)
Время: 5.7 ms / 2166.2 ms Память: 0.060 MB / 18.58 MB Application: afterRenderModule mod_menu (Реклама)
Время: 0.1 ms / 2166.3 ms Память: 0.000 MB / 18.57 MB Application: beforeRenderModule mod_search (Поиск)
Время: 4.3 ms / 2170.6 ms Память: 0.034 MB / 18.60 MB Application: afterRenderModule mod_search (Поиск)
Время: 0.1 ms / 2170.7 ms Память: 0.000 MB / 18.60 MB Application: beforeRenderModule mod_custom (Дата/Время)
Время: 3.0 ms / 2173.7 ms Память: 0.010 MB / 18.61 MB Application: afterRenderModule mod_custom (Дата/Время)
Время: 0.1 ms / 2173.9 ms Память: 0.000 MB / 18.60 MB Application: beforeRenderModule mod_custom (Наш баннер)
Время: 0.4 ms / 2174.3 ms Память: 0.007 MB / 18.61 MB Application: afterRenderModule mod_custom (Наш баннер)
Время: 0.1 ms / 2174.4 ms Память: 0.000 MB / 18.61 MB Application: beforeRenderModule mod_custom (Полезное)
Время: 0.9 ms / 2175.3 ms Память: 0.011 MB / 18.62 MB Application: afterRenderModule mod_custom (Полезное)
Время: 0.1 ms / 2175.4 ms Память: 0.000 MB / 18.62 MB Application: beforeRenderModule mod_custom (Полезное)
Время: 0.6 ms / 2176.0 ms Память: 0.005 MB / 18.62 MB Application: afterRenderModule mod_custom (Полезное)
Время: 0.1 ms / 2176.1 ms Память: 0.006 MB / 18.63 MB Application: beforeRenderModule mod_breadcrumbs (Навигатор сайта (путь к странице))
Время: 16.0 ms / 2192.2 ms Память: 0.064 MB / 18.69 MB Application: afterRenderModule mod_breadcrumbs (Навигатор сайта (путь к странице))
Время: 0.3 ms / 2192.5 ms Память: 0.001 MB / 18.69 MB Application: beforeRenderModule mod_roksprocket (FP Slideshow - RokSprocket Features)
Время: 185.1 ms / 2377.6 ms Память: 1.815 MB / 20.51 MB Application: afterRenderModule mod_roksprocket (FP Slideshow - RokSprocket Features)
Время: 128.3 ms / 2505.9 ms Память: 0.537 MB / 21.04 MB Application: afterRender

В профилировании SQL запросов, query end - обычно тормозит всё.
Самый длинный запрос к БД

очень похоже на выборку материалов для главной.
Вот тут в принципе все объясняется, а именно что на тысячах материалов тормоза есть, и что спасет лишь кеширование плагином.
Кеширование запросов мускулом тут не спасет, так как часть касаемая даты '2014-09-01 08:39:40' постоянно меняется, то есть запрос фактически кешируется на секунду.
Лучше переписать запрос, чтобы было округление до '2014-09-01 00:00:00' - тогда запрос будет дергаться из кеша весь день, но невозможно будет указать точное время снятия матеарила с публикации.
В этом случае (query cache) после кеширования его мускулом он будет отрабатывать моментально, если не изменятся данные ни в одной из перечисленных таблиц (а именно пользователи, категории, материалы, материалы для главной, рейтинг) и запрос не выпадет из кеша.
Или урезать "фишки" Joomla с главной, например вообще не проверять снят ли материал с публикации по дате, забить на рейтинг - это ускорит работу запроса и без query cache.

UPD.
Это самый долгий или самый длинный запрос? Время выполнения весьма косвенно связано с длинной запроса, я могу придумать запрос длиннее этого со временем выполнения 2 миллисекунды.

Или урезать "фишки" Joomla с главной, например вообще не проверять снят ли материал с публикации по дате, забить на рейтинг - это ускорит работу запроса и без query cache.

А как это сделать? Через админку как я понял никак? )) Или отключить что можно.

Это самый долгий или самый длинный запрос? Время выполнения весьма косвенно связано с длинной запроса, я могу придумать запрос длиннее этого со временем выполнения 2 миллисекунды.

Самый долгий, время выполнения колеблется сильно.

Да, через админку это не сделать никак. Только внести изменения в код. Для этого создать компонент, скопировав в него все файлы штатного компонента, переименовать его и внести изменения в код.
Или править штатный компонент, только эти правки затрутся при обновлении, но это возможно отследить если использовать систему контроля версий, например git.
Решение чисто на MySQL без переделки движка:
Изменить тип подсистемы хранения на InnoDB, в ней объединение таблиц работает быстрее
Делается это так:
ALTER TABLE `ixh95_content` ENGINE=INNODB;
Пройдите по все таблицам в запросе: ixh95_content_frontpage, ixh95_categories, ixh95_users, ixh95_content_rating
Также обновите MySQL до последней версии (5.6), где-то на зарубежном форуме об этом писалось, что более эфективно используется покрывающий индекс.
И этот индекс по каждой таблице следует построить:
ixh95_content_frontpage - по content_id
ixh95_categories - lft, rgt, extension, published
ixh95_users - name, email
ixh95_content_rating - rating_sum, rating_count

Надеюсь все перечислил. После этого делаем OPTIMEZE TABLE `ixh95_content` и других таблиц (не знаю, стоит ли делать сразу после постоения индекса, возможно они уже оптимизированы), EXPLAIN {запрос}, смотрим что получается. Можете выложить дамп этих таблиц, попробую сам.

Также тормоза по сортировке.
ORDER BY  c.lft, CASE WHEN a.publish_up = '0000-00-00 00:00:00' THEN a.created ELSE a.publish_up END  DESC,  a.created
Тут покрывающий индекс также невозможно использовать - разные таблицы, разный порядок сортировки (по убыванию, по возрастанию). Поэтому если админка позволяет, отключите лишние сортировки, оставив одну без условия CASE, например отключить сортировку по категориям и дате публикации, оставив по дате создания. Вообще сколько там записей в com_content?

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

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

В Joomla 3 таблицы уже в INNODB

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

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

Кэш включён, стоит компонент JotChahe, включено всё кроме кеша браузера. Так же стоит скрипт сжимающий, объединяющий и минимизирующий CSS и JS. Виртуальный хостинг MySQL обновить не могу, стоит 5.5.38

Записей в xh95_content - 15000. Соритровку через админку Joomla принципиально отключить, нельзя, а вообще сортировка на сайте не используется вроде, ну только по дате публикации.

Индексы добавлю сейчас, посмотрю.