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

Тема в разделе "Drupal", создана пользователем abody, 12 авг 2012.

Информация :
Прежде чем создать новую тему внимательно ознакомьтесь с правилами раздела
Модераторы: DMS
  1. abody

    abody

    Регистр.:
    14 сен 2006
    Сообщения:
    239
    Симпатии:
    153
    Немного воды

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

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

    Исходя из скриншоты видно, что проблема медленной загрузки страницы находится где-то на сервере. Это значит, что у нас либо тяжёлые запросы к базе данных, либо плохо написанный код. Для дальнейшего анализа необходимо поставить модуль devel. Из коробки он умеет отслеживать запросы к базе данных. На странице /admin/config/development/devel включите отслеживание запросов к базе данных:
    [​IMG]
    На скриншоте внизу располагается секция XHProf - о ней мы обязательно поговорим чуть позже.
    Итак, после включения вывода запросов внизу каждой страницы будет выводиться список всех запросов к бд (в настройках я их отсортировал по убыванию времени выполнения:(
    [​IMG]
    На скриншоте видно, что пару запросов несколько превышают желаемый лимит времени на запрос в 5 милисекунд. Однако чётко видно, что все запросы выполнились за 196 милисекунд (0,196 секунд), а это вполне неплохо => следовательно, проблема не в запросах. Если бы проблема была в них, можно было бы воспользоваться дополнительными опциями (пункт 3:(
    • P - Placeholders, показывает запрос с заменителями переменных (как они есть на скриншоте)
    • A - Arguments, показывает аргументы запроса вместо placeholder'ов
    • E - Explain
    Также на скриншоте можно заметить (пункт 2), что в какой-то момент PHP потребовалось 189 мб оперативки - а вот это уже много. Теперь было бы неплохо пробежаться по функциям и посмотреть в какой момент потребовалось столько памяти. С этим нам может помочь расширение XHProf (профилирование 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 и включите профилирование:
    [​IMG]
    Этот скриншот сделан с рабочего хостинга.
    • XHProf directory - путь к корню сайта в файловой системе сервера
    • XHProf URL - урл сайта, по которому доступна папка xhprof_html
    Теперь на страницах сайта в строке с общей информацией devel'a прявилась ссылка на профилирование PHP:
    [​IMG]
    После нажатия на ссылку перед вами развернётся таблица с вызванными функциями, количеством времени, памяти и процессорного времени, затраченого на их выполнение:
    [​IMG]
    Сокращения:
    • Incl[usive] - ресурсы, потраченные на выполнение фунцкии со всеми функциями, вызванными из неё
    • Excl[usive] - ресурсы, потраченные на выполнение непосредственно данной функции
    После нажатия в таблице на Excl. Wall Time (microsec) данные отсортируются по убыванию, показав мне функцию, которая выполнялась дольше всего:
    [​IMG]
    Как вы видите, дольше всего выполнялась фунцкия path_breadcrumbs_page_alter() - на её выполнение было потрачено 4,3 секунды - просто непозволительно долго. Нажимаем на название этой функции и смотрим, что же в ней ест столько времени и памяти:
    [​IMG]
    Очевидно, что пакостит функция 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. В следующей статье я расскажу о том, как проанализировать производительность и ускорить клиентскую часть сайта.

    источник
     
    vladis1333, WalpeR и votren нравится это.
  2. rezakS

    rezakS Постоялец

    Регистр.:
    9 янв 2008
    Сообщения:
    119
    Симпатии:
    51
    всем советую если сайт на друпале тормозит переехать на специальный хостинг для друпала.


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

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


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

    Leony

    Регистр.:
    18 мар 2008
    Сообщения:
    153
    Симпатии:
    25
    А что это за "специальный хостинг", если не секрет?

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

    marvinz

    Регистр.:
    7 апр 2009
    Сообщения:
    158
    Симпатии:
    74
    Леони, есть хостинги "заточенные" специально под друпал вроде айти патрола