Оптимизация Joomla (черновик) - страница 2 - Joomla 1.0: Установка, обновление и настройка

Fill - заходишь в админку - в конфигурации  врубаешь режим отладки

Спасибо, bzzik. Вижу 21 запрос к базе данных... Это много или мало? При условии, что на главной странице выведено 31 модуль случайных новостей и стлько же модулей последних новостей. Кэш выставлен везде. Частью выполнены советы Дениса по оптимизации. Поставлен бот-оптимайзер и компонеты: Page Cash и JRE Cash. вроде друг другу не мешают. Хотя, может, это неправильно и нужно ограничиться лишь одним компонентом кэширования? Подскажите.

смущает вот такой запрос:
12
SELECT id, name, section
 FROM jos_categories
 WHERE ( section=38 OR section=37 OR section=36 OR section=35 OR section=34 OR section=33 OR section=32 OR section=31 OR section=30 OR section=29 OR section=28 OR section=27 OR section=26 OR section=25 OR section=24 OR section=23 OR section=22 OR section=21 OR section=20 OR section=19 OR section=18 OR section=17 OR section=16 OR section=15 OR section=14 OR section=13 OR section=12 OR section=11 OR section=10 OR section=9 OR section=8 OR section=7 OR section=6 OR section=5 OR section=4 OR section=3 OR section=2 OR section=1 )
 ORDER BY ordering

Fill хм, столько раз OR в условии, от какого модуля запрос такой?

Сорри. Поторопился. Не туда посмотрел. Этот запрос в админке при открытии материала в редакторе. При загрузке главной выдает 357 запросов. При загрузке кэшированного материала - остается 30 запросов. Я в ауте...

При повторной загрузке главной страницы остаются 16 запросов. Есть ли способ при первичной загрузке снизить количество запросов. или это достигается сокращением модулей на главной? 357 запросов это, по-моему, слишком. Если не трудно, взгляните: http://www.beeznez.com

большую часть запросов может давать календарик

При первичной загрузке материала - 283 запроса. При этом чаще всего повторяется этот: 34
SELECT ms.id AS sid, ms.type AS stype, mc.id AS cid, mc.type AS ctype, i.id as sectionid, i.id As catid, ms.published AS spub, mc.published AS cpub
 FROM jos_content AS i
 LEFT JOIN jos_sections AS s ON i.sectionid = s.id
 LEFT JOIN jos_menu AS ms ON ms.componentid = s.id
 LEFT JOIN jos_categories AS c ON i.catid = c.id
 LEFT JOIN jos_menu AS mc ON mc.componentid = c.id
 WHERE ( ms.type IN ( 'content_section', 'content_blog_section' ) OR mc.type IN ( 'content_blog_category', 'content_category' ) )
 AND i.id = 7469
 ORDER BY ms.type DESC, mc.type DESC, ms.id, mc.id
То есть попробовать вырубить календарь?

Отключил календарик. Осталось 355 запросов. Реально исчезли 2 запроса. При открытии кэшированного материала теперь вместо 30 - 28 запросов.

Отключил все модули последних новостей (30). Осталось 95 запросов при первичной загрузке. Некэшированный материал - 150 запросов, кэшированный - 16. Чувствую, если отключу все модули случайных новостей (31) запросы и вовосе исчезнут. Но мне необходимо, что новости в разделах выходили в случайном порядке, да и последние новости в разделах нужны. Неужели нельзя оптимизировать запросы к БД без радикального сокращения модулей на главной?

Нельзя сократить...

У меня такая же фигня была. Было более 300 запросов, сократил всё что мог, и сейчас всё равно без кеша 106 queries 0.838171, а с кешем 73 queries 0.429294

Конечно нет предела оптимизации.
Всегда можно объединить кучу запросов типа "ORDER BY RAND() LIMIT 0, 1" (обычно генерируется модулями случайных новостей, картинок или еще чего-нибудь) в один с "LIMIT 0, NNN".
Можно убрать кучу запросов для определения itemid, если он известен заранее, или использовать один и тот же для всех новостей в модуле, и т.д.

Вот только NORDmen прав — для этого нужно руками поработать (а еще головой, в которой есть знание MySQL и PHP).

Конечно нет предела оптимизации.
Всегда можно объединить кучу запросов типа "ORDER BY RAND() LIMIT 0, 1" (обычно генерируется модулями случайных новостей, картинок или еще чего-нибудь) в один с "LIMIT 0, NNN".
Можно убрать кучу запросов для определения itemid, если он известен заранее, или использовать один и тот же для всех новостей в модуле, и т.д.

Вот только NORDmen прав — для этого нужно руками поработать (а еще головой, в которой есть знание MySQL и PHP).

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

Кстати по поводу Itemid не могли бы поподробнее объяснить?

Присоединяюсь к вопросу Fill - думаю моих знаний хватит

А еще можно кэшировать запросы в БД

Совет № 5 от Physicistа. Только хотелось бы уточнить, где находится файл my.cnf

Уважаемый boston, если я правиьно понял, то стандартный кэш в joomla и так кэширует базу данных. Или я путаю.

Уважаемый boston, если я правиьно понял, то стандартный кэш в joomla и так кэширует базу данных. Или я путаю.

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

Кто нибудь расскажет про ID? Буду оптимизировать модули свои, так как я уже определился с ними.

bzzik, ну вот приведу пример: допустим у тебя на главной весить модуль mod_poll. в нем выполняется запрос по поиску пункта меню на компонент com_poll. Допустим ты не создавал такой пункт меню, следовательно тебе и запрос этот не к чему. Или же создал и знаешь его Itemid тогда можно прописать его значение в mod_poll, опять же избавившись от запроса.

И что, почти в каждом модуле выполняется такой поиск? А зафигамс такой поиск нужен? Какое его предназначение?

нет не в каждом. я просто привел пример. возможно с mod_poll и не совсем удачно так как для него целесообразно включать кеширование. В данном примере нужен затем, что бы определить itemid пункта меню на компонент com_poll, ведь при нажатии на кпоку Голосовать или Итоги попадаешь как раз на com_poll

Понятно... Попробую разобратся

Еще рекомендую попробовать Мамбот кеширования страниц сайта System-Cache (для Joomla!1.0).

SQL-запрос:

ALTER TABLE `jos_messages` CHANGE `user_id_from` `user_id_from` SMALLINT( 5 ) UNSIGNED NOT NULL AUTO_INCREMENT

Ответ MySQL: Документация
#1075 - Incorrect table definition; there can be only one auto column and it must be defined as a key

слушайте а вот это еще туда вносить не надо?
Запрет индексации лишнего url в файле robots.txt: Disallow: /component/option,com_frontpage/

только вместе с itemid'ом

благодарю за полезную информацию.

0. И самое главное - отказаться от Apache
1. В сторону APC плюваются. http://www.joomlaperformance.com/articles/performance/why_apc_sucks_and_should_be_pulled_from_pecl_53_14.html
2. В разделе Tools есть утилита для тестирования производительности сайта на joomla.

Ну, плюсы и минусы есть у всех.

1. Нет поддержки FastCGI.
Не знаю, у кого как, но в 99% случаев php запускается как модуль Apache, возможно поэтому разработка APC ориентирована именно на это.

2. Нет поддержки командной строки.
А вам она очень нужна?

3. Не поддерживает PHP5.3 и 6.0.
Последние версии вроде бы работают на 5.3 (по-крайней мере, работы в этом направлении ведутся), а в версии 6.0 APC хотят включить в состав ядра. Тут источник проблемы в том, что в версии PHP5.3.0 насколько я знаю изменилось API для расширений, причем так, что кэшировать код стало вообще невозможным. Как дело обстоит сейчас я не знаю. Вроде бы разработчики xcache предложили патч для php, вроде бы его должны были включить в последующие версии php, но как с этим обстоит дело в настоящий момент — я не знаю.

4. Поддержка позднего связывания.
Я на это особого внимания не обращал. Но если бы это было действительно так, как описано, то APC вообще не сказывался на работе Joomla!1.5, где практически все файлы подключаются динамически. Однако тесты показывают значительное увеличение быстродействия при наличии APC.

А если говорить не о кэшировании опкода, а о предоставляемом API для кэширования, то самым быстрым окажется eAccelerator. Так что тут трудно найти тот критерий, по которому сравнивать «кэшеры».