2 мая 2011 в 13:36
Хотелось бы увидеть информацию по каждому модулю, а в частности процессорное время (ну, или просто время выполнения ) и использование памяти, а не только нагрузка на базу данных.
Комментарии
процессорное время чего?
время выполнения чего?
использование памяти на что?
намекаю - нет и не может быть
Каждого модуля, который участвует в процессе загрузки конкретной страницы.
Ну получите вы сферические данные, а толку?
Я даже не представляю что вам это даст типа
CCK - 100 процессорных секунд
Views - 80 процессорных секунд
...
Будете CCK отключать? К оптимизации подходят с других краёв, как правило
Есть модули которые "много весят" и используются не полностю. Их функционал часто можна замиенить более легкими самописными аналогами.
модуль это набор функций, как можно измерить что-то (кроме занимаемой памяти) у набора функций?
Тогда читайте комменты Андеда
Vanyasmart, поставьте xdebug включите в нем профилирование, думаю, это то что вам нужно.
Поставить профайлер
Имея информацию о том, сколько времени выполняется та или иная функция, принимающая участие в процессе генерации страницы, можно понять какая из функций работает медленнее других и попробовать ее оптимизировать.
Почему сферические? Вполне себе конкретные метрики можно получить, на основе которых можно определить во что упирается скрипт: в кривые настройки сервера, в частовыполняемые функции, результат работы которых можно/нельзя закешировать или в недостаток мощности железа.
Почему бы и нет? Уж без Views точно легко обойтись можно. Или если не выключать, то поиграться с кешированием.
в закладки
Роман, раз уж ты пришёл, тогда давай общаться цивилизованно.
Потребление ресурсов модулями это как минимум три величины:
-Процессорное время
-Рама
-Мускуль
И это всё зависит от десятков параметров и вводных.
Тот же CCK жрёт по разному в момент сохранения ноды если у тебя одно значение поля и 40 значений.
Далее, если человек задаёт такие вопросы, то профайлер ему точно ничем не поможет, так как оптимизация это нечто более чем посмотреть на цифирки, отключить модули.
Так же, в 99% всех оптимизаций за которыми ко мне обращались, речь велась о сайте на виртуальном хостинге за 50р и сайтом с 2000 хитами в сутки, такие проблемы прекрасно решаются сменой хостинга на более дорогой.
Пока что я думаю тут попахивает Premature oprimization
генерация страниц это малая малая часть того, чем занимаются модули
Так ведь я и не спорю. И все эти ресурсы: процессорное время (ну точнее физическое количество процессоров/ядер) и раму можно при желании нарастить, но есть ситуации (да что уж там, таких случаев процентов 90), когда достаточно оптимизировать код или настройки Друпала, для того чтобы снизить нагрузку с сервера (речь не о сохранении контента, а о его отдаче посетителям). И здесь важно не вслепую тыкаться и менять какие попало настройки или отключать модули, а знать, что именно работает медленно.
Профайлер поможет найти тонкие места в скрипте и понять, что нужно оптимизировать. Разумеется, если его использовать только чтобы "посмотреть на цифирки", то толку от этого будет 0.
Согласен, что если стоит выбор между часами анализа логов и оптимизации скриптов и сменой хостинга с пятидесятирублевого на сторублевый, то второй вариант проще. Но если речь, например, о смене VPS за 100 баксов в месяц на вдвое более дорогой тариф, то можно призадуматься о профилировании.
при переходе с самописных систем, где борьба была за каждый запрос и каждая страница оптимизировалась, был просто в шоке от количества запросов который генерят ЦМС. Но это естественная расплата за базовый функционал и возможность создать что то унифицировано через веб.
а вообще надо смотреть в целом на ресурсоёмкость и дальше разделять и маштабировать.
- обработка запроса
- база
- обработка инфы
- шаблонизатор
- print out