18 февраля 2009 в 22:35
В связи с последними событиями (http://drupal.ru/node/23843) я сейчас занят оптимизацией Друпала.
Хочу поделиться результатами исследования процесса загрузки Друпала.
Кратко параметры сайта: нод - 4500, комментариев - 11300, файлов - 4700, пользователей - 5900.
Но пока это имеет не очень большое значение. Я, пока, разбираюсь с загрузкой.
У Друпала есть основные 4 стадии выполнения.
1. Загрузка
2. Обработка пункта меню
3. Темизация
4. Exit
На моем локальном хосте эти операции соответственно занимают (для страницы с нодой):
загрузка - 1.2 сек
меню - 0.5 сек
темизация - 0.9 сек
exit - 0.001 сек
Итак, начнем по порядку.
В основном загрузка проходит гладко, пока не доходит до загрузки включенных модулей.
Итак, возьмем конкретный пример.
Полная загрузка: 1.202 сек
Из них:
последняя стадия загруки: 1098.351 мс
в которую включено:
Инклюд главных файлов из папки includes: 43.788 мс
Инклюд включенный модулей: 600.634 мс
Выполнение хука hook_init(): 441.953
Здесь нужно отдать должное. Модуль Devel может очень сильно напрягать hook_init()
Рейтинг модулей
Далее приведу список модулей, которые инклюдятся за 600.634 мс с временем их включения:
[profile] => 59.5209598541 [system] => 49.5181083679 [node] => 35.3019237518 [user] => 26.6139507294 [fckeditor] => 25.1798629761 [tinymce] => 25.0089168549 [fivestar] => 19.9010372162 [comment] => 17.0340538025 [date] => 15.820980072 [devel] => 15.124797821 [upload] => 15.0430202484 [forum] => 14.2340660095 [views_ui] => 13.8468742371 [imagecache] => 11.1229419708 [views] => 10.3900432587 [taxonomy] => 9.67383384705 [poll] => 8.05115699768 [excerpt] => 7.77792930603 [filter] => 7.77506828308 [fieldgroup] => 7.3721408844 [imce] => 6.35194778442 [pollfield] => 6.2780380249 [locale] => 6.2518119812 [content] => 6.06083869934 [privatemsg] => 6.0122013092 [tracker] => 5.88393211365 [node_images] => 5.37991523743 [journal] => 5.35011291504 [optionwidgets] => 5.28287887573 [acl] => 5.11002540588 [text_captcha] => 5.08308410645 [auto_nodetitle] => 5.06806373596 [path_redirect] => 4.8520565033 [nodewords] => 4.75382804871 [bueditor] => 4.61387634277 [menu] => 4.47511672974 [pathauto] => 4.4538974762 [block] => 4.39310073853 [os] => 4.34899330139 [htmLawed] => 4.22716140747 [imagefield] => 4.1720867157 [captcha] => 4.06193733215 [nodereference] => 3.65304946899 [watchdog] => 3.63707542419 [statistics] => 3.50213050842 [contact] => 3.37910652161 [votingapi] => 3.29494476318 [link] => 3.09586524963 [video_filter] => 3.04198265076 [userreference] => 2.89297103882 [comment_upload] => 2.78210639954 [text] => 2.74610519409 [blockcache] => 2.59685516357 [number] => 2.49004364014 [forum_access] => 2.41208076477 [htmlbox] => 2.30193138123 [path] => 2.2349357605 [default_filter] => 2.13289260864 [token] => 2.11596488953 [custom_breadcrumbs] => 2.02798843384 [upload_preview] => 1.95002555847 [custom_blocks] => 1.94501876831 [views_rss] => 1.67107582092 [cooliris] => 1.63984298706 [page_title] => 1.5721321106 [db_maintenance] => 1.45220756531 [bbcode] => 1.40190124512 [globalredirect] => 1.33109092712 [url_alias_cache] => 1.23906135559 [globalredirect_admin] => 1.21808052063 [transliteration] => 1.12009048462 [node_import] => 0.94199180603 [date_api] => 0.888824462891 [jquery_update] => 0.821828842163 [ping] => 0.797986984253
Выводы
Отработка скриптов Друпала делится на две части, которые делят между собой время 50 на 50.
Первая - это подключение файлов php с кодом модулей. Вторая - это выполнение sql запросов и генерация страницы.
Если Вы хотите избежать тормозов, то либо включите APC или eАкселератор, либо не стоит злоупотреблять модулями.
Их должно быть не очень много.
Полный отказ от загрузки файлов модулей даст прирост производительности в двое.
Если есть возможность реализовать функционал без модуля, то это стоит сделать без модуля.
Ну и смотрите мою табличку, от каких модулей стоит отказаться в первую очередь.
Комментарии
из таблички видно что визвиги зло
сделайте тест для начала блок заданный в модуле и php код в блоке
ЗЫ можно скриптик которым мерили
Да нет никакого скрипта.
Тупо правил функцию module_load_all() в module.inc
<?php
foreach (module_list(TRUE, FALSE) as $module) {
list($usec, $sec) = explode(' ', microtime());
$start = (float)$usec + (float)$sec;
drupal_load('module', $module);
list($usec, $sec) = explode(' ', microtime());
$end = (float)$usec + (float)$sec;
$GLOBALS['debug']['timer'][$module] = ($end - $start) * 1000;
}
?>
потом делал print_r() в index.php
Это уже следующая задача. Это не входит в загрузку.
Здесь скорее будет рулить оптимизация SQL запросов.
Не так страшен Views как его малюют
50 модулей-это много?
Хех.. Не так страшен Views как его малютки
Возникает много лишних SQL запросов. В этом его единственный минус.
Следует отдать должное шестому друпалу.
Там можно разбивать логику модуля на несколько разных файлов и подключать их в зависимости от потребностей.
Однако, реализовывать это нужно с умом.
Допустим, зачем подключать модуль captcha для авторизированных пользователей, или зачем подключать модули визивига для страниц, на которых он не используется, или path_auto если мы просто смотрим материал, а не создаем новые алиасы.
В общем таких примеров море.
Мне вот интересно, каким-таким методом можно опрежделить страницы для которых модуль не используется? Включение-выключение, например блока с формой для которой нужен визивиг никто и никогда не отловит... то же самое с отальными модулями.
> Если Вы хотите избежать тормозов, то либо включите APC или eАкселератор
, либо не стоит злоупотреблять модулями.> Их должно быть не очень много.
Соглашусь, но понятие "очень много" является растяжимым.
> Полный отказ от загрузки файлов модулей даст прирост производительности в двое.
И обеспечит полный отказ от функциональности.
> Если есть возможность реализовать функционал без модуля, то это стоит сделать без модуля.
Не согласен в корне. Я бы сказал, что стоит отказаться от крупных, широкофункциональных модулей (например CCK, Views), в пользу маленьких, которые реализуют непосредственно ваши задачи.