Медленный SQL запрос на Joomla 3.6.2 - страница 3 - Joomla 3.x: Общие вопросы

Ради интереса очистите таблицу #__assets и скорость станет моментальной...

Печально это все. В конце концов на фронтенде можно было бы сделать проверку прав опционально. С такими запросами com_content просто неприменим для большого кол-ва материалов. А это новостные, вики-сайты и прочие. Довольно большой сегмент. Получается что тут либо cck использовать(которые вообщем то тоже особой скоростью не блещут) или самопис.

У меня сейчас 30 000 и сохранение менее 5 сек.

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

Прямо таки напришивается создание какого нибудь com_content_light для вывода материалов из com_content. Может быть даже удастся прикрутить к нему нормальный роутинг.

Прямо таки напришивается создание какого нибудь com_content_light для вывода материалов из com_content. Может быть даже удастся прикрутить к нему нормальный роутинг.

В большинстве случаев com_content хватает за глаза

Эта тема доказывает что com_content совершенно неприменим если материалов более чем несколько тысяч. Неоптимизированные запросы и большое кол-во лишнего функционала вызывают жуткие тормоза. Даже 6 секунд на запрос это полный капец.

Просто для широкой аудитории нет ничего ненужного: кто-то использует какие-то вещи, кто-то не использует

Установитл компонент, очистил кеш, зашел в материал - заполнил все поля и капчу. Все работает!

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

по поводу нагрузки, все так и осталось, нагрузка как была почти 100% так и осталась ((( что делать не знаю, может кто подскажет?

Откуда нагрузка, нужны более точное описание. Скажите что за сайт, сервер, сколько в день визитов ?

Делал ? Если нет зайди в свою базу и вверху нажми SQL и вставить этот запрос и нажми ОК.

DELETE FROM `cdnlp_assets` WHERE `name` LIKE '%com_content.article.%' AND `id`!=1

А кто сказал что прогрессивное кеширование создает меньшую нагрузку на хостинг, чем стандартное.
Проверьте сколько запросов от Яндекс и Google ботов в пики нагрузки.

используется прогрессивное кеширование

PHP   5.3

Советую перейти на стандартное, вот почему: http://joomlaforum.ru/index.php/topic,305344.new.html
Обновите до PHP 5.6 и включите opcache, станет ещё в половину быстрее работать

Обновите до PHP 5.6

Дело в том что Joomla не поддерживает opcache!

Спорить не буду, т.к. не знаю, что там включили или не включили, но есть независимые тесты. В своё время я сменил Xcache на opcache и php 5.3 на php 5.6 и проводил свои тесты. Утверждать, что php7 или 5.6 медленнее, чем 5.3 - это сомнительная идея, я не поддержу, php7 - это самолёт просто.
Joomla хранила свой кэш в оперативке с помощью Xcache, в остальном поддержка не нужна, это работает на уровне php. opcache быстрее, чем Xcache, а для хранения кэша в оперативке сейчас есть memcached. Но к примеру у меня ssd диски и прироста скорости в этом я не увидел.