1000 запросов к БД, 15 секунд генерации страницы

Главные вкладки

Аватар пользователя Mystex@drupal.org Mystex@drupal.org 27 ноября 2009 в 14:45

Приветствую!

Делаю сайт на Drupal 6, активно использую CCK, Views. Ещё не вся функциональность реализована, но количество запросов иногда переваливает за 1000, время генерации страниц доходит до 15 секунд.

С такими цифрами нереально запускать сайт для людей! Как можно оптимизировать работу Друпала, что подковырять, где покодить?

Комментарии

Аватар пользователя axel axel 27 ноября 2009 в 14:56

Количество запросов и время генерации коррелируются не сильно. Для кучи модулей вполне может быть и больше > 1000 мелких запросов, т.к. по дефолту друпал хранит всё кроме файловых аттачей в БД - контент, кеши, локализацию, статусные переменные, данные сессий. Но на соответствующим образом настроенной СУБД это некритично. Вот 15 секунд означает, что что-то настроено не правильно или каки-то модули имеют некорректный код - в контриб-модулях это нередко бывает. Надо поставить модуль devel, включить в нём статистику и смотреть какие запросы или генерация кода в php занимают сколько времени.

Аватар пользователя Mystex@drupal.org Mystex@drupal.org 27 ноября 2009 в 16:04

axel

А каким образом должна быть настроена БД для друпала и каково приемлемое время выполнения запроса к БД?
Модуль Devel уже стоит, как раз через него и смотрю статистику.

Аватар пользователя volocuga volocuga 27 ноября 2009 в 16:06

"<a href="mailto:Mystex@drupal.org">Mystex@drupal.org</a>" wrote:
время генерации страниц доходит до 15 секунд.

Да вы где смотрите? На локалхосте? У меня локально бывало комп вообще вис ВЕСЬ

На Unix-ах нет никаких 15 секунд

Пост axel-я выше,читаем между строк:
Друпал очень прожорливая хрюшка-лечится хорошим железом

Аватар пользователя Mystex@drupal.org Mystex@drupal.org 27 ноября 2009 в 16:16

То что хрюшка прожорливая это точно! Смотрю на локалхосте, и комп вроде не слабый. Попробую протестировать на сервере хостера.

Аватар пользователя Demimurych Demimurych 27 ноября 2009 в 16:19

"<a href="mailto:Mystex@drupal.org">Mystex@drupal.org</a>" wrote:
А каким образом должна быть настроена БД для друпала и каково приемлемое время выполнения запроса к БД?
Модуль Devel уже стоит, как раз через него и смотрю статистику.

в том же модуле девел есть и время выполнения запросов. И имя модулей.
Посмотрите там

Не нашли. Поставьте что нибудь вроде x debug и включите профилирование. Получите подробный отчет где и как долго выполнялся какой код.

Аватар пользователя volocuga volocuga 27 ноября 2009 в 17:34

"Demimurych" wrote:
в том же модуле девел есть и время выполнения запросов.

Ради бога,не примите как наезд,но это вроде "бла-бла-бла".Друпал ЖРЁТ и жрёт много.Помоему это очевидно.Хорошее железо и без гвоздей

Аватар пользователя Demimurych Demimurych 27 ноября 2009 в 17:24

"volocuga" wrote:
Ради бога,не примите как наезд,но это вроде "бла-бла-бла".Друпал ЖРЁТ и жрёт много.Помоему это очевидно.Хорошее железо и гвоздей

ну давайте по дискутируем.

что значит много? с чем сравнивать в каких случаях и так далее.

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

Я придерживаюсь того мнения что, например задачи кеширования нужно решать правильно конфигурацией серверной стороны.

Вы будете спорить с тем что верной конфигурацией платформы я снижу нагрузку как на ЦП так и на БД? Да не просто снижу, а в десятки раз.

А если это возможно, то разговор о прожорливости друпала мягко говоря яйца выеденного не стоит.

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

Аватар пользователя axel axel 28 ноября 2009 в 13:12

Demimurych wrote:
Впрочем, я готов согласиться с тем что на колокешинах, где у администратора крайне ограниченный ресурс по конфигурированию окружения, дурпал может быть не самым производительным решением.
Ты наверно хотел написать на shared. На colocation возможности администратора как раз ограничены только его фантазией Smile

Аватар пользователя volocuga volocuga 27 ноября 2009 в 17:32

Ну в дясятки раз.Ээээ...не верю

И к тому же:

"Demimurych" wrote:
Давайте оттолкнемся от того что перед нами типичное друпал ядро, где установлены модули написанные вменяемыми программистами.

Ну в подавляющем большинстве люди берут модули с орга.Я верю,что там есть откровенно свинские штуки,но также верю и в коллективные разум.Если модули юзают тыщи людей,они по определению не могут быть погаными.Не так ли?

"Demimurych" wrote:
задачи кеширования нужно решать правильно конфигурацией серверной стороны.

Да мне сдаётся,не только кеширования - всего

Аватар пользователя Demimurych Demimurych 27 ноября 2009 в 17:46

"volocuga" wrote:
Ну в дясятки раз.Ээээ...не верю

даже не вникая в подробности работы конкретного проекта,
простым включением кеша зпрососов + кеш пхпного апкодов + mod_expire на всю статику + фронтендом что нибудь легкой вроде lighthttp или nginx с кеширущим прокси = профит.

анонимусы вообще будут выгребать статику из кеша. без единого запроса к бд или к php
прочие, в большистве случаев будут работать с кешем бд и апкодным кешем.
нагрузка снижается в десятки раз.

"volocuga" wrote:
Ну в подавляющем большинстве люди берут модули с орга.Я верю,что там есть откровенно свинские штуки,но также верю и в коллективные разум.Если модули юзают тыщи людей,они по определению не могут быть погаными.Не так ли?

Чаще всего да. Я вводную про программистов дал для того, чтобы упредить аргументы из разряда а если модуль делает такой запрос который сервер БД не может закешировать. И так далее.

"volocuga" wrote:
Да мне сдаётся,не только кеширования - всего

не понял фразы. А чего еще?

Аватар пользователя gumk gumk 27 ноября 2009 в 20:23

Хостинг от gor + authcache модулей больше 40 запросов лучше не спрашивайте, среднее время загрузки для за логиного пользователя менее 0.3 сек

Аватар пользователя shp shp 27 ноября 2009 в 21:11

Ваши рассуждения о том, что Друпалу нужно хорошее железо, в данном случае неуместны, потому что 15 секунд - это нереально много. Впрочем, как и 1000 запросов Smile

Самый простой метод "в лоб". Отключите все модули кроме Devel, затем включайте поочереди. Таким образом определите, что дает такие тормоза.

P.S. Друпал, конечно, прожорливый, но если постараться - оптимизировать реально.

Аватар пользователя volocuga volocuga 27 ноября 2009 в 23:18

"shp" wrote:
Впрочем, как и 1000 запросов :)

1000 запросов влёгкую получается на странице модулей.Даже 3000 :)

"shp" wrote:
Отключите все модули кроме Devel, затем включайте поочереди.

Ну понятно что тормозит - вьюсы,сск,pathauto,то есть те модули,без которых друпал гавно на палочке

Аватар пользователя Mystex@drupal.org Mystex@drupal.org 28 ноября 2009 в 10:43

Загрузил скрипты на хостинг (Linux) - время генерации страницы стало меньше секунды.

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

Аватар пользователя Demimurych Demimurych 28 ноября 2009 в 14:36

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

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

"<a href="mailto:Mystex@drupal.org">Mystex@drupal.org</a>" wrote:
Какое время генерации считается приемлемым и не раздражающим пользователя?

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

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

Аватар пользователя Azerot Azerot 28 ноября 2009 в 15:57

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

Аватар пользователя ilya ilya 19 января 2010 в 2:07

"Azerot" wrote:
Мдя, понаписали. Истерики .....

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

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

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

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

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

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

Аватар пользователя volocuga volocuga 19 января 2010 в 2:51

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

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

Аватар пользователя Azerot Azerot 19 января 2010 в 8:22

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

Аватар пользователя volocuga volocuga 19 января 2010 в 12:32

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

Аватар пользователя shp shp 20 января 2010 в 0:41

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

Аватар пользователя volocuga volocuga 20 января 2010 в 1:56

Очевидно можно.А кто его будет потом поддерживать,баги ловить?Что делать,если надо там ссылочку убрать,а там поставить?Лезть на сервак за файлами и править вручную?Можно написать что-то универсальное конечно,но это будут те же вьюсы,только хуже.

Аватар пользователя shp shp 21 января 2010 в 0:13

Quote:
Очевидно можно.А кто его будет потом поддерживать,баги ловить?Что делать,если надо там ссылочку убрать,а там поставить?Лезть на сервак за файлами и править вручную?Можно написать что-то универсальное конечно,но это будут те же вьюсы,только хуже.

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

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

Аватар пользователя Dan Dan 20 января 2010 в 7:23

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

А вы хотите, что бы ПО было год от года "тоньше" и менее требовательным? Скажите это производителям игрушек. Или компании MS, мол никак не могу запустить висту на своём пентиуме. Пентиуме-100. Таки прогресс.
Да и дело-то собственно не в требовательности, а в универсальности. Это и есть главная фича друпала, а оптимизация и тонкая настройка - это очень индивидуальное дело и сильно зависит от специфики проекта. Но у нас принято считать, что друпал должен быть из коробки и универсальным и быстрым (то есть заточеным под конкретную реализацию). Эти понятия несовместимы. В принципе.

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

Считать запросы - особого смысла не имеет. Когда начинал изучать SQL писал такие запросы, что пока mysql делал выборку, с созданием временных файлов, можно было чаю попить, покурить и фильм посмотреть. Зато эти выборки были упакованы в один запрос!

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

Cниппет хуже views (по крайней мере, из тех, что я видел на этом сайте). Альтернатива - свой модуль с нужным кэшированием.

Аватар пользователя kyky kyky 20 января 2010 в 11:01

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

Автор цитаты тотально прав. Если я напишу бесконечный цикл или рекурсию глубиной 10к вызовов, то, стало быть, нужно железо тюнить? Имеем быдлокод с 1000 запросов -- бежим за новой памятью/процессором?
"Dan" wrote:
Да и дело-то собственно не в требовательности, а в универсальности. Это и есть главная фича друпала

Универсальность друпала в сухом остатке -- это автоматический вызов функций с определенными именами. В современном ООП с наследованием и переопределением методов этот подход мне лично кажется смешным. И самое обидное, что за эту "универсальность" приходится платить высокую цену.
"Dan" wrote:
Считать запросы - особого смысла не имеет. Когда начинал изучать SQL писал такие запросы, что пока mysql делал выборку, с созданием временных файлов, можно было чаю попить, покурить и фильм посмотреть. Зато эти выборки были упакованы в один запрос!

Вы опять в крайности. Речь идет о том, как количество запросов приблизить к хотя бы к 50-100. НЕ К ОДНОМУ, а к 50-100. Попробуйте приблизиться к этому числу, используя cck/views/path. Эффективное кеширование сложного кода достигается исключительно ручными способами, из чего следует, что хваленые cck/views/path просто отпадают за ненадобностью и Друпал лишается своего модульного сахара.
Короче, без кодинга опять не получится. Сказка о расширяемости вкупе с быстродействием себя не оправдывает.
Запросы считать необходимо. Видимо, разработчики Дру пренебрегли этим, и вот вам результат.

Аватар пользователя Dan Dan 20 января 2010 в 12:47

"kyky" wrote:
Автор цитаты тотально прав. Если я напишу бесконечный цикл или рекурсию глубиной 10к вызовов, то, стало быть, нужно железо тюнить? Имеем быдлокод с 1000 запросов -- бежим за новой памятью/процессором?

Мы говорим про школьников или адекватных программистах? Покажите мне в друпале или контирибе подобный код. Да, встречаются разного рода косяки, но на то она и открытая разработка, что сообщество тыкает в них носом.

"kyky" wrote:
В современном ООП с наследованием и переопределением методов этот подход мне лично кажется смешным.

Восемь лет я профессионально писал на классах в С++ (сам язык знаю уже наверное лет 15). И мне почему-то друпал не кажется смешным. Очень комфортно себя чувствую.

"kyky" wrote:
Вы опять в крайности. Речь идет о том, как количество запросов приблизить к хотя бы к 50-100. НЕ К ОДНОМУ, а к 50-100. Попробуйте приблизиться к этому числу, используя cck/views/path.

Скорее утрирую. Вот два запроса: "SELECT ... FROM ..." и "SELECT ... INNER ... INNER ... INNER ... GROUP". По-вашему они одинаковы? Там один и там один. Как Вы предлагаете считать?

Насчёт views. Он очень грамотно строит запросы. Да, бывают и косяки, он не идеален. В сложных случаях может и вообще не дать нужного результата. Но! Подавляющее большинство сниппетов, что я видел здесь менее эффективны, чем views. А ведь сниппеты пишут как раз потому что views "быдлокоден".

Аватар пользователя Azerot Azerot 21 января 2010 в 9:33

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

Quote:
Покажите мне в друпале или контирибе подобный код.

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

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

Quote:
Да, встречаются разного рода косяки, но на то она и открытая разработка, что сообщество тыкает в них носом.

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

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

Quote:
В современном ООП с наследованием и переопределением методов этот подход мне лично кажется смешным. И самое обидное, что за эту "универсальность" приходится платить высокую цену.

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

Аватар пользователя z-s z-s 19 октября 2011 в 10:25

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

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

Аватар пользователя xxandeadxx xxandeadxx 19 октября 2011 в 10:38

"z-s" wrote:
Среднее время скрипта друпал 0.9-1.5 сек

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

Аватар пользователя z-s z-s 27 октября 2011 в 17:41


1.


"что за "скрипт друпал"?" - пишите по-делу, думаю вам прекрасно понятно о чем речь.

2.


6.x

3.


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 сайтов в анализе)

Аватар пользователя Dan Dan 27 октября 2011 в 18:36

"z-s" wrote:
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

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

Аватар пользователя z-s z-s 27 октября 2011 в 18:41

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

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

Аватар пользователя Orion76 Orion76 27 октября 2011 в 18:51

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

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

Аватар пользователя xxandeadxx xxandeadxx 10 ноября 2015 в 11:47

"z-s" wrote:
Лучше приводите факты по теме.

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

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

Аватар пользователя v1adimir@drupal.org v1adimir@drupal.org 27 октября 2011 в 21:41

"z-s" wrote:
а у вас на ноутбуке крутятся с сотню тысяч сайтов?

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

Аватар пользователя z-s z-s 28 октября 2011 в 13:28

Согласен - это я на автомате сказал про сотню.. - порядка 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 - тестировали локально? какие модули включены? сколько сайтов законченных тестировали?