Производительность сайта на Drupal. Анализ серверной части

abody

Постоялец
Регистрация
14 Сен 2006
Сообщения
251
Реакции
166
Немного воды

Что делать, если сайт дохнет прямо на глазах? С чего начать, если вам подсунули полуживой проект с просьбой поднять его на ноги? Ответ выглядит немного по-капитански: анализ. Вам надо понять, где именно закралась проблема в производительности, которая мешает быстрой работе сайта. Сразу хочу сказать, что в этой статье я буду принимать на веру, что вы выбрали правильный хостинг, и проблема заключается не в нём. Безусловно, многие проблемы с производительностью на сервере можно решить докупив ещё железа, однако не каждый заказчик готов платить за это (хотя по подсчётам, докупить железа обойдётся гораздо дешевле, чем тратиться на специалиста по производительности, но кому это объяснишь ;)). Однако если же косяк с производительностью серьёзный - то он может съесть ресурсы даже докупленного железа, и тогда на вас очень обидятся. А если проблема окажется в клиентской части сайта - то хоть дата-центры скупайте, а у клиентов сайты будут тормозить.
Вступление

Сайт разделяется на 2 части - клиентская и серверная. К клиентской части относится всё, что скачивает браузер клиента (js, css, изображения, html). К серверной - всё, что от клиента спрятано (в основном это php код, включающий запросы к базе данных).
Первым делом надо посмотреть где тормозит сайт - на клиентской или серверной его части. В этом мне помогает Для просмотра ссылки Войди или Зарегистрируйся (плагин Firefox). Открываем его на вкладке СЕТЬ и перезагружаем страницу.
Для просмотра ссылки Войди или Зарегистрируйся
На первой строчке вы увидите время, которое потратил браузер на ожидание ответа от сервера (3,97 секунд - это непозволительно огромное время ожидания ответа от сервера). За это время поизошло следующее:
  • Браузер послал запрос к серверу на получение страницы
  • Друпал произвёл полный бутстрап
  • На серверной стороне выполнились все запросы к базе данных, необходимые для получения страницы
  • Был отрендерен весь контент, полученный из базы данных
  • Браузер получил ответ от сервера в виде сформированного html кода
Анализ серверной части сайта

Исходя из скриншоты видно, что проблема медленной загрузки страницы находится где-то на сервере. Это значит, что у нас либо тяжёлые запросы к базе данных, либо плохо написанный код. Для дальнейшего анализа необходимо поставить модуль Для просмотра ссылки Войди или Зарегистрируйся. Из коробки он умеет отслеживать запросы к базе данных. На странице /admin/config/development/devel включите отслеживание запросов к базе данных:
Для просмотра ссылки Войди или Зарегистрируйся
На скриншоте внизу располагается секция XHProf - о ней мы обязательно поговорим чуть позже.
Итак, после включения вывода запросов внизу каждой страницы будет выводиться список всех запросов к бд (в настройках я их отсортировал по убыванию времени выполнения:(
Для просмотра ссылки Войди или Зарегистрируйся
На скриншоте видно, что пару запросов несколько превышают желаемый лимит времени на запрос в 5 милисекунд. Однако чётко видно, что все запросы выполнились за 196 милисекунд (0,196 секунд), а это вполне неплохо => следовательно, проблема не в запросах. Если бы проблема была в них, можно было бы воспользоваться дополнительными опциями (пункт 3:(
  • P - Placeholders, показывает запрос с заменителями переменных (как они есть на скриншоте)
  • A - Arguments, показывает аргументы запроса вместо placeholder'ов
  • E - Для просмотра ссылки Войди или Зарегистрируйся
Также на скриншоте можно заметить (пункт 2), что в какой-то момент PHP потребовалось 189 мб оперативки - а вот это уже много. Теперь было бы неплохо пробежаться по функциям и посмотреть в какой момент потребовалось столько памяти. С этим нам может помочь расширение Для просмотра ссылки Войди или Зарегистрируйся (профилирование PHP). Примечательно, что поставить его можно только на *nix системы. Его установка (если самостоятельно:(
pecl download xhprof-0.9.2
tar -xvf xhprof-0.9.2.tar.gz
cd xhprof-0.9.2/extension
phpize
./configure
make
make install
Дальше включите расширение в php.ini:
extension=xhprof.so
xhprof.output_dir=/var/log/xhprof;
Если сайт находится на хостинге - просто попросите хостеров включить XHProf :)
Следующим этапом вам надо создать отдельный домен для этого расширения. Например, локально я обычно называю его dev.xhprof (хотя можно и blabla.biz). Далее в директорию с доменом копируйте папки xhprof_html и xhprof_lib из файлов расширения. После этого перейдите на страницу с настройками devel'a и включите профилирование:
Для просмотра ссылки Войди или Зарегистрируйся
Этот скриншот сделан с рабочего хостинга.
  • XHProf directory - путь к корню сайта в файловой системе сервера
  • XHProf URL - урл сайта, по которому доступна папка xhprof_html
Теперь на страницах сайта в строке с общей информацией devel'a прявилась ссылка на профилирование PHP:
Для просмотра ссылки Войди или Зарегистрируйся
После нажатия на ссылку перед вами развернётся таблица с вызванными функциями, количеством времени, памяти и процессорного времени, затраченого на их выполнение:
Для просмотра ссылки Войди или Зарегистрируйся
Сокращения:
  • Incl[usive] - ресурсы, потраченные на выполнение фунцкии со всеми функциями, вызванными из неё
  • Excl[usive] - ресурсы, потраченные на выполнение непосредственно данной функции
После нажатия в таблице на Excl. Wall Time (microsec) данные отсортируются по убыванию, показав мне функцию, которая выполнялась дольше всего:
Для просмотра ссылки Войди или Зарегистрируйся
Как вы видите, дольше всего выполнялась фунцкия path_breadcrumbs_page_alter() - на её выполнение было потрачено 4,3 секунды - просто непозволительно долго. Нажимаем на название этой функции и смотрим, что же в ней ест столько времени и памяти:
Для просмотра ссылки Войди или Зарегистрируйся
Очевидно, что пакостит функция count(), которая вызывается 2 миллиона раз и потратив на себя кучу времени. А array_fill() на 2млн элементов съел около 256 миллионов байт памяти (~244 mb). Открываем код функции path_breadcrumbs_page_alter() и смотрим:
function path_breadcrumbs_page_alter(&$page) {

$a = array_fill(0, 2000000, 'пиу');
for ($i = 0; $i < count($a); $i++) {
// Мне очень стыдно ...
}

// Остальной код.
}
После нахождения косяка в производительности устраняем её и наслаждаемся быстродействующим сайтом.
P.S. В следующей статье я расскажу о том, как проанализировать производительность и ускорить клиентскую часть сайта.

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


у меня разница почти в 3 раза составила

время загрузки с 12 секунд до 2-3 уменьшило.


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

нагрузку во время тестирования полезно проводить с пом. утилиты ab, котор. поставляется в комплекте с Apache:
ab -n 500
где 500 - число запросов, т.е. сколько раз страница запрошена.
Если кол-во запросов одновременно, то дописать:
-c 1000
Можно дописать какой-нить файл, localhost:8080/hdd/1.jpg
 
Леони, есть хостинги "заточенные" специально под друпал вроде айти патрола
 
Назад
Сверху