Рассказывалось о том, как установить и настроить 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, перескакивать через участки кода, смотреть, как и где переменные изменяют значения.
FirePHP - это расширение для firebug, которое в связке со своим маленьким php-классом, позволяет транслировать в консоль firebug"а данные от php, например всякие var_dump и прочую отладочную информацию. Главный плюс этого расширения в том, что вся трансляция отладочной информации происходит через заголовки и не замусоривает страницы и вообще никак не ломает логику работы приложения. Официальный сайт: http://firephp.org/ .
В наших проектах почти во всех скриптах в начале подключается рабочий файлик с загрузчиком классов, подключением функций и прочими нужными штуками. Поэтому включение профайлинга мы вынесли в этот файл. А для того, чтобы иметь возможность включать/выключать отладочный режим по своему желанию добавили проверку на конфигурационную константу, плюс обернули эти проверки в некие мета-тэги, которые автоматически удаляются при сборке проекта. Тоже самое относится и к выключению профайлинга и записывании информации в заголовки с помощью firephp - эти задачи решает одна функция, которая вызывается в конце каждого php-скрипта и так же обернута в мета-тэги. Выглядит это примерно так:
// В конфиг-файле приложения прописаны вот такие константы/** Режим работы среды окружения * */
define("APPLICATION_ENV" , "dev" ); // dev - отладка | pro - продакшин
/** Путь до профайлера */
define("XHPROF_ROOT" , __DIR__ . "/ExtProcs/debug/xhprof-0.9.2" );/***************************************************************************************
* Далее в файлике, который подгружается в начале каждого скрипта запускаем профайлинг
* DEV_START и DEV_END - это наши мета-тэги, все что между ними вырезается при сборке
***************************************************************************************///-- DEV_START
//-- в режиме отладки подключаем debug библиотеки
// Подгружаем firephp
require_once(__DIR__ . "/includes/ExtProcs/debug/firephp/FirePHP.class.php" );
//-- подгружаем профайлер
"/xhprof_lib/utils/xhprof_lib.php" );
require_once (XHPROF_ROOT . "/xhprof_lib/utils/xhprof_runs.php" );
// Инициализируем профайлинг с нужными флагами. Подробное описание флагов
// можно найти на php.net/manual/ru/xhprof.constants.php
xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);
}
//-- DEV_END// Ну и вот такая функция вызывается в конце каждого скрипта
// Ее вызов так же обернут в DEV_START и DEV_END/**
* Создаем ссылку на результат профайлинга и выводим это в консоль
*/
function dev_boot_Down() {
if (APPLICATION_ENV === "dev" ) {
// Инициализируем экземпляр firephp
$firephp = FirePHP::getInstance(true );
// Выключаем профайлинг и сохраняем данные
$xhprof_data = xhprof_disable();
$xhprof_runs = new XHProfRuns_Default();
$run_id = $xhprof_runs->save_run($xhprof_data, "xhprof_testing" );
// Формируем ссылку на данные профайлинга и записываем ее в консоль
$link = "http://" . $_SERVER["HTTP_HOST" ] . "/includes/ExtProcs/debug/xhprof-0.9.2/xhprof_html/index.php?run={$run_id}&source=xhprof_testing\n" ;
$firephp->info($link, "profiling data" );
}
}
* This source code was highlighted with Source Code Highlighter .
extension=xhprof.so
xhprof.output_dir="/var/tmp/xhprof"
Так же не плохо поставить что-то типа dot или Graphviz для рисования графов вызовов. У меня под MacOS X стоит Graphviz.
Проделав вышеописанные процедуры мы получили возможность в любой момент прямо в браузере открыть и посмотреть на профайлинг любого нашего скрипта.
Со временем любой PHP-программист сталкивается с проблемой низкой производительности своего приложения. Это может быть медленная загрузка конкретной страницы или слишком долгий ответ от API. И порой достаточно сложно понять, в чем причина тормозов? Порой случаются более сложные ситуации: на боевом сервере api сильно тормозит, но на стенде, где происходит разработка, - все хорошо. И пойди разберись, что идет не так. Производить отладку на рабочем сервере - это крайняя степень безысходности, до которой, конечно, лучше не доводить.
Именно для таких ситуаций и были придуманы специальные инструменты, называемые профилировщиками приложений. В мире PHP эту роль выполняют xDebug, а также xhprof. xhprof является более легковесным, простым и гибким инструментом, поэтому его использование более предпочтительно. Что интересно, xhprof был разработан в facebook еще в 2009 году, однако до сих пор от них нет официальной поддержки php7 и больше не будет, поскольку facebook перешел на HHVM. Однако, благодаря обширному сообществу php-разработчиков, появился форк , поддерживающий php7, установка которого не вызывает каких-либо сложностей.
УстановкаДля начала нужно, собственно, установить xhprof:
Git clone https://github.com/longxinH/xhprof xhprof cd xhprof/extension phpize ./configure --with-php-config=/usr/bin/php-config sudo make && sudo make install mkdir /var/tmp/xhprof
Extension=xhprof.so xhprof.output_dir="/var/tmp/xhprof"
Для папки /var/tmp/xhprof должен быть доступ на запись, т.к. туда будут сохраняться результаты профайлинга.
Можно перезагрузить PHP-FPM и проверить, установилось ли расширение. Банально, это можно сделать с помощью вывода функции phpinfo();
xhprof установлен, можно им пользоваться. В пакет xhprof входит очень удобный интерфейс для анализа отчетов профилирования. xhprof позволяет строить отчеты, как в текстовом так и графическом виде. В установочной папке xhprof находятся xhprof_html и xhprof_lib , которые нам понадобятся. Папка xhprof_html - предоставляет доступ к GUI. xhprof_lib - библиотека для отображения и анализа кода. Всю папку xhprof целесообразно перенести в /var/www/xhprof и настроить для нее виртуальный хост, например xhprof.loc. Пример для nginx:
Server { listen 80; server_name xhprof.loc; charset utf-8; root /var/www/xhprof/xhprof_html; index index.php; location / { try_files $uri $uri/ /index.php?q=$uri&$args; } location ~ \.php { fastcgi_pass 127.0.0.1:9000; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } }
Также необходимо не забыть обновить файл hosts. Теперь при введении в браузерe URL xhprof.loc мы будем попадать на веб-интерфейс профилировщика, где будут доступы сгенерированные им файлы.
Теперь можно приступить непосредственно к профилированию кода.
Для включения профилировщика используется функция xhprof_enable() , которая на вход принимает следующие флаги:
Для отключения же профилировщика используется функция xhprof_disable(). Для удобства напишем два скрипта header.php и footer.php, выполняющие эти функции. header.php подключается в начало профилируемого скрипта, а footer.php - в конец. footer.php занимается также и сохранением данных профилирования.
header.php: if (extension_loaded("xhprof")) { include_once "/var/www/xhprof/xhprof_lib/utils/xhprof_lib.php"; include_once "/var/www/xhprof/xhprof_lib/utils/xhprof_runs.php"; xhprof_enable(XHPROF_FLAGS_CPU); } footer.php: if (extension_loaded("xhprof")) { $profilerNamespace = "ЗДЕСЬ_ИМЯ_ПРОФИЛИРУЕМОГО_СКРИПТА"; $xhprofData = xhprof_disable(); $xhprofRuns = new XHProfRuns_Default(); $runId = $xhprofRuns->save_run($xhprofData, $profilerNamespace); }Подключив header.php и footer.php к профилируемому скриту, можно начинать: при выполнении профилируемого скрипта сгенерируется файл, который сохранится в директории /var/tmp/xhprof , содержащий информацию о работе скрипта. При открытии веб-интерфейса xhprof.loc, будет доступен этот сгенерированный файл:
При открытии файла профилирования появляется детальная информация о работе приложения, весь стек вызовов:
Что значат столбцы:
Если перейти по ссылке , то отобразится прекрасное дерево вызовов с визуальной индикацией наиболее тормознутого кода. Если же этого не произошло, то скорее всего нужно установить библиотеку graphviz:
Apt-get install graphviz
Пример построенного графика:
В моем случае самое узкое место - это взаимодействие с БД.
Изначально xhprof разрабатывался именно с целью профилирования кода в бою, на production серверах. Другого бесплатного и эффективного инструмента профилирования php7-кода в бою по-просту нет, поэтому у xhprof нет конкурентов. Конкретно у меня есть опыт использования xhprof на production сервере, который обрабатывает миллион запросов в сутки. Там используется php7, и проблем пока не было обнаружено. Однако, xhprof не запускается для каждого запроса - генерировалось бы слишком много файлов профилирования. У меня профилировщик запускается только в том случае, если в запросе указан заголовок «XHPROF_ENABLE» и он установлен в true. Также можно использовать и другую стратегию, например, запускать профилировщик случайно с вероятностью, скажем, в 1/1000. Тогда тоже будет достаточно ясная картина.
Даже несмотря на то, что xhprof официально не поддерживается для php7, он по-прежнему остается незаменимым инструментом для php-разработчика.
Последнее обновление: 12.01.2019 г.
Публикация: 09.01.2016 г.
Используя PhpStorm, ты можешь проанализировать работу своего PHP кода профилируя его. Профилирование позволит тебе собрать статистику выполнения программы: имена выполняемых функций, сколько раз каждая функция была выполнена, время выполнения каждой функции, какие другие функции были вызваны внутри каждой функции и так далее.
Эта информация может дать тебе подсказку о том, где твой код может быть улучшен.
Давай посмотрим, как это работает.
IDE PhpStorm может использовать информацию профилирования собранную с помощью инструмента Xdebug . Это расширение должно быть установлено и настроено в твоей системе. Для получения дополнительной информации смотри Руководство по установке Xdebug .
Если ты являешься пользователем замечательной портативной серверной платформы и программной среды Open Server, то делать ничего ненадо - расширение Xdebug уже установлено и подключено.
Внимание
Xdebug не совместим с IonCube. IonCube - это инструмент (утилиты) для защиты ПО, написанного на языке программирования PHP. Отключи расширение IonCube совсем или на время использования Xdebug. Ещё одна вероятная проблема может состоять в том, что Xdebug по умолчанию настроен на порт 9000 и он же используется в Open Server. Для её решения следует в одном из случаев изменить номер порта.
Все действия, описанные здесь, были воспроизведены с корректными ожидаемыми результатами при следующем технологическом окружении:
Профилирование добавляет некоторые накладные расходы на запуск приложения и генерирует огромное количество информации на диске. Поэтому, лучше всего, включать профайлер Xdebug только при необходимости и отключать в обычных условиях.
Конфигурирование Xdebug осуществляется через директивы в активном php.ini файле. При любом способе включения профайлера необходимо настроить следующую директиву:
xdebug.profiler_output_dir = /path/to/store/snapshots
В значении директивы необходимо указать путь, который будет использоваться для сохранения файлов профилирования.
Чтобы включить профайлер Xdebug в глобальном масштабе необходимо использовать нижеуказанную директиву:
xdebug.profiler_enable = 1
Таким образом профилирование будет осуществляться при каждом запуске любого сценария. Использовать данный вариант включения профайлера удобно лишь в редких случаях.
Включить профайлер с помощью дополнительных параметров интерпретатора можно в окне Run/Debug Configurations . Для его открытия используй следующие пункты главного меню IDE:
Опция (отмечена красным контуром на скриншоте выше) Interpreter options (параметры интерпретатора) секции Command Line (командная строка) должна содержать следующую строку:
D xdebug.profiler_enable = 1
Такой вариант позволит тебе использовать профайлер для конкретной конфигурации, а не в глобальном масштабе.
Для более управляемого профилирования необходимо использовать нижеуказанную директиву:
xdebug.profiler_enable_trigger = 1
Если значение директивы установлено в 1, то при выполнении сценария с GET/POST параметром или кукой с именем XDEBUG_PROFILE профилирование будет выполнено вне зависимости от установки xdebug.profiler_enable .
Данный вариант включения профайлера самый популярный.
Для получения возможности анализа логов профилирования их необходимо сначала собрать.
Для профилирования веб-приложений используй профайлер Xdebug глобально или запускай и останавливай его по требованию. После включения профайлера открой приложение в браузере, чтобы начать сбор данных - логов профилирования.
При анализе проблем производительности, использование букмарклетов или расширений браузера для отладки является очень хорошим подходом, так как позволяет перемещаться по приложению и запускать профайлер только в тот момент, когда обнаружена проблема производительности. Это позволяет собирать целевые логи профилирования.
Для профилирования CLI приложений и юнит-тестов используй профайлер Xdebug глобально или создай отдельную конфигурацию запуска для включения профайлера с помощью окна Run/Debug Configurations . После чего запускай CLI приложение или юнит-тесты для сбора данных профилирования.
При анализе проблем производительности в юнит-тестах хорошим подходом является создание отдельной конфигурации запуска только тех юнит-тестов, в которых есть подозрения на проблемы с производительностью. Это позволяет собирать целевые логи профилирования.
Давай подробнее рассмотрим лог профилирования.
Для открытия лога профилирования используй следующие пункты главного меню IDE: .
Если ты являешься пользователем замечательной портативной серверной платформы Open Server, то для просмотра лога профилирования также можешь использовать кроссплатформенный инструмент Webgrind . Его можно найти через следующие пункты главного меню Open Server [Дополнительно → PHP профайлер] .
Логи профилирования сохраняются в папку согласно настроенной директиве xdebug.profiler_output_dir . Имя генерируемого файла всегда начинается с cachegrind.out. и заканчивается либо идентификатором процесса PHP или процесса веб-сервера или crc32 хэшем каталога, в котором находится профилируемый сценарий.
Во вкладке Execution Statistics (статистика выполнения) ты можешь изучить сводную информацию о метриках исполнения каждой вызываемой функции. Ты можешь увидеть все файлы, вызовы функций, сколько раз они были вызваны, и время (абсолютное и относительное) выполнения каждой функции.
В верхней сетке отображаются различные метрики:
В нижней сетке отображаются две вкладки: Callees (вызываемые) - функции, которые сценарий вызывает здесь и Callers (вызывающие) - откуда сценарий был вызван. Ты можешь видеть различные метрики и здесь:
Функции с большим собственным временем выполения или большим количеством вызовов, безусловно, требуют проверки.
Во вкладке Call Tree (дерево вызовов) отображаются пути выполнения твоего кода. Тут ты можешь увидеть более подробную информацию о времени выполнении каждой функции и так далее.
В верхней сетке отображаются деревья вызовов (какие функции вызываются в других функциях) и другие метрики:
В нижней сетке отображаются две вкладки: Callees (вызываемые) - функции, которые вызываются здесь и Callers (вызывающие) - откуда вызывается функция. Ты можешь видеть различные метрики и здесь:
Контрольные вопросы
С помощью систем для профилирования можно собрать информацию о том, какие функции в 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 работает быстро, то стоит подумать, нужно ли вызывать функции так часто?
При обнаружении следующих ситуаций стоит подумать о кэшировании:
Не стоит кэшировать все подряд, так как память тоже ценный ресурс. Кэшируйте те данные, к которым обращаетесь постоянно. Также кэширование имеет мало смысла в случае если кэширование тратит больше ресурсов, чем экономит.
Кроме кэширования в коде не стоит забывать о кэшировании с помощью веб-сервера (), а также на стороне клиента. Если использовать правильные заголовки, то многие запросы могут быть разрешены еще до поступления на сервер.