abody
Постоялец
- Регистрация
- 14 Сен 2006
- Сообщения
- 251
- Реакции
- 168
- Автор темы
- #1
Немного воды
Что делать, если сайт дохнет прямо на глазах? С чего начать, если вам подсунули полуживой проект с просьбой поднять его на ноги? Ответ выглядит немного по-капитански: анализ. Вам надо понять, где именно закралась проблема в производительности, которая мешает быстрой работе сайта. Сразу хочу сказать, что в этой статье я буду принимать на веру, что вы выбрали правильный хостинг, и проблема заключается не в нём. Безусловно, многие проблемы с производительностью на сервере можно решить докупив ещё железа, однако не каждый заказчик готов платить за это (хотя по подсчётам, докупить железа обойдётся гораздо дешевле, чем тратиться на специалиста по производительности, но кому это объяснишь
). Однако если же косяк с производительностью серьёзный - то он может съесть ресурсы даже докупленного железа, и тогда на вас очень обидятся. А если проблема окажется в клиентской части сайта - то хоть дата-центры скупайте, а у клиентов сайты будут тормозить.
Вступление
Сайт разделяется на 2 части - клиентская и серверная. К клиентской части относится всё, что скачивает браузер клиента (js, css, изображения, html). К серверной - всё, что от клиента спрятано (в основном это php код, включающий запросы к базе данных).
Первым делом надо посмотреть где тормозит сайт - на клиентской или серверной его части. В этом мне помогает Для просмотра ссылки Войдиили Зарегистрируйся (плагин Firefox). Открываем его на вкладке СЕТЬ и перезагружаем страницу.
Для просмотра ссылки Войдиили Зарегистрируйся
На первой строчке вы увидите время, которое потратил браузер на ожидание ответа от сервера (3,97 секунд - это непозволительно огромное время ожидания ответа от сервера). За это время поизошло следующее:
Исходя из скриншоты видно, что проблема медленной загрузки страницы находится где-то на сервере. Это значит, что у нас либо тяжёлые запросы к базе данных, либо плохо написанный код. Для дальнейшего анализа необходимо поставить модуль Для просмотра ссылки Войдиили Зарегистрируйся. Из коробки он умеет отслеживать запросы к базе данных. На странице /admin/config/development/devel включите отслеживание запросов к базе данных:
Для просмотра ссылки Войдиили Зарегистрируйся
На скриншоте внизу располагается секция XHProf - о ней мы обязательно поговорим чуть позже.
Итак, после включения вывода запросов внизу каждой страницы будет выводиться список всех запросов к бд (в настройках я их отсортировал по убыванию времени выполнения
Для просмотра ссылки Войдиили Зарегистрируйся
На скриншоте видно, что пару запросов несколько превышают желаемый лимит времени на запрос в 5 милисекунд. Однако чётко видно, что все запросы выполнились за 196 милисекунд (0,196 секунд), а это вполне неплохо => следовательно, проблема не в запросах. Если бы проблема была в них, можно было бы воспользоваться дополнительными опциями (пункт 3
или Зарегистрируйся (профилирование 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 и включите профилирование:
Для просмотра ссылки Войдиили Зарегистрируйся
Этот скриншот сделан с рабочего хостинга.
Для просмотра ссылки Войдиили Зарегистрируйся
После нажатия на ссылку перед вами развернётся таблица с вызванными функциями, количеством времени, памяти и процессорного времени, затраченого на их выполнение:
Для просмотра ссылки Войдиили Зарегистрируйся
Сокращения:
Для просмотра ссылки Войдиили Зарегистрируйся
Как вы видите, дольше всего выполнялась фунцкия 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. В следующей статье я расскажу о том, как проанализировать производительность и ускорить клиентскую часть сайта.
источник
Что делать, если сайт дохнет прямо на глазах? С чего начать, если вам подсунули полуживой проект с просьбой поднять его на ноги? Ответ выглядит немного по-капитански: анализ. Вам надо понять, где именно закралась проблема в производительности, которая мешает быстрой работе сайта. Сразу хочу сказать, что в этой статье я буду принимать на веру, что вы выбрали правильный хостинг, и проблема заключается не в нём. Безусловно, многие проблемы с производительностью на сервере можно решить докупив ещё железа, однако не каждый заказчик готов платить за это (хотя по подсчётам, докупить железа обойдётся гораздо дешевле, чем тратиться на специалиста по производительности, но кому это объяснишь
). Однако если же косяк с производительностью серьёзный - то он может съесть ресурсы даже докупленного железа, и тогда на вас очень обидятся. А если проблема окажется в клиентской части сайта - то хоть дата-центры скупайте, а у клиентов сайты будут тормозить.Вступление
Сайт разделяется на 2 части - клиентская и серверная. К клиентской части относится всё, что скачивает браузер клиента (js, css, изображения, html). К серверной - всё, что от клиента спрятано (в основном это php код, включающий запросы к базе данных).
Первым делом надо посмотреть где тормозит сайт - на клиентской или серверной его части. В этом мне помогает Для просмотра ссылки Войди
Для просмотра ссылки Войди
На первой строчке вы увидите время, которое потратил браузер на ожидание ответа от сервера (3,97 секунд - это непозволительно огромное время ожидания ответа от сервера). За это время поизошло следующее:
- Браузер послал запрос к серверу на получение страницы
- Друпал произвёл полный бутстрап
- На серверной стороне выполнились все запросы к базе данных, необходимые для получения страницы
- Был отрендерен весь контент, полученный из базы данных
- Браузер получил ответ от сервера в виде сформированного html кода
Исходя из скриншоты видно, что проблема медленной загрузки страницы находится где-то на сервере. Это значит, что у нас либо тяжёлые запросы к базе данных, либо плохо написанный код. Для дальнейшего анализа необходимо поставить модуль Для просмотра ссылки Войди
Для просмотра ссылки Войди
На скриншоте внизу располагается секция XHProf - о ней мы обязательно поговорим чуть позже.
Итак, после включения вывода запросов внизу каждой страницы будет выводиться список всех запросов к бд (в настройках я их отсортировал по убыванию времени выполнения
Для просмотра ссылки Войди
На скриншоте видно, что пару запросов несколько превышают желаемый лимит времени на запрос в 5 милисекунд. Однако чётко видно, что все запросы выполнились за 196 милисекунд (0,196 секунд), а это вполне неплохо => следовательно, проблема не в запросах. Если бы проблема была в них, можно было бы воспользоваться дополнительными опциями (пункт 3
- P - Placeholders, показывает запрос с заменителями переменных (как они есть на скриншоте)
- A - Arguments, показывает аргументы запроса вместо placeholder'ов
- E - Для просмотра ссылки Войди
или Зарегистрируйся
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
Для просмотра ссылки Войди
После нажатия на ссылку перед вами развернётся таблица с вызванными функциями, количеством времени, памяти и процессорного времени, затраченого на их выполнение:
Для просмотра ссылки Войди
Сокращения:
- Incl[usive] - ресурсы, потраченные на выполнение фунцкии со всеми функциями, вызванными из неё
- Excl[usive] - ресурсы, потраченные на выполнение непосредственно данной функции
Для просмотра ссылки Войди
Как вы видите, дольше всего выполнялась фунцкия 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. В следующей статье я расскажу о том, как проанализировать производительность и ускорить клиентскую часть сайта.
источник
Для просмотра скрытого содержимого вы должны войти или зарегистрироваться.
