27 ноября 2009 в 14:45
Приветствую!
Делаю сайт на Drupal 6, активно использую CCK, Views. Ещё не вся функциональность реализована, но количество запросов иногда переваливает за 1000, время генерации страниц доходит до 15 секунд.
С такими цифрами нереально запускать сайт для людей! Как можно оптимизировать работу Друпала, что подковырять, где покодить?
Комментарии
Количество запросов и время генерации коррелируются не сильно. Для кучи модулей вполне может быть и больше > 1000 мелких запросов, т.к. по дефолту друпал хранит всё кроме файловых аттачей в БД - контент, кеши, локализацию, статусные переменные, данные сессий. Но на соответствующим образом настроенной СУБД это некритично. Вот 15 секунд означает, что что-то настроено не правильно или каки-то модули имеют некорректный код - в контриб-модулях это нередко бывает. Надо поставить модуль devel, включить в нём статистику и смотреть какие запросы или генерация кода в php занимают сколько времени.
а чем замерялось время генерации?
axel
А каким образом должна быть настроена БД для друпала и каково приемлемое время выполнения запроса к БД?
Модуль Devel уже стоит, как раз через него и смотрю статистику.
Да вы где смотрите? На локалхосте? У меня локально бывало комп вообще вис ВЕСЬ
На Unix-ах нет никаких 15 секунд
Пост axel-я выше,читаем между строк:
Друпал очень прожорливая хрюшка-лечится хорошим железом
То что хрюшка прожорливая это точно! Смотрю на локалхосте, и комп вроде не слабый. Попробую протестировать на сервере хостера.
в том же модуле девел есть и время выполнения запросов. И имя модулей.
Посмотрите там
Не нашли. Поставьте что нибудь вроде x debug и включите профилирование. Получите подробный отчет где и как долго выполнялся какой код.
Ради бога,не примите как наезд,но это вроде "бла-бла-бла".Друпал ЖРЁТ и жрёт много.Помоему это очевидно.Хорошее железо и без гвоздей
ну давайте по дискутируем.
что значит много? с чем сравнивать в каких случаях и так далее.
Давайте оттолкнемся от того что перед нами типичное друпал ядро, где установлены модули написанные вменяемыми программистами.
Я придерживаюсь того мнения что, например задачи кеширования нужно решать правильно конфигурацией серверной стороны.
Вы будете спорить с тем что верной конфигурацией платформы я снижу нагрузку как на ЦП так и на БД? Да не просто снижу, а в десятки раз.
А если это возможно, то разговор о прожорливости друпала мягко говоря яйца выеденного не стоит.
Впрочем, я готов согласиться с тем что на колокешинах, где у администратора крайне ограниченный ресурс по конфигурированию окружения, дурпал может быть не самым производительным решением.
Ну в дясятки раз.Ээээ...не верю
И к тому же:
Ну в подавляющем большинстве люди берут модули с орга.Я верю,что там есть откровенно свинские штуки,но также верю и в коллективные разум.Если модули юзают тыщи людей,они по определению не могут быть погаными.Не так ли?
Да мне сдаётся,не только кеширования - всего
даже не вникая в подробности работы конкретного проекта,
простым включением кеша зпрососов + кеш пхпного апкодов + mod_expire на всю статику + фронтендом что нибудь легкой вроде lighthttp или nginx с кеширущим прокси = профит.
анонимусы вообще будут выгребать статику из кеша. без единого запроса к бд или к php
прочие, в большистве случаев будут работать с кешем бд и апкодным кешем.
нагрузка снижается в десятки раз.
Чаще всего да. Я вводную про программистов дал для того, чтобы упредить аргументы из разряда а если модуль делает такой запрос который сервер БД не может закешировать. И так далее.
не понял фразы. А чего еще?
Хостинг от gor + authcache модулей больше 40 запросов лучше не спрашивайте, среднее время загрузки для за логиного пользователя менее 0.3 сек
Ваши рассуждения о том, что Друпалу нужно хорошее железо, в данном случае неуместны, потому что 15 секунд - это нереально много. Впрочем, как и 1000 запросов
Самый простой метод "в лоб". Отключите все модули кроме Devel, затем включайте поочереди. Таким образом определите, что дает такие тормоза.
P.S. Друпал, конечно, прожорливый, но если постараться - оптимизировать реально.
1000 запросов влёгкую получается на странице модулей.Даже 3000 :)
Ну понятно что тормозит - вьюсы,сск,pathauto,то есть те модули,без которых друпал гавно на палочке
15 секунд это наверно просто на денвере.
Загрузил скрипты на хостинг (Linux) - время генерации страницы стало меньше секунды.
Какое время генерации считается приемлемым и не раздражающим пользователя?
Моментальное?
Момент - это тоже какое-то количество времени
Стремящееся к нулю, а нуль это бесконечно малая величина
да да спасибо.
заговариваться стал.
почему то считается комфортным не более секунды.
Говорят что якобы, у человека за это время не успевает появиться раздражение от неповоротливости интерфейса.
Мдя, понаписали. Истерики много, товарищ volocuga.
"Друпал тормозной..." Ну попробуйте Битрикс, думаете он быстрее? Хотя денег-то стоит ого-го.
С позиций здравого смысла - любая CMS - это тормоза, супротив узкоспециализированного самописного кода (ну понятно, если если его не криворукие дебилы писали). Так почему же >90% таки используют CMS? Потому что достоинства всё-таки перевешивают недостатки.
Поэтому дурацкую по моему мнению дискуссию о том, что тормозит вообще надо заканчивать, переходя от вообще к частному случаю. А далее как правильно писали - отладка вам в руки и вперёд с песней искать косяки. На мой скромный взгляд администратора хостинга, если при генерации обычной страницы делается 1000 запросов к MySQL, а время генерации страницы 15 секунд, то программиста надо вешать к потолку за левую ногу и держать в подвешенном состоянии до тех пор пока вся дурь из головы не вытечет! Тогда возможно появится посветление в уму, он научится правильно использовать и настраивать кэш, не заниматься сериализацией и десериализацией массов данных длиной от 100кбайт при генерации каждой страницы и т.д.
Гы-гы - прав как никогда! Только не "..потолку за левую ногу ..", а сразу за яйца, чего там мелочиться...
Более того - за 10 минут более 6-10 тысяч селектов и блокировать наХ!
А на счет въюсов - добавлю от себя - фигня редкая - использую при крайней нужде и страшном обломе "пальцами по клаве стучать"
На счет "золотого стандарта" - не более 20-30 запросов на страницу! Но друпал такого не позволяет - если грамотно все расписать - выходит от 30-32 до 50 запросов (имею в виду выборки на страницу, а не одна голая статья та всю страницу). И с этими показателями можно нормально жить!
Но поколение подрастает новое, очень "грамотное" с глубокой верой в безразмерность ресурсов сервера
Это все мое, извращенное, мнение.
Чего сервер жалеть? Вы делайте как западники,на каждую фичу - модуль,и не парится.За всеми этими подсчётами запросов вы забываете зачем,собственно,нужна СMS - для облегчения жизни человека.Процессор считает - человек пиво пьёт.Это правильно
Угу. Только такие человеки хотят, чтобы ещё хостинг при этом стоил $10 в месяц. И искренне негодуют, когда хотстер начинает закручивать гайки для таких сайтов и человеков, и почему-то начинает требовать $100 вместо $10. Как грузите сервер - так и платите тогда!
ругают вьюс, а что взамен. Чем запрос вьюса отличается от снипета?
Valeratal: ругать вьюсы-это понты того же рода,что и поносить виндовс.Типа за...бу себя всмерть сам,но не буду как ламер кнопочками щёлкать.
Никакие это не понты. Кастомным модулем можно получить лучшую производительность, чем с использованием views. А если еще сделать простенькое кэширование, то вообще отлично будет.
Очевидно можно.А кто его будет потом поддерживать,баги ловить?Что делать,если надо там ссылочку убрать,а там поставить?Лезть на сервак за файлами и править вручную?Можно написать что-то универсальное конечно,но это будут те же вьюсы,только хуже.
Конечно, на простых стандартных сайтах views может быть достаточно. Особенно если нужно менять пар-ры без залезания в код. Но на любом более-менее серьезном проекте без кастомного модуля все равно не обойтись, а раз так, то не сильно сложно заодно заменить views своими обработчиками. Потом, как я уже говорил, в этом случае можно реализовать еще и свое кэширование, это еще больше поднимет производительность.
А вообще, это извечный выбор между универсальностью и производительностью. В каждом конкретном случае надо смотреть.
А вы хотите, что бы ПО было год от года "тоньше" и менее требовательным? Скажите это производителям игрушек. Или компании MS, мол никак не могу запустить висту на своём пентиуме. Пентиуме-100. Таки прогресс.
Да и дело-то собственно не в требовательности, а в универсальности. Это и есть главная фича друпала, а оптимизация и тонкая настройка - это очень индивидуальное дело и сильно зависит от специфики проекта. Но у нас принято считать, что друпал должен быть из коробки и универсальным и быстрым (то есть заточеным под конкретную реализацию). Эти понятия несовместимы. В принципе.
Считать запросы - особого смысла не имеет. Когда начинал изучать SQL писал такие запросы, что пока mysql делал выборку, с созданием временных файлов, можно было чаю попить, покурить и фильм посмотреть. Зато эти выборки были упакованы в один запрос!
Cниппет хуже views (по крайней мере, из тех, что я видел на этом сайте). Альтернатива - свой модуль с нужным кэшированием.
Автор цитаты тотально прав. Если я напишу бесконечный цикл или рекурсию глубиной 10к вызовов, то, стало быть, нужно железо тюнить? Имеем быдлокод с 1000 запросов -- бежим за новой памятью/процессором?
Универсальность друпала в сухом остатке -- это автоматический вызов функций с определенными именами. В современном ООП с наследованием и переопределением методов этот подход мне лично кажется смешным. И самое обидное, что за эту "универсальность" приходится платить высокую цену.
Вы опять в крайности. Речь идет о том, как количество запросов приблизить к хотя бы к 50-100. НЕ К ОДНОМУ, а к 50-100. Попробуйте приблизиться к этому числу, используя cck/views/path. Эффективное кеширование сложного кода достигается исключительно ручными способами, из чего следует, что хваленые cck/views/path просто отпадают за ненадобностью и Друпал лишается своего модульного сахара.
Короче, без кодинга опять не получится. Сказка о расширяемости вкупе с быстродействием себя не оправдывает.
Запросы считать необходимо. Видимо, разработчики Дру пренебрегли этим, и вот вам результат.
Мы говорим про школьников или адекватных программистах? Покажите мне в друпале или контирибе подобный код. Да, встречаются разного рода косяки, но на то она и открытая разработка, что сообщество тыкает в них носом.
Восемь лет я профессионально писал на классах в С++ (сам язык знаю уже наверное лет 15). И мне почему-то друпал не кажется смешным. Очень комфортно себя чувствую.
Скорее утрирую. Вот два запроса: "SELECT ... FROM ..." и "SELECT ... INNER ... INNER ... INNER ... GROUP". По-вашему они одинаковы? Там один и там один. Как Вы предлагаете считать?
Насчёт views. Он очень грамотно строит запросы. Да, бывают и косяки, он не идеален. В сложных случаях может и вообще не дать нужного результата. Но! Подавляющее большинство сниппетов, что я видел здесь менее эффективны, чем views. А ведь сниппеты пишут как раз потому что views "быдлокоден".
Истина как всегда посередине. Количество запросов надо уменьшать, но имея в виду, что запрос запросу рознь и иногда один тяжёлый запрос нагрузит сервер больше, чем 10 обычных.
Подобный? Пожалуйста. Модуль wghtml. До сих пор в списке рекомендованных для Drupal 5 кстати.
Вот мои претензии к этому модулю - скажете мало?
При всей открытости разработки в Drupal попробуйте стать разработчиком модуля. Это не так-то просто как может показаться. А уж сколько моих вопросов на drupal.org остались вообще без какого-либо ответа - это снова отдельных разговор. Так что костяков в Drupal ещё ВАГОН. При этом не смотря на тыки сообщества в лице простых смертных исправлять их и даже замечать никто особо не торопится. Гораздо больше шансов что-либо исправить у разработчиков, но не простых смертных, увы.
Но при всём при этом, Drupal всё-таки на сегодняшний момент остаётся лучшим бесплатным и открытым решением в плане CMS.
А как же широко известный факт, что код ООП на php выполняется намного медленнее?
Среднее время скрипта друпал 0.9-1.5 сек. - Это без оптимизации (порой подскакивает до 2 секунд).
В сравнении:
Joomla: 0.5 - 1.5 секунды
(Я всегда думал что Битрикс мамонт, но оказывается он просто пушистый) 0.1 - 0.3 секунды.
Данные брал через strace (трасировка системных вызовов).
что за "скрипт друпал"? какая версия? сколько модулей? сколько данных в базе? характеристики сервера? пост ни о чём
"что за "скрипт друпал"?" - пишите по-делу, думаю вам прекрасно понятно о чем речь.
6.x
2 * процессор Intel Xeon 5650, 2.6 ГГц (всего 24 независимых ядра)
6 * 16 Гб, 6 * 8 Гб памяти Kingston (всего 144 Гб)
12 * SATA 3.5 HDD 2 Тб, RAID 10 и RAID 5 (сырая емкость 24 Тб, итоговая емкость около 12 Тб)
1 * SSD 512 Мб для поддержки баз данных
2 RAID контроллера с 512 мб памяти каждый для независимой работы дисковых систем
Операционная система: Linux 2.6 (Gentoo x64)
Роль сервера: сервер хостинга, сервер баз данных mysql
Характеристика средняя ( учавствовало порядка 100 сайтов в анализе)
бедненький, Intel Xeon с 24-я ядрами запускает друпал за 1.5 сек! видимо пора виндовс переустанавливать
У меня на ноуте быстрее странички генеряться, может вам туда ноут вместо сервера поставить?
Дешевле будет раз в 10!
а у вас на ноутбуке крутятся с сотню тысяч сайтов?
Я говорю про боевой сервер и про усредненные показатели. Дискусия по вопросу верю\неверю не нужна. Я говорю статистические данные а не свое отношение. Вы можете принять это к сведению либо не принимать - но привести факты минимум по такой же выборке. Пожалуйста не продолжайте дискуссию - это просто мусор. Лучше приводите факты по теме.
недавно встречал топик (на друпал.ру) по аналогичной проблеме..
Вроде что-то там было про модули толи локализации толи перевода или что-то подобное..
да пожалуйста:
девелоперская машина с одним ядром. увольте вашего админа или лучше действительно купите вместо сервера ноут
МакХост в треде?
сто тысяч сайтов на одном сервере? дайте 2 таких!!!!111 надо же было такое сказать)))))
Это пример shared hosting с
аццкимрекордным оверсейлом. Представители Гиннесса уже выехали с наградой.Согласен - это я на автомате сказал про сотню.. - порядка 10 000
echo "`tail -n 1 out | awk '{print $2}' | awk -F":" '{print $3}'` - `head -n 1 out | awk '{print $2}' | awk -F":" '{print $3}'`" | bc
среднее показания в пределах: 1.197321
больше всего кушают views,
Никак не получается меньше 0.8 секунды
Да кстати, 200ms - тестировали локально? какие модули включены? сколько сайтов законченных тестировали?