Форум русской поддержки Joomla!® CMS
21.01.2017, 17:15:28 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
   
   Начало   Поиск Joomla 3.0 FAQ Joomla 2.5 FAQ Joomla 1.5 FAQ Правила форума Новости Joomla Реклама Войти Регистрация Помощь  
Страниц: 1 [2] 3 4   Вниз
  Добавить закладку  |  Печать  
Автор

Оптимизация Joomla (черновик)

 (Прочитано 117912 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Physicist
Support Team
*****

Репутация: +185/-0
Offline Offline

Пол: Мужской
Сообщений: 962


Рябов Денис


« : 24.01.2008, 20:20:00 »

Я решил написать статью по оптимизации Joomla для моего блога joomup.com/blog. А пока статья находится в процессе написания, выкладываю на всеобщее обозрение ее «черновик» (даже скорее «краткое содержание первой части»). Любые дополнения и критика приветствуются.


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

Хочу сразу предупредить, что повысить производительность Joomla на несколько порядков только за счет оптимизации вряд ли удастся. Поэтому задумайтесь, может быть имеет смысл сменить хостинг, перейти на виртуальный сервер, на выделенный сервер, проапгрейдить сервер, использовать несколько серверов (тут можно отметить pdf-руководство Joomla Cluster на forum.joomla.org), и т.д.

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

Сначала несколько советов, которые применимы к любой CMS, написанной на PHP:

1*. Используйте обновленное ПО. Например, PHP 5.2 работает почти в 2 раза быстрее, чем PHP 4.4.

2*. Используйте PHP-акселлераторы. Среди самых известных можно выделить Alternative PHP Cache (APC), eAccelerator, XCache, Zend Optimizer. По данным тестов joomla.org, самая быстрая работа Joomla обеспечивается с использованием APC и PHP 5.2.2 (см. выше про производительность PHP).

3.* Оптимизация Apache. Если вы используете сервер Apache, оптимизируйте его под свои нужды (на сайте www.crucialp.com описано, как провести оптимизацию под большой трафик).

4. Не обязательно использовать сервер Apache. Вместо него можно использовать более быстрый Lighttpd. Об использовании Joomla с Lighttpd написано на сайте ircmaxell.com: тут и тут.

5.* Оптимизация MySQL. По-умолчанию MySQL устанавливается с минимальными настройками. Попробуйте изменить эти настройки в соответствии с возможностями вашего сервера (советую прочитать статьи на joomlaperformance.com и profitpapers.com). Хорошим способом ускорить работу MySQL является настройка кэширования запросов. Текущее состояние параметров кэша можно увидеть, выполнив команду "SHOW STATUS LIKE 'qcache%';". Параметр query_cache_type должен иметь ненулевое значение, а в параметре query_cache_size должен быть указан размер кэша (именно это значение вам придется подобрать для обеспечения наилучшей производительности). Все эти параметры задаются в вашем файле my.cnf, например:
Код:
query_cache_type = 1
query_cache_size = 20M
query_cache_limit = 2M
Уделите внимание параметру max_connections. Увеличьте его значение, иначе вас очень быстро настигнет проблема "too many connections".

6. Подумайте о переносе картинок в наполненном графикой популярном посте на отдельный сервер или хостинг. Можно использовать мощности бесплатных сервисов (например flickr) и разместить изображения там. Точно также можно перенести и многие другие файлы.

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

8. Не забудьте включить gzip-сжатие, если хотите уменьшить трафик (правда, это слегка увеличит нагрузку на процессор).  Кстати, это можно сделать не только для html-страниц, генерируемых Joomla, но и для всех css и js файлов. Если на вашем сервере установлен Apache 2, то просто добавьте следующие директивы в ваш файл .htaccess:
Код:
<FilesMatch "\.(js|css)$">
SetOutputFilter DEFLATE
</FilesMatch>

9. Совершенно не к чему каждый раз загружать одни и те же css/js файлы и графику. Как правильно поместить их в кэш браузера, описано на apachedev.ru, а для знающих английский рекомендую статью на askapache.com.

10. Оптимизируйте графику в шаблоне. Некоторые сайты славятся тем, что загружают несколько сотен килобайт картинок. Вообще, проверяйте объем загружаемой информации и время загрузки на сайте http://www.websiteoptimization.com/services/analyze/index.html.

11. Старайтесь уменьшить количество запросов к серверу. Постарайтесь объединить имеющиеся css-файлы в один. То же самое относится и к js-скриптам. Да и сами файлы очистить от лишнего мусора.

12. Для более быстрого отображения страницы в браузере желательно, чтобы на странице не было ошибок. Вы можете проверить свой сайт, например, на validator.w3.org.

13?. Добавьте favicon.ico и favicon.gif в корень сайта, т.к. некоторые браузеры сначала запрашивают их, а не те, которые указаны в коде страницы (их не так много, но в логах сервера эти запросы появляются с завидной регулярностью).

Теперь перейдем к советам, относящимся к собственно Joomla.

14*. Включите кэширование для всех модулей, для которых это возможно. Время жизни кэша определите из условия: сколько времени вы готовы ждать, пока добавленная новость появится в модуле последних новостей? Для одних сайтов это будет 10 минут, для других – час, для третьих – сутки. (Если хотите, вот числа: в «свежеустановленной» Joomla при посещении главной страницы генерируется 36 запросов, а с включенным кэшированием модулей — всего 13 запросов).

15*. Добавьте индексы для таблиц в БД. Тут есть несколько альтернативных предложений по оптимизации: ircmaxell.com и forum.joomla.org (перевод на русский — joomlaportal.ru). Я бы рекомендовал те, что описаны на forum.joomla.org, т.к. на ircmaxell.com уж очень большие индексы создаются.

16*. Не забывайте, что при частом изменении таблиц БД они сильно возрастают в размере, поэтому время поиска по БД тоже возрастает. Поэтому БД нужно регулярно оптимизировать (по сути — сжимать). Установите мамбот OptimizeTables (от smart'а) или выполняйте оптимизацию таблиц вручную (выделите все таблицы через phpMyAdmin, и выполните команды repair и optimize).

17*. Можно сменить тип таблицы jos_session на memory:
Код:
alter table jos_session type=memory;
(если ваша версия Joomla использует другой префикс таблиц, то не забудьте заменить «jos» на него).

18*. Отключите встроенную статистику. В большинстве случаев статистика, предоставляемая хостер;ом, дает намного больше информации о посетителях. Но можно оставить статистику поисковых запросов.

19. Удалите лишние (неиспользуемые) расширения (компоненты, модули, мамботы).

20. Много запросов образуется при формировании списки новостей в различных модулях (из-за получения Itemid для каждой новости). Это можно ускорить, используя постоянный Itemid, появившийся в 1.0.12.

21. Много запросов зачастую генерируют сторонние SEF-компоненты. При большой нагрузке лучше использовать встроенный SEF, или не использовать SEF вовсе (кстати, встроенный SEF практически не требователен к ресурсам; более того, по данным теста joomla.org  Joomla!1.5 с включенным SEF работает быстрее, чем с отключенным).

22. Старайтесь не использовать в настройках пунктов меню «Category Name Linkable» («Названия категорий в виде ссылок»).

23. Для полей id в таблицах БД можно вместо типа int(11) указать smallint unsigned, что приводит к небольшому уменьшению объема памяти, требуемого для хранения БД.

24. Закройте через robots.txt от индексации поисковыми ботами компонент com_search и файл index2.php. Также можно закрыть com_wraper и com_newsfeed (ленты новостей), т.к. поисковики могут посчитать это дублированным контентом. Ниже приведен набор правил для встроенного SEF:
Код:
User-agent: *
Disallow: /index2.php?
Disallow: /component/option,com_search/
Disallow: /component/option,com_newsfeeds/
Disallow: /component/option,com_wrapper/
Кстати, в robots.txt можно также ограничить (на всякий случай) доступ поисковиков к файлам Joomla:
Код:
Disallow: /administrator/
Disallow: /cache/
Disallow: /components/
Disallow: /editor/
Disallow: /help/
Disallow: /includes/
Disallow: /language/
Disallow: /mambots/
Disallow: /media/
Disallow: /modules/

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

26. Оптимизируйте используемый шаблон (например, удалите лишние пробелы и переводы строк).
« Последнее редактирование: 13.06.2008, 19:22:01 от Physicist » Записан
 
b2z
Support Team
*****

Репутация: +717/-0
Offline Offline

Пол: Мужской
Сообщений: 7592


Разраблю понемногу


« Ответ #31 : 04.04.2008, 11:39:22 »

Fill - заходишь в админку - в конфигурации  врубаешь режим отладки Wink
Записан
Fill
Осваиваюсь на форуме
***

Репутация: +0/-0
Offline Offline

Пол: Мужской
Сообщений: 39



« Ответ #32 : 04.04.2008, 13:53:52 »

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

Репутация: +0/-0
Offline Offline

Пол: Мужской
Сообщений: 39



« Ответ #33 : 04.04.2008, 14:03:37 »

смущает вот такой запрос:
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
Записан
beliyadm
Профи
********

Репутация: +1583/-61
Offline Offline

Пол: Мужской
Сообщений: 8293


Севастополь == Россия


« Ответ #34 : 04.04.2008, 14:08:36 »

Fill хм, столько раз OR в условии, от какого модуля запрос такой?
Записан
Fill
Осваиваюсь на форуме
***

Репутация: +0/-0
Offline Offline

Пол: Мужской
Сообщений: 39



« Ответ #35 : 04.04.2008, 14:14:25 »

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

Репутация: +0/-0
Offline Offline

Пол: Мужской
Сообщений: 39



« Ответ #36 : 04.04.2008, 14:19:42 »

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

Репутация: +1583/-61
Offline Offline

Пол: Мужской
Сообщений: 8293


Севастополь == Россия


« Ответ #37 : 04.04.2008, 14:25:25 »

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

Репутация: +0/-0
Offline Offline

Пол: Мужской
Сообщений: 39



« Ответ #38 : 04.04.2008, 14:32:11 »

При первичной загрузке материала - 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
То есть попробовать вырубить календарь?
Записан
Fill
Осваиваюсь на форуме
***

Репутация: +0/-0
Offline Offline

Пол: Мужской
Сообщений: 39



« Ответ #39 : 04.04.2008, 14:38:29 »

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

Репутация: +0/-0
Offline Offline

Пол: Мужской
Сообщений: 39



« Ответ #40 : 04.04.2008, 15:06:12 »

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

Репутация: +717/-0
Offline Offline

Пол: Мужской
Сообщений: 7592


Разраблю понемногу


« Ответ #41 : 04.04.2008, 16:17:04 »

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

У меня такая же фигня была. Было более 300 запросов, сократил всё что мог, и сейчас всё равно без кеша 106 queries 0.838171, а с кешем 73 queries 0.429294
« Последнее редактирование: 04.04.2008, 16:20:54 от bzzik » Записан
Physicist
Support Team
*****

Репутация: +185/-0
Offline Offline

Пол: Мужской
Сообщений: 962


Рябов Денис


« Ответ #42 : 04.04.2008, 16:45:38 »

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

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

Репутация: +0/-0
Offline Offline

Пол: Мужской
Сообщений: 39



« Ответ #43 : 04.04.2008, 17:05:48 »

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

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

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

Репутация: +717/-0
Offline Offline

Пол: Мужской
Сообщений: 7592


Разраблю понемногу


« Ответ #44 : 04.04.2008, 17:09:35 »

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

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

Репутация: +222/-3
Offline Offline

Пол: Мужской
Сообщений: 499



« Ответ #45 : 04.04.2008, 17:18:27 »

А еще можно кэшировать запросы в БД Azn
Записан
Fill
Осваиваюсь на форуме
***

Репутация: +0/-0
Offline Offline

Пол: Мужской
Сообщений: 39



« Ответ #46 : 04.04.2008, 17:39:03 »

Совет № 5 от Physicistа. Только хотелось бы уточнить, где находится файл my.cnf
Записан
Fill
Осваиваюсь на форуме
***

Репутация: +0/-0
Offline Offline

Пол: Мужской
Сообщений: 39



« Ответ #47 : 04.04.2008, 17:42:10 »

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

Репутация: +185/-0
Offline Offline

Пол: Мужской
Сообщений: 962


Рябов Денис


« Ответ #48 : 04.04.2008, 17:56:49 »

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

Репутация: +717/-0
Offline Offline

Пол: Мужской
Сообщений: 7592


Разраблю понемногу


« Ответ #49 : 16.04.2008, 12:38:46 »

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

Репутация: +113/-7
Offline Offline

Пол: Мужской
Сообщений: 368



« Ответ #50 : 16.04.2008, 18:20:49 »

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

Репутация: +717/-0
Offline Offline

Пол: Мужской
Сообщений: 7592


Разраблю понемногу


« Ответ #51 : 16.04.2008, 22:23:07 »

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

Репутация: +113/-7
Offline Offline

Пол: Мужской
Сообщений: 368



« Ответ #52 : 16.04.2008, 23:49:05 »

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

Репутация: +717/-0
Offline Offline

Пол: Мужской
Сообщений: 7592


Разраблю понемногу


« Ответ #53 : 16.04.2008, 23:56:03 »

Понятно... Попробую разобратся Azn
Записан
Physicist
Support Team
*****

Репутация: +185/-0
Offline Offline

Пол: Мужской
Сообщений: 962


Рябов Денис


« Ответ #54 : 05.06.2008, 14:47:01 »

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

Репутация: +4/-1
Offline Offline

Пол: Мужской
Сообщений: 57


Всегда в тени...


« Ответ #55 : 19.06.2008, 14:51:57 »

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
Записан
newleax
Давно я тут
****

Репутация: +23/-0
Offline Offline

Пол: Женский
Сообщений: 234



« Ответ #56 : 05.08.2008, 19:56:05 »

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

Репутация: +113/-7
Offline Offline

Пол: Мужской
Сообщений: 368



« Ответ #57 : 07.08.2008, 19:08:36 »

только вместе с itemid'ом
Записан
Komsa
Захожу иногда
**

Репутация: +0/-0
Offline Offline

Сообщений: 14


« Ответ #58 : 03.11.2008, 01:14:49 »

благодарю за полезную информацию.
Записан
vadim s. sabinich
Осваиваюсь на форуме
***

Репутация: +11/-0
Offline Offline

Пол: Мужской
Сообщений: 141


переводчик-любитель


« Ответ #59 : 13.01.2009, 16:40:42 »

0. И самое главное - отказаться от Apache Wink
1. В сторону APC плюваются. http://www.joomlaperformance.com/articles/performance/why_apc_sucks_and_should_be_pulled_from_pecl_53_14.html
2. В разделе Tools есть утилита для тестирования производительности сайта на joomla.
« Последнее редактирование: 13.01.2009, 17:39:04 от vadim s. sabinich » Записан
Physicist
Support Team
*****

Репутация: +185/-0
Offline Offline

Пол: Мужской
Сообщений: 962


Рябов Денис


« Ответ #60 : 13.01.2009, 17:38:55 »

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

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. Так что тут трудно найти тот критерий, по которому сравнивать «кэшеры».
Записан
Страниц: 1 [2] 3 4   Вверх
  Добавить закладку  |  Печать  
 
Перейти в:  

Powered by SMF 1.1.21 | SMF © 2006, Simple Machines

Joomlaforum.ru is not affiliated with or endorsed by the Joomla! Project or Open Source Matters.
The Joomla! name and logo is used under a limited license granted by Open Source Matters
the trademark holder in the United States and other countries.

LiveInternet