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) - время генерации страницы стало меньше секунды.

Какое время генерации считается приемлемым и не раздражающим пользователя?

Моментальное?

Момент - это тоже какое-то количество времени :)

Стремящееся к нулю, а нуль это бесконечно малая величина

Ты наверно хотел написать на shared. На colocation возможности администратора как раз ограничены только его фантазией :)

да да спасибо.
заговариваться стал.

почему то считается комфортным не более секунды.

Говорят что якобы, у человека за это время не успевает появиться раздражение от неповоротливости интерфейса.

Мдя, понаписали. Истерики много, товарищ volocuga.
"Друпал тормозной..." Ну попробуйте Битрикс, думаете он быстрее? Хотя денег-то стоит ого-го.
С позиций здравого смысла - любая CMS - это тормоза, супротив узкоспециализированного самописного кода (ну понятно, если если его не криворукие дебилы писали). Так почему же >90% таки используют CMS? Потому что достоинства всё-таки перевешивают недостатки.
Поэтому дурацкую по моему мнению дискуссию о том, что тормозит вообще надо заканчивать, переходя от вообще к частному случаю. А далее как правильно писали - отладка вам в руки и вперёд с песней искать косяки. На мой скромный взгляд администратора хостинга, если при генерации обычной страницы делается 1000 запросов к MySQL, а время генерации страницы 15 секунд, то программиста надо вешать к потолку за левую ногу и держать в подвешенном состоянии до тех пор пока вся дурь из головы не вытечет! Тогда возможно появится посветление в уму, он научится правильно использовать и настраивать кэш, не заниматься сериализацией и десериализацией массов данных длиной от 100кбайт при генерации каждой страницы и т.д.

Гы-гы - прав как никогда! Только не "..потолку за левую ногу ..", а сразу за яйца, чего там мелочиться...

Более того - за 10 минут более 6-10 тысяч селектов и блокировать наХ!

А на счет въюсов - добавлю от себя - фигня редкая - использую при крайней нужде и страшном обломе "пальцами по клаве стучать"

На счет "золотого стандарта" - не более 20-30 запросов на страницу! Но друпал такого не позволяет - если грамотно все расписать - выходит от 30-32 до 50 запросов (имею в виду выборки на страницу, а не одна голая статья та всю страницу). И с этими показателями можно нормально жить!

Но поколение подрастает новое, очень "грамотное" с глубокой верой в безразмерность ресурсов сервера :)

Это все мое, извращенное, мнение.

Чего сервер жалеть? Вы делайте как западники,на каждую фичу - модуль,и не парится.За всеми этими подсчётами запросов вы забываете зачем,собственно,нужна СMS - для облегчения жизни человека.Процессор считает - человек пиво пьёт.Это правильно

Угу. Только такие человеки хотят, чтобы ещё хостинг при этом стоил $10 в месяц. И искренне негодуют, когда хотстер начинает закручивать гайки для таких сайтов и человеков, и почему-то начинает требовать $100 вместо $10. Как грузите сервер - так и платите тогда!

ругают вьюс, а что взамен. Чем запрос вьюса отличается от снипета?

Valeratal: ругать вьюсы-это понты того же рода,что и поносить виндовс.Типа за...бу себя всмерть сам,но не буду как ламер кнопочками щёлкать.

Никакие это не понты. Кастомным модулем можно получить лучшую производительность, чем с использованием 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 "быдлокоден".

Конечно, на простых стандартных сайтах views может быть достаточно. Особенно если нужно менять пар-ры без залезания в код. Но на любом более-менее серьезном проекте без кастомного модуля все равно не обойтись, а раз так, то не сильно сложно заодно заменить views своими обработчиками. Потом, как я уже говорил, в этом случае можно реализовать еще и свое кэширование, это еще больше поднимет производительность.

А вообще, это извечный выбор между универсальностью и производительностью. В каждом конкретном случае надо смотреть.

Истина как всегда посередине. Количество запросов надо уменьшать, но имея в виду, что запрос запросу рознь и иногда один тяжёлый запрос нагрузит сервер больше, чем 10 обычных.

Подобный? Пожалуйста. Модуль wghtml. До сих пор в списке рекомендованных для Drupal 5 кстати.
Вот мои претензии к этому модулю - скажете мало?

wgHTML импортирует HTML страницы прямо в Drupal, добавляя
необходимые данные в таблицу node. Таким образом, с одной стороны он обеспечивает
более тесную интеграцию с Drupal, с другой стороны кэширование. Однако, кэширование
HTML-страниц в wgHTML было сделано очень и очень безграмотно. По истечении времени
жизни кэша, старые данные не удаляются, а вместо них загружается новая копия того
же документа. Через полгода работы я обнаружил, что размер моей БД на таблицах
wgHTML вырос уже до гигабайта, а в таблице node много мусора.

При всей открытости разработки в Drupal попробуйте стать разработчиком модуля. Это не так-то просто как может показаться. А уж сколько моих вопросов на drupal.org остались вообще без какого-либо ответа - это снова отдельных разговор. Так что костяков в Drupal ещё ВАГОН. При этом не смотря на тыки сообщества в лице простых смертных исправлять их и даже замечать никто особо не торопится. Гораздо больше шансов что-либо исправить у разработчиков, но не простых смертных, увы.

Но при всём при этом, Drupal всё-таки на сегодняшний момент остаётся лучшим бесплатным и открытым решением в плане CMS.

А как же широко известный факт, что код ООП на php выполняется намного медленнее?

Среднее время скрипта друпал 0.9-1.5 сек. - Это без оптимизации (порой подскакивает до 2 секунд).
В сравнении:
Joomla: 0.5 - 1.5 секунды
(Я всегда думал что Битрикс мамонт, но оказывается он просто пушистый) 0.1 - 0.3 секунды.

Данные брал через strace (трасировка системных вызовов).

что за "скрипт друпал"? какая версия? сколько модулей? сколько данных в базе? характеристики сервера? пост ни о чём

Характеристика средняя ( учавствовало порядка 100 сайтов в анализе)

бедненький, Intel Xeon с 24-я ядрами запускает друпал за 1.5 сек! видимо пора виндовс переустанавливать

У меня на ноуте быстрее странички генеряться, может вам туда ноут вместо сервера поставить?
Дешевле будет раз в 10!

а у вас на ноутбуке крутятся с сотню тысяч сайтов?

Я говорю про боевой сервер и про усредненные показатели. Дискусия по вопросу верю\неверю не нужна. Я говорю статистические данные а не свое отношение. Вы можете принять это к сведению либо не принимать - но привести факты минимум по такой же выборке. Пожалуйста не продолжайте дискуссию - это просто мусор. Лучше приводите факты по теме.

недавно встречал топик (на друпал.ру) по аналогичной проблеме..

Вроде что-то там было про модули толи локализации толи перевода или что-то подобное..

да пожалуйста:

девелоперская машина с одним ядром. увольте вашего админа или лучше действительно купите вместо сервера ноут

МакХост в треде?

сто тысяч сайтов на одном сервере? дайте 2 таких!!!!111 надо же было такое сказать)))))

Это пример shared hosting с аццким рекордным оверсейлом. Представители Гиннесса уже выехали с наградой.

Согласен - это я на автомате сказал про сотню.. - порядка 10 000

strace -tt -f -o out >/dev/null php -c /etc/php.ini -f index.php && 
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 - тестировали локально? какие модули включены? сколько сайтов законченных тестировали?