19 января 2007 в 22:45
Тезис: при грамотном создании индексов на таблицах происходит значительное (в несколько раз) увеличение быстродействия Drupal.
Пролог: действо развернулось при переезде с development-сервера на production. Development-сервер = чего-то-там-2-х-ядерное-Opteron-2Гб-памяти. Точнее не могу сказать, т.к. сервер не мой личный. Но 99% ресурсов были в распоряжении разработчика. Production = недорогой местный VPS, 3% CPU от "не менее 10ГГц в сумме от всех процессоров" (экспериментально установлено наличие 4 процессоров), 128Мб RAM и столько же swap.
Н.У.: Сайт - небольшой новостийный a-la Digg.com, список модулей - так же в аттаче.
Development-сервере - Gentoo Linux, production - Fedore Core 4.
Везде Apache 1.3.37, PHP 5.1.6 + eAccellerator, MySQL 5.0.32. Drupal 4.7.5.
PHP memory_limit 128M, execution_time 120. Более подробно - см. прикреплённые php.ini, my.cnf и список загруженых модулей Apache и PHP.
Всё ПО настроено на максимальное быстродействие, кэширование, где можно, включено.
КЭШ В DRUPAL ОТКЛЮЧЕН.
На development-сервере немного притормаживал, после рестарта Apache и MySQL, когда кэши не заполнены, главная страница появлялась через 40-60 секунд. Иногда вообще не появлялась, убиваясь об execution_time.
Но production - соответственно, ещё хуже оказалось, первая страница показывалась с 3-го раза, после заполенения всех кэшей.
Всё дальнейшее относится именно к production.
Действо:
Получен список самых медленных запросов к БД, требующих для выполенения более 1 секунды.
Долгая медитация на темы EXPLAIN SELECT ..... и создание недостающих индексов.
Дальше написан скрипт, выбирающий все SELECT'ы из mysqld.log и подсчитывающий время их выполения.
Ещё раз долгая медитация на темы EXPLAIN SELECT ..... и создание недостающих индексов.
Начальная и конечная схемы БД приведены в аттаче. (Включены все используемые сайтом таблицы, как ядерные, так и от разных модулей.)
Вывод: значительное увеличение быстродействия, даже первая страница при пустых кэшах грузится в пределах 10-ти секунд.
Эпилог: существуют маленькие программки mysqlreport и mysqlsla, которые тоже умеют статистику и время выполения запросов считать. Но свой скрипт всё равно лучше 
Если все разработчики модулей и ядра Drupal'а разберутся с индексацией в своих таблицах, то у многих CMS появится достойный конкурент по быстродействию.
Drupal 5 ещё не смотрел, надеюсь там ещё большего быстродействия можно будет добиться.
| Вложение | Размер |
|---|---|
 php.ini_.txt | 6.88 КБ |
| my.cnf_.txt | 2.75 КБ |
| DrupalModules.txt | 669 байт |
| ApacheModules.txt | 204 байта |
| schema_OLD.sql_.txt | 42.51 КБ |
| schema.sql_.txt | 46.57 КБ |
 slowLog.php_.txt | 1.17 КБ |
Комментарии
Мой Вам глубочайший прижизненный памятник
И огромное СПАСИБО за содержательную и актуальною заметку по оптимизации.
ЗЫ А так же за наглядное доказательство того, что в умелых руках всё работает как дОлжно, а не как принято.
---
http://drupal5.ru - информация для друпателей
качественные ответы только на качественные вопросы
> Drupal 5 ещё не смотрел, надеюсь там ещё большего быстродействия можно будет добиться.
Да, это было бы интересно и особенно актуально. Просим, просим!
Еще одно доказательство того, что спецов по БД пора заносить в красную книгу. А если они попадаются в руки как член команды , то нужно не жалеть этих самых рук и носить их на руках, плечах и шее
мда, ещё бы было написана точная инструкция по применению... а так, только для разработчиков... но всё равно, спасибо...
я так понимаю это не нам инструкция нужна а разработчикам
Респект, но, по-моему, это несколько неправильно - мерять производительность по времени открытия страниц в браузере. Потому что время открытия в браузере (упрощенно) = время генерации страницы + время передачи данных от сервера к вам (это уже зависит от качества интернет-соединения). Нам нужно как раз таки время генерации. Так что подключайте скрипты-таймеры и выводите на страницах время генерации!
Для разработчиков следует иметь в виду, что mysql очень быстро выполняет ПРОСТЫЕ запросы к базе. Сам имел опыт когда сложный запрос к табличке из 10 записей выполнялся 1.5 секунды, при этом наличие или отсутсвие индексов роли не играло.
В обычном варианте когда php и mysql установлены на одной системе, быстрее получается сделать 2 запроса к базе, получить результат и обработать его в скрипте модуля, нежели делать один большой запрос.
PS. В одной табличке модуля сейчас 312800 записей - ничего не тормозит. (кол-во ноликов - правильное
Кстати - а есть ли модуль, который считает и рисует на каждой страничке время генерации?
Зачем отдельный модуль? Посмотрите документацию по ф-ии microtime(), в начале index.php засекаете время, в конце - опять получаете время и выводите разницу. И все дела...
Модуль devel, если мне не изменяет склероз.
---
http://drupal5.ru - информация для друпателей
качественные ответы только на качественные вопросы
Еще бы написали какие именно индексы были добавлены/изменены/удалены, а то сверять два здоровенных sql-а файла тяжко!