1 декабря 2010 в 14:37
Статистика по модулю Devel:
Average memory per page: 24.8 MB
Average ms per page: 8,358.12
Путь # accesses Max Memory (MB) Avg Memory (MB) ms (Max) ms (Avg) Query ms (Max) Query ms (Avg) Query Count (Max) Query Count (Avg)
1 574 25.25 21.92 4,583.0 1,117.0 1,245.0 246.0 373 294
node 119 41.00 20.55 39,437.0 2,893.0 1,092.0 125.0 406 176
Размер главной страницы 24.9 KB (с дополнительными обращениями к серверу 284.2 KB)- время загрузки на сторону клиента 4.16s (с дополнительными обращениями к серверу 7.86s, onload: 6.65s), 31 запрос к серверу
Прошу гуру оптимизации прокомментировать эту статистику.
Еще хотелось бы узнать, что за мистическая страница 1? На сайте ее нет.
Комментарии
*Чорт. Забыл как зовут.* Юля или Аня, одно из двух.
И что ты, деточка, собралась оптимизировать?
80 модулей не количество, как правило, 2500 просмотров это не число.
Так что пни-ка лучше своего админа, пусть перестанет дуть пиго и поставит акселлетор, у тебя корпоративный сайт, насколько я помню, на своём серванте
Лично я так и сказала нашим "заказчикам" из соседнего отдела, что кроме установки eAcelerator ничего не могу им посоветовать. Вот только они на меня заявы пишут, типа сайт медленно работает несмотря на перенос на отдельный и более мощный сервер. При этом статистика загрузки страниц в среднем улучшилась в 3 раза.
П.с. Я Аня!
а почему его, а не APC или xcache?
Ну что скажу - я всегда знал что в Кубанистане фееричные бакланы обитают
Очень долго. А сколько из этого времени по статистике Devel выполняются запросы к БД?
Это как нужно настроить "отдельный более мощный сервер", чтобы генерация страницы занимала 4+ секунды...
У меня на хилом ноуте, при отладке, без кешера опкодов на больших проектах столько не набегает. 
Аня, придите к админам того сервера с молотком и примените его для выправления их рук.
255.08 главная, самый сложный вьювс пэйдж - 297.02
Я вообще с линухом общаюсь на уровне "подключиться по фтп - залить файлы, подключиться через путти перезапустить сервер". Поэтому eAcelerator - т.к. первое средство, которое попалось в статьях по оптимизации сервера под друпал.
У меня в отделе есть спец, который бы все настроил как надо, но т.к. другой отдел (заказчик) за это платить отказывается, и еще и все грехи на нас сваливает, мы им помогать из принципа отказываемся
посмотрите тут (в конце почитайте) - http://drupal.ru/node/52070 у меня была проблема с views (и не только у меня), м.б. это ваш случай!
А в идеали посмотреть бы например с devel, какие запросы тормозят, чтобы понимать, с чем имеете дело...
При таких соотношениях затрат времени на БД и РHP возможны три варианта:
1. Тормозящий код самописного модуля, блока или темы - нужно профилировать загрузку страницы
2. Не работающий eAcelerator - попробуйте отключить и сравните время генерации
3. Кривая конфигурация http-сервера - искать того кто ее проверит
2. Не работающий eAcelerator - попробуйте отключить и сравните время генерации
проще с помощью phpinfo() посмотреть, что там с eAcelerator, работает ли он или так, прохлождается...
ну и просто м.б. сервак хероватенький, то тут только свалить с него либо на другой, либо от хостера к чертям собачьим!
Похоже не только у меня трудности с чтением русского
ЗЫ: Автор, не обращай внимания, это мы о своем.
А по вашей теме RxB дал уже совет, без нормального ускорителя и добротной настройки сервера вряд-ли что-то получится оптимизировать по хорошему.
чувствуется качественный ответ от продвинутого хабровца с длинной
пипикармойСобственно, все что хотела - услышала (что нужен акселератор, а БД тут не причем). Спасибо
будем пока считать дискуссию закрытой. Но если акселератор не поможет - буду клянчить новых подсказок 
P.S. Стоит ли переводить таблицы БД Cache_form, watchdog, accesslog из MyISAM в InnoDB?
Cache_form
Данные 2,397.3 КБ
Индекс 9,216 Байт
Фрагментировано 1,847.7 КБ
Эффективность 558.6 КБ
Всего 2,406.3 КБ
watchdog
Данные 443.1 КБ
Индекс 24,576 Байт
Фрагментировано 187.7 КБ
Эффективность 279.4 КБ
Всего 467.1 КБ
accesslog
Данные 3,445.6 КБ
Индекс 954.0 КБ
Фрагментировано 129.7 КБ
Эффективность 4,269.9 КБ
Всего 4,399.6 КБ
2500 просмотров слишком мало чтобы об этом думать.
С твоими цифрами времени генерации самый большой профит получится после использования акселлератора
Я недавно выципил редкий глюк views, который появляется по ходу при использовании мультиязычности. сами девелоперы пока не могут определиться, где косяк, то ли в самом views, то ли в одном из модулей, пользующих его, но смысл в том, что в запрос вставляется совершенно ненужная связь и тогда всесто пары миллисикунд он выполняется минуты... причем зависит от самого запроса, объема данных и конфига базы, т.е. для одного случая такой же запрос пройдет за мс, а для другого будет длиться минуты...
так что все таки проверьте, что там с медленными запросами, лишним не будет.
Ну и акселератор само собой прикрутить стоит, если он еще не стоит...
У вас комплекс?
В том что запросы не влияют я уже убедилась. У меня максимальное количество запросов - в материале "Офис", и то они выполняются менее чем за 400мс. А вот время формирования страницы этого материала - ужас! О_О около минуты! Причем только на этом типе материала... Даже не знаю на что грешить. Яндекс-карта или самописный модуль (заменяет ссылки с таксономии на статьи по услугам)? Изначально с ними все летало. А потом добавилось несколько "не публичных" целочисленных полей CCK... Все равно не понимаю - проверка публичности основана на запросах, а они быстро отрабатывают. Есть мысли?
скорее всего кто то кого то ждет. Попробуйте поочередно отключить яндекс карты, а потом самописный модуль, так хотя бы определите, кто виноват, ну а дальше дебаггером смотреть, кто тормозит...
Виновник - самописный модуль... похоже надо основную часть его функционала переводить на модуль taxonomy_redirect
П.С. а он работает с Domain? или может просто есть модуль, который подружит taxonomy с доменами?
Так вроде есть одноимённый модуль. Посмотри блог юзера Scirr или Skirr не помню точно как его, он спрашивал как подружить форум с данным модулем и там ответ
Увы, тут проблема не закрепить сами термины за доменами, а в том, чтобы на странице /taxonomy/term/tid ссылки на материалы шли не на текущий домен, а на тот, за которым закреплен сам материал...
А вообще наш модуль заменял в материале ссылки на термины таксономии ссылками на описания соответствующих услуг (определяя при этом домен, за которым закреплена публикация).
что же там такого написали, что он стал так сильно нагружать машину? Вроде как модуль д.б. простеньким... Или вы описания тянете нодами, т.е. целиком?
FROM menu_links
LEFT OUTER JOIN node ON ((node.status=1) AND (node.type=\'page\') AND (CONCAT(\'node/\',node.nid)=menu_links.link_path))
LEFT OUTER JOIN url_alias ON menu_links.link_path=url_alias.src
WHERE
menu_links.link_path LIKE \'%%node/%%\'
AND menu_links.hidden=0
AND node.nid in (
SELECT term_node.nid
FROM term_node
WHERE tid=%d
)
AND menu_links.menu_name IN (\'menu-phiz\',\'menu-ur\')
ORDER BY menu_links.depth ASC', $v->tid);
Вот такой запрос применялся к каждому термину (а их в материале было до 25 штук..)
насколько я знаю, вот это не очень замечательная вещь, там вроде как MySQL не может использорвать ключи или что то в таком духе:
AND node.nid in (
SELECT term_node.nid
FROM term_node
WHERE tid=%d
)
но тогда мы опять упираемся в базу, а вы вроду как утверждали, что с ней все ок. как долго выполняется такой запрос?
Запрос писался полгода назад, под крики "быстрее!!! Мы хотим всё и ужЕ вчера!" от заказчика
Это я сегодня переписала запрос через db_query. Devel показал в среднем 15 секунд на такой запрос...
Логика подсказывает, что выборку изначально надо строить от таблицы node.
Оговорюсь сразу, что я не спец по оптимизации сложных SQL запросов. но в данном случая я бы ушел от опператора IN и просто попытался бы присоединить таблицу term_node к базовому запросу и дальше фильтронул бы по критерию where, как то как:
SELECT DISTINCT menu_links.link_path, menu_links.menu_name, url_alias.dst
FROM menu_links
LEFT OUTER JOIN node ON ((node.status=1) AND (node.type='page') AND (CONCAT('node',node.nid)=menu_links.link_path))
LEFT OUTER JOIN url_alias ON menu_links.link_path=url_alias.src
JOIN term_node ON node.nid = term_node.nid
WHERE
menu_links.link_path LIKE '%node%'
AND menu_links.hidden=0
AND term_node.tid=%d
AND menu_links.menu_name IN ('menu-phiz','menu-ur')
ORDER BY menu_links.depth ASC
hint - используйте внешние двойные кавычки, тогда не надо будет париться с hash символами.
используйте еще такую штуку как EXPLAIN, чтобы понять, как ищет mySQL и что какие ключи он использует.
ну и таблички было бы неплохо в фигурные скобочки вставлять - {node}, а то как то не по drupal'ки получается!