Оптимизируемся. Часть 1, MySQL

если есть свой (или арендованный) сервер... проблем с Друпалом, скорее всего не будет... настроить всё можно... другое дело, что делать, если настройки недоступны?

Интересно, конечно, но никто не думает, как можно физически урезать кол-во запросов, допустим путем удаления ненужных функций?

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

тогда разве что получается каждому под свои нужды и подстраивать друпал. Единственный правильный выход..

В любом случае хотелось бы посмотреть ваш my.cnf

эмм, а можно точнее сам текст запроса, а то он (текст запроса) немного отформатировался в сообщении

show variables like 'query%';

1. если нет возможности что-то сделать (на хостинге), то по крайней мере можно провести диагностику и сделать предположения о возможных причинах медленной работы. К счастью, хостингов у нас много, есть из чего выбрать.
2. "уменьшить количество запросов" - можно, я на эту тему тоже хочу сделать статеечку. К сожалению, проблема, на мой взгляд, не в универсальности, проблема носит системный характер.

Ну если автор считает, что производительность MySQL зависит только от одной переменной, то единственное, что могу посоветовать автору - это сходить и почитать доки, прежде чем писать "умные" статьи на публику.

Автор не считает, что "производительность MySQL зависит только от одной переменной", он полагает, что мог бы посоветовать голословным критикам далеко не единственное место, куда можно было бы "сходить", однако не станет этого делать в силу очевидных причин.

Я мог бы быть неголословным, но почему я должен вас учить MySQL? Ведь это не я написал статью, а вы. Причём не зная такой элементарной вещи как, например, даже то, что query_cache_size в MySQL 3.x отсутствует вообще. Версию MySQL вы не указали, тип таблиц тоже не указали MyISAM или InnoDB (а ведь многое зависит и от этого). О чём можно говорить дальше? Пионерская статья для пионеров.

Мне было интересно. Я - пионер? (Хотя, мо этой теме еще много можно рассказать...)

А Вас я бы попросил не быть таким заносчивым. Не все здесь админы БД и не всем все подробности реально нужны. (Хотя и интересно для общего развития)

А мне вот другое интересно. Админы БД почему-то молчат, а статью пишут другие. Я например не считаю себя вправе кому-то что-то советовать по причине слабого знания MySQL (хотя вы меня почему-то записали в админы БД). Для того, чтобы кому-то советовать, на мой взгляд, я слишком мало знаю - это к вопросу о заносчивости. Но даже моего "мало" хватает, чтобы быть неголословным критикуя. Делайте выводы - стоит ли в следующий раз писать подобные статьи и выглядеть нелепо или лучше всё-таки изучить предмет на более высоком уровне, а потом писать.

Чем больше информации - тем лучше. Пусть обрывистой или частично неверной.
На то он и форум, чтоб люди информацию добавляли.

corochoone, закон критики: "отвергая предлагай"

Предлагаю вместо бесполезных словопрений показать конфиги сервера. Это, на мой взгляд, единственная результирующая статьи.

Не согласен, чем больше, тем лучше. Если это больше ничего нового не даёт, а только путает новичков в предмете!

Предлагаю:
http://www.linuxshare.ru/docs/software/SQL/mysql/manual/MySQL_Optimisati...
В особенности раздел:
http://www.linuxshare.ru/docs/software/SQL/mysql/manual/Optimising_the_S...

Написано не мной, но даже этот старинный документ много информативней и полезней!

и что касается InnoDB:
http://www.mysql.ru/docs/man/InnoDB_start.html

А если что-то ещё кому не понятно, то надеюсь Яндексом все умеют пользоваться? Года 3 назад было мало чего на русском - сейчас даже для тех, кто в английском совсем не шарит - найти доки на русском нет проблем!

Конфиги сервера показывать нет смысла, потому что надо сперва разобраться у кого какая версия MySQL стоит, кто какие типы таблиц юзает - MyISAM или InnoDB, а также у кого какая конфигурация сервера. Именно всё это влияет на конфиги. Иначе это тоже самое, что показывать разные автомобили: запорожец и мерседес - и тот и другой ездят, но разницу надеюсь объяснять не надо!

> Админы БД почему-то молчат, а статью пишут другие.

потому что кроме друпаловского модуля db_maintenance ей ничего не поможет.
а друпал грузит mysql раз в 10 сильнее чем другие cms, не спасает даже выделенный сервер (

а друпал грузит mysql раз в 10 сильнее чем другие cms, не спасает даже выделенный сервер (

Сравнивать CMS только по нагрузке совсем не правильно. Не забывайте что по функциональности друпал тоже далеко впереди т.н. "других CMS". Уже есть десятки (если не сотни) работающих сайтов с огромной посещаемостью. Отсюда следует, что производительность для друпала не проблема. При условии нормального хостинга и прямых рук, конечно.

PS ничего личного, просто устал уже от таких необоснованных жалоб.

Задайтесь вопросом, почему почти самая частая претензия к Друпалу - его тормознутость?
Если исключить системные причины (такие, как использование php как такового, модульность), то вырисовывается интересная картина: это не Друпал тормозит о сравнению с другими CMS, это те, другие ЦМСки как-то сумели ужиться на площадках, которые нерадивые хостеры и сисадмины не в состоянии как следует настроить.

Именно так! "Сумели ужиться на площадках, которые нерадивые хостеры и сисадмины не в состоянии как следует настроить". Причем, ценой урезанного функционала.

А ведь найти вменяемый хостинг вполне реально.

шутите, да, издеваетесь? для обычных цмс-ок нормальным считается 10-30 запросов к базе на одну страничку, а 100 считается катастрофически много, а в друпале нормальным считается 100-300.

А в обычных CMSках есть модули path и locale? Отключите path и переведите тексты в исходном коде - вот Вам и 30 запросов!

да нет, 30 запросов это ерунда, включите модуль devel и посмотрите что творится, особенно в 4.7 друпале - мне так кажется что всю малину портит один единственный модуль - menu..., ну и еще views_build_view абсолютно везде лезет с запросом почти под 2 секунды.

Затянутые по времени запросы - возможно проблема индексов.

- Купил Белаз, прикинь, 200 мешков цемента за раз может перевезти!
- А я на днях Феррари купил. Сколько мешков с цементом перевезёт не знаю... 3-4 влезет, наверное.
- Ацтой у тебя тачка!

Не надо говорить о средней температуре в больнице - пустое это...

2 СЕКУНДЫ?! Не миллисекунды, а секунды? Тогда, скорее всего, Вам надо идти искать пряморуких админов :)

при чем тут админы и белаз? вот запрос который везде цепляется из за того что почему-то блоки views просчитываются везде даже если они не выводятся, наверно ошибка в модуле block - не могу найти где.

1519.56 1 views_build_view SELECT node.nid, node.created AS node_created_created, node.created AS node_created, node.title AS node_title, node.changed AS node_changed, users.name AS users_name, users.uid AS users_uid FROM node node LEFT JOIN term_node term_node ON node.nid = term_node.nid AND term_node.tid = 'Array' LEFT JOIN term_node term_node2 ON node.nid = term_node2.nid AND term_node2.tid IN ('183') LEFT JOIN term_node term_node3 ON node.nid = term_node3.nid AND term_node3.tid IN ('138') LEFT JOIN users users ON node.uid = users.uid WHERE (term_node.tid IS NULL) AND (node.status = '1') AND (term_node2.tid IS NULL) AND (term_node3.tid IS NULL) ORDER BY node_created_created DESC LIMIT 0, 20

плюс откуда-то всегда берется по 5-10 различных левых произвольных node_load - из за того что и taxonomy_block тоже везде просчитывает блоки которые идут на главной.

7.45 1 node_load SELECT n.nid, n.vid, n.type, n.status, n.created, n.changed, n.comment, n.promote, n.moderate, n.sticky, r.timestamp AS revision_timestamp, r.title, r.body, r.teaser, r.log, r.format, u.uid, u.name, u.picture, u.data FROM node n INNER JOIN users u ON u.uid = n.uid INNER JOIN node_revisions r ON r.vid = n.vid WHERE n.nid = 531

Действительно, запрос серьезный. Но, все-таки, при хороших настройках базы должно быть намного меньше.

mysql она настроена по дефолту, дальше ее настраивать не надо ) - все равно не поможет... надо только оптимизировать запросы и правильно индексировать таблицы.

я заметил вот что - в друпале 4.7 (в 5 не смотрел) - блоки те что на главной по центру сделаны через views и taxonomy_block, они все равно просчитываются для каждой страницы, даже там где их нет - это у меня только или у всех? может потому что у страниц стоит признак "показывать на главной"?

шутите, да, издеваетесь? для обычных цмс-ок нормальным считается 10-30 запросов к базе на одну страничку, а 100 считается катастрофически много, а в друпале нормальным считается 100-300.
гм. иногда встречаю людей маникально заставляющих свой движок работать на 10 и менее запросах. только бред это.
во многих случаях один запрос может выполняться существенно медленнее чем с десяток simple (простых) запросов. Так что количество запросов - это еще не показатель производительности системы в целом.

Затянутые по времени запросы - возможно проблема индексов.
не всегда. иногда появляются запросы которые просто не могут по своей природе использовать индексы - в результате полное сканирование таблиц (не знаю как в Views - не пользуюсь им и не собираеюсь, нечто такое наблюдал в pathauto под 4.7).

to kiev1
а вы не пробовали смотреть что выдает EXPLAIN <запрос>?

> а вы не пробовали смотреть что выдает EXPLAIN <запрос>? вот этот запрос

SQL-запрос:
EXPLAIN SELECT n.nid, n.vid, n.type, n.status, n.created, n.changed, n.comment, n.promote, n.moderate, n.sticky, r.timestamp AS revision_timestamp, r.title, r.body, r.teaser, r.log, r.format, u.uid, u.name, u.picture, u.data
FROM node n
INNER JOIN users u ON u.uid = n.uid
INNER JOIN node_revisions r ON r.vid = n.vid
WHERE n.nid =531


выдает вот что

"ну и еще views_build_view абсолютно везде лезет с запросом почти под 2 секунды"

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

модуль forum также использует много запросов и его тоже надо отключить... при пяти-шести модулях у вас будет всё летать на любом хостинге... а в других CMS такие же возможности штатно вообще не поставляются...

ну да, path, он конечно тоже долгие запросы делает и их не так уж много, потом эта revision везде лезет - как ее отключить - давайте придумаем, а?
И главное - вот с той табличкой - что из EXPLAIN получилась - с ней что делать? как теперь с этим жить? научите оптимизировать запросы.

есть модуль на Друпал.орг уничтожает все ревизии...
я не помню где он там, посмотрите по слову revision

как оптимизировать запросы я уже говорил... существует даже модуль специальный...
а вообще, главное в жизни - это или достигать невозможного (много учиться, стараться и тд.) или жить по возможностям (имея потребности не превышающие эти самые возможности)...

а что табличка означает, особенно последняя строчка?

последняя строчка означает сканирование таблицы node_revisions ввиду того что не используются индексы (скорее всего в этой таблице отсутствует индекс по полю vid). в случае с небольшими сайтами - проблем по идее не должно возникать. но представьте сайт скажем так с 16-18 тыс. нод. это будет ужас :)

select type - тип оператора SELECT. В данном случае у вас все запросы "простые" (все запросы - т.е. запрос можно записать как три запроса, без использования JOIN)

type - тип соединения. const - это хорошо. т.к. считываются только один раз и содержат только максимум 1 строку. (что собственно видно из столбца rows). А вот ALL означает полное сканирование таблицы.Обычно это плохо. Избегать такой ситуации можно используя индексы.

possible_keys - используемые индексы. сразу видно что в последней строке не используются индексы.

extra - у вас в последней строке написано using where. Это означает что используется выражение where (в данном случае будет типа SELECT * node_revisions r WHERE r.vid=значение). Более жесткого ограничения для таблицы node_revisions не задается соответственно выбираются все записи с этим значением поля vid. Как я понимаю (если есть гуру подтвердите) - такой запрос приведет к сканированию таблицы node_revisions в не зависимости от ограничений n.nid.

Если оптимизировать этот запрос, то для начала конечно можно добавить индекс в node_revisions для поля vid. Но в целом лично мне этот запрос не понятен - т.е. что этот запрос делает:
выводит информацию о конкретной ноде (531й) из таблиц node и node_revisions, докучи подгружая данные о юзере.
Каким боком здесь INNER JOIN node_revisions r ON r.vid = n.vid ? Что дает эта конструкция кроме как лишнего сканирования таблицы node_revisions? имхо правильнее было бы INNER JOIN node_revisions r ON r.nid=n.nid (даже с логической точки зрения). И еще зачем в данном случае вообще использовать запрос заранее зная номер ноды? т.е. не проще ли использовать в нужном месте node_load и node_view и модифизировать шаблон в нужном месте для правильно вывода? (вот в этом моменте я сомневаюсь, т.к. для меня проще было бы самому модуль написать в котором реализуются нужные блоки а в теме - только вывод в независимости от содержания)

"потом эта revision везде лезет"
да но там содержимое хранится, не в node а в node_revisions в полях body и teaser. :) модуль который "убивает ревизии" убивает версии как я понимаю саму таблицу он наврядли убьет, это было бы неправильно наверное :)

спасибо!
у таблицы node_revisions есть все ключи
почему делается выборка из всей таблицы - не знаю - наверно это баг модуля views - потому что этот запрос делает функция views_build_view - вид совсем не сложный - вывод блока из нескольких таксономий.

emzi says: "уменьшить количество запросов" - можно, я на эту тему тоже хочу сделать статеечку.

Очень интересно было бы почитать статью на эту тему, а то меня данная проблема тоже очень волнует ;(

Эээээээ.... Кто-то сказал pgsql? Или всё можно списывать эту субд...? Топик напряженный - люди улыбайтесь чаще :)

Да, похоже у друпала это по-жизни проблема с тормознутостью - сайт drupal.org еле живой, поиск уже они отключили...

Встречал ссылку, что мол Ворнер брозерс что-то замутили на друпале... и типа Solaris у них там стоит :) SAMP: Solaris Apache MySQL PHP. Может вот оно что ему надо?

Это Drupal тормознутый? Ребята, вы ещё Bitrix не видели :) Особенно последний. Там админку чтобы открыть надо мегабайт данных скачать (диалапщики уже могут отдыхать), а уж как сервер напрягается во время работы - это вообще сказка :)

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

Так оно бегало быстрее или нет ?:)
Заметка себе на будущее посмотреть к какие таблицам и по каким полям друпал круче всего муржит бд:) и самому поковырять...

Я думаю, что в Друпал та же проблема, что и в Битрикс и других CMS. Просто разработчики тестируют всё на табличках с 10 колонками. Если нет индексов, то на таких данных и не напрягает. А если данных в таблице сотни тысяч и миллионы строк, вот тут-то тормоза и наступают.

Могу дать бесплатный совет для тех кто не знает. Включайте в mysql протоколирование тяжёлых запросов (long-queries) и смотрите какие запросы выполняются непозволительно долго. А дальше - хоть phpMyAdmin вам в руки, explain и осмотр всего этого дела на предмет наличия нужных индексов с последующим их созданием. Довольно неплохо помогает!

> Просто разработчики тестируют всё на табличках с 10 колонками.

не - в друпале все тестируют на самом drupal.org - а там очень много материалов, они делают что могут, наверно что-то придумают.

не - в друпале все тестируют на самом drupal.org
если говорить о ядре - да, но если бы все модули тестировались на ДО, он бы лежал перманентно

Господа - на org черным по белому написано
Modules

Modules are plugins for Drupal that extend its core functionality. Only use matching versions of modules with Drupal. Modules released for Drupal 4.7.x will not work for Drupal 5.x. These contributed modules are not part of any official release and may not be optimized or work correctly.
Эти дополнительные модули не являются частью официального релиза и могут буть не оптимизированы или работать некорректно.

Это правда, но согласитесь, что Drupal в core поставке мало кому интересен :)
А вообще спасение - дело рук самих утопающих. Слава Богу Drupal - это opensource проект и никто не мешает принять участие в его разработке. К сожалению и за мной такой грешок водится - что-то поправил, что-то соптимизировал, но выслать рецепты разработчикам... увы. :( В результате следующий кто наступит на эти грабли решает их самостоятельно!

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