Профилирование PHP-кода
Рано или поздно каждый из нас сталкивается с унаследованным кодом и его оптимизацией. Дебаггер и профилировшик в такой ситуации - лучшие помощники программиста. У тех кто работает с PHP, благодаря Дерику Ретансу (Derick Rethans) есть хороший инструмент - xDebug. Информации касательно xDebug много даже в рунете, поэтому речь в этой статье пойдет не о нем.
Наткнувшись на упоминание о профилировщике для PHP я сразу подумал об xDebug (о проприетарных инструментах от Zend я давно уже успел позабыть), но на этот раз ошибся - речь пойдет об XHProf.
XHProf
Этот профилировшик был разработан специально для Facebook, а исходный код его был открыт в марте 2009 года.
Установка прошла достаточно быстро и гладко.
wget pecl.php.net/get/xhprof-0.9.2.tgz
tar xvf xhprof-0.9.2.tgz
cd xhprof-0.9.2/extension/
phpize
./configure && make && make install
cd /usr/local/etc/php.d/
vim xhprof.ini
cd /usr/local/
vim header.php
vim footer.php
vim etc/php.ini
/etc/init.d/php-fpm restart
cp vhost.conf.template prof.my.conf
sed -i s/site/prof/ prof.my.conf
vim prof.my.conf
/etc/init.d/nginx restart
Разберем упомянутые конфиги
Xhprof.ini
extension=/usr/local/lib/php/extensions/no-debug-non-zts-20090626/xhprof.so
xhprof.output_dir="/home/max/www/profile/"
Prof.my.conf - конфиг нгинкса - самый стандартный.
Server {
listen 80;
server_name prof.my;
charset utf8;
Root /usr/local/src/xhprof-0.9.2/xhprof_html ;
location / {
index index.php;
}
Location ~ \.php$ {
fastcgi_pass 127.0.0.1:12000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /usr/local/src/xhprof-0.9.2/xhprof_html/$fastcgi_script_name;
include fastcgi_params;
В /usr/local/src/xhprof-0.9.2/xhprof_html лежат PHP-исходники, создающие неплохой WEBGUI к профайлеру.
Итак о двух главных файлах:
Header.php
include_once "/usr/local/src/xhprof-0.9.2/xhprof_lib/utils/xhprof_lib.php";
include_once "/usr/local/src/xhprof-0.9.2/xhprof_lib/utils/xhprof_runs.php";
xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);
}
}
Footer.php
if(isset($_COOKIE["xhprof"])){
if (extension_loaded("xhprof")) {
$profiler_namespace = "myapp"; // namespace for your application
$xhprof_data = xhprof_disable();
$xhprof_runs = new XHProfRuns_Default();
$run_id = $xhprof_runs->save_run($xhprof_data, $profiler_namespace);
// url to the XHProf UI libraries (change the host name and path)
$profiler_url = sprintf("http://prof.my/index.php?run=%s&source=%s", $run_id, $profiler_namespace);
echo <<
OUT;
}
}
Теперь запускаем любой PHP-скрипт через веб и видим в левом верхнем углу ссылку на вывод профилировщика - именно для этого и был создан хост prof.my
Обратите внимание - я использую проверку на COOKIE! При такой проверке можно безопасно использовать профилировщик на production-сервере - на реальных данных и реальной загрузке.
Веб-интерфейс профилировщика выводит таблички с информацией о каждой функции и сообщает следующую информацию:
Есть возможность сортировки таблицы по любому из параметров
Информация по каждой функции делится еще на два вида Inclusive и Exclusive. Inclusive включает цифры использованные дочерними вызовами, а Exclusive не включает их. Так же есть возможность, кликнув на название функции увидеть информацию только по ней и функциям из которых она вызывалась и которые вызывались ей.
Если в системе установлен GraphViz, профилировщик нарисует вам граф вызовов.
P.S. Не нарушая традиций: это мой первый пост на хабре.
UPD: перепостил в PHP.
Рассказывалось о том, как установить и настроить xdebug, описывались некоторые простейшие возможности, такие как улучшение вывода функции var_dump() или вывод трассировки стека вызовов при получении сообщения об ошибке. Во второй части мы рассмотрели такую возможность xdebug как трассировку. Трассировка содержит все вызовы функций и методов в программе, время запуска, опционально размер памяти, передаваемые и возвращаемые параметры. Лог трассировки может помочь вам понять пути выполнения сложной программы. Вместо того чтобы вставлять отладочный код внутрь программы, вы включаете или выключаете трассировку в тем места где нужно, а потом используете утилиты подобные grep или собственно написанные приложения на PHP для анализа лог файла.
В данной статье мы рассмотрим профайлинг. Профайлинг с первого взгляда похож на трассировку. Профайлинг-лог не предназначет для людей, не предназначен для визуализации потока выполнения программы, однако он обеспечивает нас данными для статистического анализа запущенной программы.
Создания профайлинг-лога
Ниже короткая выдержка из профайлинг-лога, созданного xdebug:
fl=php:internal
fn=php::define
106 3Fl=C:\www\drupal\includes\bootstrap.inc
fn=require_once::C:\www\drupal\includes\bootstrap.inc
1 648
cfn=php::define
calls=1 0 0
13 6
cfn=php::define
calls=1 0 0
18 4
cfn=php::define
calls=1 0 0
23 2
xdebug.profiler_output_dir=«c:\traces»
xdebug.profiler_enable_trigger=On
Название профайлинг-лога
Имя, которое по умолчания xdebug присваивает профайлинг-логу «cachegrind.out.» плюч идентификатор процесса. Также как и в случае лога трассировки можно изменить названия лога, добавляя в php.ini соответствующие настройки. Название параметра xdebug.profiler_output_name. Аргументом является строка. которая может содержать различные модификаторы. Самые важные ниже:
Анализ профайлинг-лога
Как уже говорилось выше, для анализа профайлинг-лога необходимы дополнительные программы для визуализации данных. Все профайлинг-логи, которые создает xdebug, находятся в формате похожем на Cachegrind-формат. Cachegrind это профайлер, который является частью более мощной программы под названием Valgrind , программы для отладки и профайлинга программного обеспечения для Linux. Cachegrind был предназначен для анализа статистик кэшей, использования памяти и команд программы. Другой инструмент программы Valgrind, Callgrind рисует графы вызовов. В отношении PHP, мы можем использовать это приложение для визуализации и анализа профайлинг-лога.
Инструмент, который обычно используется для анализа профайлинг-лога, созданного xdebug, называется . KCachegrind – это свободное программное обеспечение доступное по лицензии GPL (работает только на Unix-системах). Однако, есть простенькая программка и для Windows - , которая также бесплатна. Давайте рассмотрим сначала Windows-версию.
WinCacheGrind: анализ профайлинг-логов в Windows
Текущая версия (на момент написания автором данной статьи) WinCachegrind - 1.0.0.12. Эта версия датирована далеким 2005, что говорит о том, что WinCachegrind давно не разрабатывается. Если посмотреть на примечания к релизу release notes, авторы пишут, что в программе есть ошибки, которые иногда делают ее поведение странным.
Поэтому я рекомендую использовать KCachegrind, запущенной на основе виртуальной машигы на последнем дистрибутиве Линукса, например Ubuntu (примечание переводчика, вообще говоря странная рекомендация, я бы рекомендовал в этом случае просто поставить линукс, а не городить огород виртуальных машин). Существует огромное количество виртуальных машин, доступных под Windows. Если не возможно использовать Unix или виртуальную машину по каким-либо причинам, вы можете продолжать использовать WinCachegrind для простого анализа профайлинг-лога. WinCachegrind не рисует графы вызовов в отличие от KCachegrind.
Установка Wincachegrind чрезвычайно проста. Запустите установщик, нажмите на кнопочку согласиться с лицензией и установка завершена. Теперь вы можете запустить программу, открыть в ней один из cachegrind профайлинг-логов, созданных xdebug.
Кликая на часики или иконку сигмы, вы можете переключаться между выводом информации в абсолютных значениях и процентах. Процентное отображение показывает, сколько времени в процентах от общего времени занимает вызов функции в данном блоке.
Две полезные настройки Profiler -> Hide Fast Functions и Profiler -> Hide Library Functions. Первый переключатель скрывает функции, временной вклад которых в общее время выполнения программы незначителен.
Вторая настройка, Profiler -> Hide Library Functions скрывает из общего анализа встроенные в PHP функции. Когда включены обе эти настройки, вы видите меньше данных, вследствие чего можно сфокусироваться на тех участках кода, которые требуют оптимизации.
Главное окно содержит две вкладки: Line by line и Overall. Обе вкладки показывают одинаковую информацию, однако вкладка Overall агрегирует информацию для лучшенго представления. Self time отображает время запуска кода в текущем блоке, в то время как Cumulative time (Cum.) показывает общее время запуска функций в данном блоке.
KCacheGrind: анализ профайлинг-логов в Unix
Unix версия KCachegrind предоставляет больше функциональности, чем WinCachegrind. KCachegrind визуализирует данные и строит граф вызовов.
Для начала использования необходимо установить KCachegrind. Текущая версия . Более новая версия (0.10.1) доступна, однакак она является частью пакета Valgrind.
Если выозможно используйте менеджер пакетов для установки пакета KCachegrind. KCachegrind использует GraphViz для рисования графов вызова, поэтому необходимо также установить пакет GraphViz, если ваш менеджер пакетов автоматически не устанавливает зависимые пакеты.
Если вы не нашли бинарный пакет KCachegrind, необходимо скомпилировать KCachegrind самостоятельно. После загрузки исходников, запустите
./configure --prefix=/opt/kde3
make
make install
Как вы можете видеть, большая часть времени запуска прошла внутри common.inc.php. Следующий скриншот показывает визуализацию вызовов функций внутри common.inc.php:
В этом блоке кода запускаются два require_once, которые составляют половину времени запуска common.inc.php. Кликнув дважды на любой прямоугольник, вы опуститесь глубже в анализ данных.
Оптимизация кода на основании данных профайлинга
Всегда профилируйте ваши приложения до начала оптимизации. Вы можете сами начать оптимизацию, в том месте, где вам кажется, что эта оптимизация принесет эффект, однако это не всегда верно. Оптимизация, главным образом, имеет эффект лишь в тех частях, которые занимают, больше всего времени в процессе выполнения.
Если запускается множество копий программы одновременно, все равно может возникнуть необходимость оптимизации той части вашей программы, которая занимает большую часть времени выполнения. В этом случае оптимизация не сделает обслуживание одного индивидуального запроса быстрее, но позволит вашему серверу выдерживать высокую нагрузку, потребляя меньше ресурсов для обслуживания подобные запросы.
Когда вы смотрите на продолжительность запуска по данным профайлера, имейте ввиду, что абсолютные значения мене важны, чем относительные. Измеренные на разных системах, абсолютные значения могут быть различными. Однако до того как приступить к оптимизации кода, рассмотрите следующие вещи.
Важное правило в оптимизации – сокращение количества операций ввода/вывода. Некоторые операции ввода/вывода требуют очень много времени по сравнению с вычислениями. Уменьшение таких операций может быть очень эффективным путем ускорения вашей программы. Удаление одного вызова I/O может дать более эффективное улучшение, чем куча часов оптимизации кода. Поэтому вы должны сфокусироваться вначале на операциях I/O до того как вы приступите к коду.
Также перед оптимизацией вы можете увеличить количество ваших серверов. Вы можете купить огромный, что позволит вам ненамного увеличить производительность. Время разработки более дорогое, чем цена нового сервера. И если вы увеличите количество железа, вы можете быть уверены, что вы получите увеличение сразу же без какого-либо воздействия на PHP код. Когда разработчик проводит один или два дня над оптимизацией код, вы никогда не скажете, на сколько увеличится производительность. И в конце концов, вы уже не можете быть уверены в том, что оптимизация не принесет никаких ошибок.
Преобразование некоторых страниц в статические – это один из путей достичь большей производительности. Допустим, есть сайт с большим трафиком, где PHP скрипт на каждый запрос создает первую страницу, выбирая информацию из базы данных или XML-файла. Если данные на странице изменяются достаточно часто, то вы можете пересоздавать ее статическую копию. Если преобразование в статический вид для страницы не возможно (на странице выводится какая-то персональная информация), вы можете преобразовывать в статику некоторые блоки.
Другой уровень оптимизации не требует изменения кода PHP. Как мы знаем PHP это интерпретируемый язык. Это значит, что его команды транслируются во время выполнения в промежуточный код. Трансляция повторяется каждый раз, когда запускается скрипт. Это делает PHP медленнее по сравнению с такими языками как C или Java, которые не требуют разбора код каждый раз при запуске. Для PHP, вы можете использовать кэши промежуточного представления (смотри мой перевод ….) для сохранения и повторного использования промежуточного кода, это делает запуск и выполнение быстрее.
Все это не говорит о том, что не время и не место оптимизировать PHP-код. Некоторые оптимизации кода могут очень сильно увеличить производительность. Однако всегда помните, что изменение кода всегда несет риск внесения дополнительных ошибок и проблем безопасности. Также не забывайте, что оптимизация кода делает его менее читаемым.
Заключение
Создание и визуализация профайлинг-лога это одна из важных условий для оптимизации PHP-кода. Вы должны знать, какие места в программе требуют больше всего времени, и именно там начать оптимизацию.
В следующей статье мы рассмотрим отладку, используя xdebug. xdebug может предоставить вам возможность для удаленной отладки. Используя клиент, в котором реализована такая возможность, например Eclipse PDT, вы можете производить отладку вашего кода, не изменяя его, устанавливать breakpoints, перескакивать через участки кода, смотреть, как и где переменные изменяют значения.
Профилирование приложения — это сбор данных о скорости выполнения различных участков программы (файлов и функций). Существует множество инструментов профилирования PHP, но не все инструменты подходят для проведения анализа прямо в продакшне.
XHProf — мега простой профайлер, который собирает статистику прямо во время работы приложения почти без оверхеда .
Если приложение начинает работать медленно, профилирование поможет узнать, какая именно часть тупит. Результат профилирования — это обычно список выполненных функций и времени их исполнения.
Профилирование стоит делать до любой оптимизации приложения. В противном случае — будете руководствоваться догадками. Скорее всего неправильными.
Xdebug — мощное решение для PHP. Но сама платформа Xdebug настолько тяжелая, что ее нельзя использовать на работающих сайтах
. XDebug создает значительную нагрузку на ресурсы сервера и замедляет приложение.
С другой стороны, проблемы на "живом" сайте могут быть совершенно не такими, как в среде разработчика. Профилирование только на компьютерах разработчиков будет показывать лишь часть проблем.
Именно поэтому и было разработано решение XHprof . Оно предназначено для применения в работающих приложениях. Основная идея этого профайлера — создавать минимум нагрузки на приложение при этом собирать все необходимые данные о скорости работы. Решение разработано ребятами из Facebook и поддерживается новыми версиями PHP .
На Debian XHprof есть в sid пакетах, поэтому: apt-get install xhprof
Вы также можете собрать XHprof самостоятельно.
Пусть у нас есть скрипт с таким кодом:
function execute() { # Какой-то PHP код } execute();
Проведем профилирование с помощью XHprof. Для этого на этой странице необходимо:
Это будет выглядеть так:
function execute() { # Какой-то PHP код } # Инициализируем профайлер xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY); # Выполняем программу после включения профайлера execute(); # Останавливаем профайлер после выполнения программы $xhprof_data = xhprof_disable();
# Сохраняем результат профилирования в переменную $xhprof_data
Собранные данные можно проанализировать в интерфейсе XHprof для построения отчетов. Для этого, необходимо скачать исходники XHprof : cd /var/www; wget http://pecl.php.net/get/xhprof-0.9.4.tgz gzip -d xhprof-0.9.4.tgz tar -xvf xhprof-0.9.4.tar
После этого необходимо внести изменения в скрипт:
... $xhprof_data = xhprof_disable(); include_once "/var/www/xhprof-0.9.4/xhprof_lib/utils/xhprof_lib.php"; include_once "/var/www/xhprof-0.9.4/xhprof_lib/utils/xhprof_runs.php"; $xhprof_runs = new XHProfRuns_Default(); $run_id = $xhprof_runs->save_run($xhprof_data, "test");
# Новый код сохраняет отчет для использования в графическом интерфейсе
Чтобы увидеть отчет, необходимо настроить виртуальный хост на папку /var/www/xhprof-0.9.4/xhprof_html. Например, в Nginx:
Server { server_name xh..9.4/xhprof_html; index index.php; location ~* \.(php)$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } } nginx -s reload
После этого появится список отчетов:
Таблица содержит список функций, которые были выполнены в рамках одной страницы с дополнительной информацией:
Чтобы построить графический отчет, убедитесь, что у Вас установлен graphviz: apt-get install graphviz
Ресурсоемкие участки кода выделены желтым (средние) и красным (самые тяжелые). Это те участки кода, которые используют множество ресурсов относительно всей остальной программы. Это может быть одна медленная функция или большое количество вызовов быстрой функции. В нашем примере функция str_replace() помечена красным из-за 262 вызовов.
Интерфейс XHprof также позволяет просматривать агрегатную информацию сразу с нескольких отчетов. Для этого run_id передаются через запятую: http://xh..php?run=53a894f6d5d9b,53a894fcf126e &source=test
Используйте XHprof для профилирования PHP прямо в продакшне.
С помощью систем для профилирования можно собрать информацию о том, какие функции в php-коде потребляют больше процессорного времени и оперативной памяти, то есть выявить наиболее медленные и требовательные к памяти места в программе на php.
XHProf - PHP profiler разработанный в Facebook.
Установка:
Aptitude install php-pear pecl install xhprof-0.9.4 echo "extension=xhprof.so" > /etc/php5/mods-available/xhprof.ini ln -s /etc/php5/mods-available/xhprof.ini /etc/php5/conf.d/xhprof.ini apachectl restart
Необходимые для работы файлы расположены в директории /usr/share/php . Однако не все, а только c php-кодом. Для нормального отображения отчетов требуется jquery и css. Их можно заполучить из репозитория на github:
Git clone https://github.com/facebook/xhprof.git
После этого в код php-скрипта в месте, откуда должен начаться сбор данных добавляем строку:
Xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);
В скобках указаны параметры для сбора данных. В данном случае будет осуществляться сбор данных по нагрузке на процессор и по использованию оперативной памяти. Возможен еще один параметр XHPROF_FLAGS_NO_BUILTINS при использовании которого данные по встроенным функциям не собираются.
$xhprof_data = xhprof_disable(); include_once "xhprof_lib/utils/xhprof_lib.php"; include_once "xhprof_lib/utils/xhprof_runs.php"; $xhprof_runs = new XHProfRuns_Default(); $run_id = $xhprof_runs->save_run($xhprof_data, "xhprof_test"); echo "Report: http://domain.tld/xhprof_html/index.php?run=$run_id&source=xhprof_test"; echo "\n";
В строке $run_id в кавычках указано название профиля, которое можно задать произвольно.
Результат в обработанном виде выглядит следующим образом:
Если указать параметр XHPROF_FLAGS_NO_BUILTINS , то видно, что количество вызовов функций значительно снижается:
В таблице представлена следующая информация:
Calls
- количество вызовов функции,
Wall Time
- общее время работы функции вклчая время ожидания ответа от внешних ресурсов,
CPU
- сколько времени было затарчено на обработку функций,
MemUse
- сколько оперативной памяти было задействовано,
PeakMemUse
- пиковое потребление памяти.
В качестве модификаторов выступают:
Incl
- inclusive - с учетом вызовов других функций из этой функции,
Excl
- exclusive - без учета вызовов функций.
Кроме того, над таблицей представлена информация о суммарных времени обработки, использованной памяти и количестве вызовов функций.
Также XHProf позволяет строить разностные отчеты между двумя запусками, которые обозначаются красным и зеленым цветами. С помощью таких отчетов можно получить ясную картину улучшений после каждого изменения кода.
Для получения подобного отчета нужно воспользоваться ссылкой вида:
http://domain.tld/xhprof_html/index.php?run1=run_id1&run2=run_id2&source=xhprof_test
где run_id1 и run_id2 - идентификаторы запусков.
Если установить Graphviz :
Aptitude install graphviz
Также для php profiler xhprof существуют сторонние веб-интерфейсы использующие базы данных:
xDebug - дебаггер PHP-кода с возможностью профилирования (profiling), написанный Дериком Ретансом (Derick Rethans).
Установка:
Yum install php5-xdebug
Затем редактируем конфиг:
Nano /etc/php5/mods-available/xdebug.ini
добавляя в него строки:
Xdebug.profiler_enable = 1 xdebug.profiler_aggregate = On xdebug.profiler_output_dir = /tmp
Здесь включаем PHP профайлер и указываем директорию в которую складывать профили. Профили создаются с именами вида cachegrind.out.*
Существует веб-клиент webgrind: https://github.com/jokkedk/webgrind . Работает он не слишком быстро, но позволяет оперативно просмотреть небольшие профили. Фактически это код на PHP, который нужно склонировать с github:
Git clone https://github.com/jokkedk/webgrind.git
создастся директория webgrind , которую нужно скопировать в директорию любого сайта и обратиться к ней из браузера. Далее, чтобы в Debian заработало построение графиков в конфигурационном файле config.php нужно поправить путь до исполняемого файла graphviz . Должно получиться так:
Static $dotExecutable = "/usr/bin/dot";
Кроме того, можно подправить часовой пояс:
Static $defaultTimezone = "Europe/Moscow";
В заголовке можно выбрать профиль и поставить галочку учитывать ли встроенные функции. В самой таблице видны функции, количество вызовов, время работы самой функции и время с учетом ожидания. Чтобы углубиться в функции достаточно щелкнуть по треугольной стрелочке. В моем случае при достаточно объемных профилях (от нескольких мегабайт), ожидание результата было излишне большим. Вероятно, для достаточно крупных профилей лучше использовать локальные программы просмора.
График может выглядеть следующим образом:
Обратите внимание, что webgrind не стоит использовать на производственных серверах, так как какая-либо авторизация не предусмотрена, но при этом есть доступ к коду файлов на php. В случае необходимости используйте хотя бы базовую авторизацию Apache.
Также существуют программы для анализа профилей как под Linux:
Данные профиля могут помочь вам улучшить ваше приложение, то есть достичь определенных целей, к примеру, понизить потребление памяти, уменьшить время генерации страницы и так далее.
Информация в профиле является стартовой точкой в оптимизации: сообщается сколько времени генерируется результат, сколько памяти используется и сколько вызовов функций происходит. С помощью более подробных данных вы можете улучшить эти показатели.
К примеру, если вы используете фреймворк, то использование некоторых функций фреймворка может вести к вызову нескольких базовых функций. Если вы читаете некоторые данные несколько раз, то, возможно, стоит сохранить результат в переменную.
Также профайлер может помочь понять где стоит использовать кэширование PHP-кода, к примеру, с помощью APCu или memcached .
Прежде всего, стоит оптимизировать функции, который требуют больше всего времени на исполнение. После того, как все оптимизировано и кажется, что улучшать больше нечего, стоит отсортировать функции по количеству вызовов и поработать над его понижением. Даже если PHP работает быстро, то стоит подумать, нужно ли вызывать функции так часто?
При обнаружении следующих ситуаций стоит подумать о кэшировании:
Не стоит кэшировать все подряд, так как память тоже ценный ресурс. Кэшируйте те данные, к которым обращаетесь постоянно. Также кэширование имеет мало смысла в случае если кэширование тратит больше ресурсов, чем экономит.
Кроме кэширования в коде не стоит забывать о кэшировании с помощью веб-сервера (), а также на стороне клиента. Если использовать правильные заголовки, то многие запросы могут быть разрешены еще до поступления на сервер.
Установка xhprof для php:
Sudo apt-get install php5-xhprof
Перезапускаем Apache:
Sudo service apache2 restart
Распечатываем phpinfo(); и проверяем подключился модуль или нет?
Проверяем /etc/php5/apache2/conf.d появилась ли там ссылка на конфиг xhprof.ini.
Если нет, то создаем линку сами и перезапускаем apache.
Sudo ln -s /etc/php5/mods-available/xhprof.ini /etc/php5/apache2/conf.d/20-xhprof.ini sudo service apache2 restart
Проверяем подключение xhprof, проверяем подключен ли 20-xhprof.ini:
На скрине указана версия 0.9.2, хотя при инсталяции отобразилась версия 0.9.4, но это нам не помеха.
Теперь можем профилировать наш код.
Функция xhprof_enable() принимает в качестве аргументов флаги:
XHPROF_FLAGS_CPU для фиксирования статистики процессора,
XHPROF_FLAGS_MEMORY - для памяти,
XHPROF_FLAGS_NO_BUILTINS - для игнорирования встроенных функций.
Для сохранения и дальнейшего разбора полетов, нам необходимо установить инструмент для анализа профайла.
Скачиваем архив с инструментом анализа со страницы xhprof: , берем версию 0.9.4.
У на сервере или локальном ПК создаем папку доступную через localhost или отдельный домен, в который разархивируем скачанный архив:
Теперь мы можем сохранять профайл.
Https://xn--d1acnqm.xn--j1amh/altadmin/posts/edit/188
Код для отслеживания выглядит примерно так:
// Инициализируем профайлер - будем считать и процессорное время и потребление памяти
xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);
// Профилируемый код
# Останавливаем профайлер
$xhprof_data = xhprof_disable();
# Сохраняем отчет и генерируем ссылку для его просмотра
include_once "/var/www/html/xhprof-0.9.4/xhprof_lib/utils/xhprof_lib.php";
include_once "/var/www/html/xhprof-0.9.4/xhprof_lib/utils/xhprof_runs.php";
$xhprof_runs = new XHProfRuns_Default();
$run_id = $xhprof_runs->save_run($xhprof_data, "xhprof_test");
echo "Report: http://localhost/xhprof-0.9.4/xhprof_html/index.php?run=$run_id&source=xhprof_test";
echo "\n";
/var/www/html/xhprof-0.9.4 - путь к папке которую мы разархивировали в ней необходимые нам библиотеки.
Report: http://localhost/xhprof-0.9.4/xhprof_html/index.php?run=57c32f3095d21&source=xhprof_test
Так выглядит анализ профайла. Эта таблица отображает все вызовы функций которые профилируются.
Мы можем сортировать функции кликая на заголовки таблицы.
Когда мы видим что какая то функция или много раз выполняется или очень долго, можем кликнуть на эту функцию и откроется подобная таблица но с внутренними вызовами внутри рассматриваемой функции и родительское окружение где была вызвана функция.
Показатели:
Total Incl. Wall Time (время затраченное на выполнение функций с учетом ожидания ответов от сокетов, файловой системы и других ресурсов)
Total Incl. CPU (время затраченное на выполнение функций)
Total Incl. MemUse (использование памяти)
Total Incl. PeakMemUse (пиковое использование памяти)
Number of Function Calls (количество вызовов функций)
Еще есть возможность графического отображения отчета. Но для этого надо убедится что у вас установлена библиотека graphviz:
Apt-get install graphviz
После в профиле нужно нажать для отображения и вуаля:
Теперь можете анализировать и улучшать код.