An extension to PHP called Xdebug is available to assist in profiling PHP applications , as well as runtime debugging. When running the profiler, the output is written to a file in a binary format called "cachegrind". Applications are available on each platform to analyze these files. No application code changes are necessary to perform this profiling.
To enable profiling, install the extension and adjust php.ini settings. Some Linux distributions come with standard packages (e.g. Ubuntu"s php-xdebug package). In our example we will run the profile optionally based on a request parameter. This allows us to keep settings static and turn on the profiler only as needed.
# php.ini settings # Set to 1 to turn it on for every request xdebug.profiler_enable = 0 # Let"s use a GET/POST parameter to turn on the profiler xdebug.profiler_enable_trigger = 1 # The GET/POST value we will pass; empty for any value xdebug.profiler_enable_trigger_value = "" # Output cachegrind files to /tmp so our system cleans them up later xdebug.profiler_output_dir = "/tmp" xdebug.profiler_output_name = "cachegrind.out.%p"
Next use a web client to make a request to your application"s URL you wish to profile, e.g.
Http://example.com/article/1?XDEBUG_PROFILE=1
As the page processes it will write to a file with a name similar to
/tmp/cachegrind.out.12345
By default the number in the filename is the process id which wrote it. This is configurable with the xdebug.profiler_output_name setting.
Note that it will write one file for each PHP request / process that is executed. So, for example, if you wish to analyze a form post, one profile will be written for the GET request to display the HTML form. The XDEBUG_PROFILE parameter will need to be passed into the subsequent POST request to analyze the second request which processes the form. Therefore when profiling it is sometimes easier to run curl to POST a form directly.
Analyzing the Output
Once written the profile cache can be read by an application such as or Webgrind . PHPStorm, a popular PHP IDE, can also display this profiling data .
KCachegrind, for example, will display information including:
- Functions executed
- Call time, both itself and inclusive of subsequent function calls
- Number of times each function is called
- Call graphs
- Links to source code
What to Look For
Obviously performance tuning is very specific to each application"s use cases. In general it"s good to look for:
- Repeated calls to the same function you wouldn"t expect to see. For functions that process and query data these could be prime opportunities for your application to cache.
- Slow-running functions. Where is the application spending most of its time? the best payoff in performance tuning is focusing on those parts of the application which consume the most time.
Note : Xdebug, and in particular its profiling features, are very resource intensive and slow down PHP execution. It is recommended to not run these in a production server environment.
Профилирование приложения — это сбор данных о скорости выполнения различных участков программы (файлов и функций). Существует множество инструментов профилирования PHP, но не все инструменты подходят для проведения анализа прямо в продакшне.
XHProf — мега простой профайлер, который собирает статистику прямо во время работы приложения почти без оверхеда .
Зачем профилировать?
Если приложение начинает работать медленно, профилирование поможет узнать, какая именно часть тупит. Результат профилирования — это обычно список выполненных функций и времени их исполнения.
Профилирование стоит делать до любой оптимизации приложения. В противном случае — будете руководствоваться догадками. Скорее всего неправильными.
Проблема Xdebug
Xdebug — мощное решение для PHP. Но сама платформа Xdebug настолько тяжелая, что ее нельзя использовать на работающих сайтах
. XDebug создает значительную нагрузку на ресурсы сервера и замедляет приложение.
С другой стороны, проблемы на "живом" сайте могут быть совершенно не такими, как в среде разработчика. Профилирование только на компьютерах разработчиков будет показывать лишь часть проблем.
Именно поэтому и было разработано решение XHprof . Оно предназначено для применения в работающих приложениях. Основная идея этого профайлера — создавать минимум нагрузки на приложение при этом собирать все необходимые данные о скорости работы. Решение разработано ребятами из Facebook и поддерживается новыми версиями PHP .
XHProf
Установка
На Debian XHprof есть в sid пакетах, поэтому: apt-get install xhprof
Вы также можете собрать XHprof самостоятельно.
Включение профилирования
Пусть у нас есть скрипт с таким кодом:
execute();
Проведем профилирование с помощью XHprof. Для этого на этой странице необходимо:
- Включить профайлер в самом начале.
- В самом конце программы остановить профайлер и сохранить полученные данные.
Это будет выглядеть так:
# Инициализируем профайлер xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY); # Выполняем программу после включения профайлера execute(); # Останавливаем профайлер после выполнения программы $xhprof_data = xhprof_disable();
# Сохраняем результат профилирования в переменную $xhprof_data
- Функция xhprof_enable() принимает в качестве аргументов флаги. XHPROF_FLAGS_CPU для фиксирования статистики процессора, XHPROF_FLAGS_MEMORY — для памяти, XHPROF_FLAGS_NO_BUILTINS — для игнорирования встроенных функций.
- xhprof_disable() выключит профайлер и вернет собранную статистику.
Отчеты
Генерация
Собранные данные можно проанализировать в интерфейсе 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
После этого необходимо внести изменения в скрипт:
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
После этого появится список отчетов:
Таблица содержит список функций, которые были выполнены в рамках одной страницы с дополнительной информацией:
- Calls — количество и процентное соотношение вызовов функции.
- Incl. Wall Time — время выполнения функции с вложенными функциями.
- Excl. Wall Time — время выполнения функции без вложенных функций.
- Incl. CPU — процессорное время с вложенными функциями.
- Excl. CPU — процессорное время без вложенных функций.
- Incl. MemUse — потребление памяти с вложенными функциями.
- Excl. MemUse — потребление памяти без вложенных функций.
- Incl. PeakMemUse — максимальное потребление памяти с вложенными функциями.
- Excl. PeakMemUse — максимальное потребление памяти без вложенных функций.
Графические отчеты
Чтобы построить графический отчет, убедитесь, что у Вас установлен graphviz: apt-get install graphviz
Ресурсоемкие участки кода выделены желтым (средние) и красным (самые тяжелые). Это те участки кода, которые используют множество ресурсов относительно всей остальной программы. Это может быть одна медленная функция или большое количество вызовов быстрой функции. В нашем примере функция str_replace() помечена красным из-за 262 вызовов.
Агрегатные отчеты
Интерфейс XHprof также позволяет просматривать агрегатную информацию сразу с нескольких отчетов. Для этого run_id передаются через запятую: http://xh..php?run=53a894f6d5d9b,53a894fcf126e &source=test
TL;DR
Используйте XHprof для профилирования PHP прямо в продакшне.
Иногда ошибки ViewProfile.swf и другие системные ошибки SWF могут быть связаны с проблемами в реестре Windows. Несколько программ может использовать файл ViewProfile.swf, но когда эти программы удалены или изменены, иногда остаются "осиротевшие" (ошибочные) записи реестра SWF.
В принципе, это означает, что в то время как фактическая путь к файлу мог быть изменен, его неправильное бывшее расположение до сих пор записано в реестре Windows. Когда Windows пытается найти файл по этой некорректной ссылке (на расположение файлов на вашем компьютере), может возникнуть ошибка ViewProfile.swf. Кроме того, заражение вредоносным ПО могло повредить записи реестра, связанные с Bioshock 2. Таким образом, эти поврежденные записи реестра SWF необходимо исправить, чтобы устранить проблему в корне.
Редактирование реестра Windows вручную с целью удаления содержащих ошибки ключей ViewProfile.swf не рекомендуется, если вы не являетесь специалистом по обслуживанию ПК. Ошибки, допущенные при редактировании реестра, могут привести к неработоспособности вашего ПК и нанести непоправимый ущерб вашей операционной системе. На самом деле, даже одна запятая, поставленная не в том месте, может воспрепятствовать загрузке компьютера!
В связи с подобным риском мы настоятельно рекомендуем использовать надежные инструменты очистки реестра, такие как WinThruster (разработанный Microsoft Gold Certified Partner), чтобы просканировать и исправить любые проблемы, связанные с ViewProfile.swf. Используя очистку реестра , вы сможете автоматизировать процесс поиска поврежденных записей реестра, ссылок на отсутствующие файлы (например, вызывающих ошибку ViewProfile.swf) и нерабочих ссылок внутри реестра. Перед каждым сканированием автоматически создается резервная копия, позволяющая отменить любые изменения одним кликом и защищающая вас от возможного повреждения компьютера. Самое приятное, что устранение ошибок реестра может резко повысить скорость и производительность системы.
Предупреждение: Если вы не являетесь опытным пользователем ПК, мы НЕ рекомендуем редактирование реестра Windows вручную. Некорректное использование Редактора реестра может привести к серьезным проблемам и потребовать переустановки Windows. Мы не гарантируем, что неполадки, являющиеся результатом неправильного использования Редактора реестра, могут быть устранены. Вы пользуетесь Редактором реестра на свой страх и риск.
Перед тем, как вручную восстанавливать реестр Windows, необходимо создать резервную копию, экспортировав часть реестра, связанную с ViewProfile.swf (например, Bioshock 2):
- Нажмите на кнопку Начать .
- Введите "command " в строке поиска... ПОКА НЕ НАЖИМАЙТЕ ENTER !
- Удерживая клавиши CTRL-Shift на клавиатуре, нажмите ENTER .
- Будет выведено диалоговое окно для доступа.
- Нажмите Да .
- Черный ящик открывается мигающим курсором.
- Введите "regedit " и нажмите ENTER .
- В Редакторе реестра выберите ключ, связанный с ViewProfile.swf (например, Bioshock 2), для которого требуется создать резервную копию.
- В меню Файл выберите Экспорт .
- В списке Сохранить в выберите папку, в которую вы хотите сохранить резервную копию ключа Bioshock 2.
- В поле Имя файла введите название файла резервной копии, например "Bioshock 2 резервная копия".
- Убедитесь, что в поле Диапазон экспорта выбрано значение Выбранная ветвь .
- Нажмите Сохранить .
- Файл будет сохранен с расширением.reg .
- Теперь у вас есть резервная копия записи реестра, связанной с ViewProfile.swf.
Следующие шаги при ручном редактировании реестра не будут описаны в данной статье, так как с большой вероятностью могут привести к повреждению вашей системы. Если вы хотите получить больше информации о редактировании реестра вручную, пожалуйста, ознакомьтесь со ссылками ниже.
Последнее обновление: 12.01.2019 г.
Публикация: 09.01.2016 г.
Используя PhpStorm, ты можешь проанализировать работу своего PHP кода профилируя его. Профилирование позволит тебе собрать статистику выполнения программы: имена выполняемых функций, сколько раз каждая функция была выполнена, время выполнения каждой функции, какие другие функции были вызваны внутри каждой функции и так далее.
Эта информация может дать тебе подсказку о том, где твой код может быть улучшен.
Давай посмотрим, как это работает.
1. Необходимые условия
IDE PhpStorm может использовать информацию профилирования собранную с помощью инструмента Xdebug . Это расширение должно быть установлено и настроено в твоей системе. Для получения дополнительной информации смотри Руководство по установке Xdebug .
Если ты являешься пользователем замечательной портативной серверной платформы и программной среды Open Server, то делать ничего ненадо - расширение Xdebug уже установлено и подключено.
Внимание
Xdebug не совместим с IonCube. IonCube - это инструмент (утилиты) для защиты ПО, написанного на языке программирования PHP. Отключи расширение IonCube совсем или на время использования Xdebug. Ещё одна вероятная проблема может состоять в том, что Xdebug по умолчанию настроен на порт 9000 и он же используется в Open Server. Для её решения следует в одном из случаев изменить номер порта.
Все действия, описанные здесь, были воспроизведены с корректными ожидаемыми результатами при следующем технологическом окружении:
2. Включение профайлера Xdebug
Профилирование добавляет некоторые накладные расходы на запуск приложения и генерирует огромное количество информации на диске. Поэтому, лучше всего, включать профайлер Xdebug только при необходимости и отключать в обычных условиях.
Конфигурирование Xdebug осуществляется через директивы в активном php.ini файле. При любом способе включения профайлера необходимо настроить следующую директиву:
xdebug.profiler_output_dir = /path/to/store/snapshots
В значении директивы необходимо указать путь, который будет использоваться для сохранения файлов профилирования.
2.1. В глобальном масштабе
Чтобы включить профайлер Xdebug в глобальном масштабе необходимо использовать нижеуказанную директиву:
xdebug.profiler_enable = 1
Таким образом профилирование будет осуществляться при каждом запуске любого сценария. Использовать данный вариант включения профайлера удобно лишь в редких случаях.
2.2. С помощью дополнительных параметров интерпретатора
Включить профайлер с помощью дополнительных параметров интерпретатора можно в окне Run/Debug Configurations . Для его открытия используй следующие пункты главного меню IDE:
Опция (отмечена красным контуром на скриншоте выше) Interpreter options (параметры интерпретатора) секции Command Line (командная строка) должна содержать следующую строку:
D xdebug.profiler_enable = 1
Такой вариант позволит тебе использовать профайлер для конкретной конфигурации, а не в глобальном масштабе.
2.3. С помощью специальных GET/POST параметров или cookie файла
Для более управляемого профилирования необходимо использовать нижеуказанную директиву:
xdebug.profiler_enable_trigger = 1
Если значение директивы установлено в 1, то при выполнении сценария с GET/POST параметром или кукой с именем XDEBUG_PROFILE профилирование будет выполнено вне зависимости от установки xdebug.profiler_enable .
Данный вариант включения профайлера самый популярный.
3. Сбор логов профилирования
Для получения возможности анализа логов профилирования их необходимо сначала собрать.
3.1. Сбор логов профилирования для веб-приложений
Для профилирования веб-приложений используй профайлер Xdebug глобально или запускай и останавливай его по требованию. После включения профайлера открой приложение в браузере, чтобы начать сбор данных - логов профилирования.
При анализе проблем производительности, использование букмарклетов или расширений браузера для отладки является очень хорошим подходом, так как позволяет перемещаться по приложению и запускать профайлер только в тот момент, когда обнаружена проблема производительности. Это позволяет собирать целевые логи профилирования.
3.2. Сбор логов профилирования для CLI приложений и юнит-тестов
Для профилирования CLI приложений и юнит-тестов используй профайлер Xdebug глобально или создай отдельную конфигурацию запуска для включения профайлера с помощью окна Run/Debug Configurations . После чего запускай CLI приложение или юнит-тесты для сбора данных профилирования.
При анализе проблем производительности в юнит-тестах хорошим подходом является создание отдельной конфигурации запуска только тех юнит-тестов, в которых есть подозрения на проблемы с производительностью. Это позволяет собирать целевые логи профилирования.
4. Анализ описания лога профилирования
Давай подробнее рассмотрим лог профилирования.
4.1. Открытие лога профилирования
Для открытия лога профилирования используй следующие пункты главного меню IDE: .
Если ты являешься пользователем замечательной портативной серверной платформы Open Server, то для просмотра лога профилирования также можешь использовать кроссплатформенный инструмент Webgrind . Его можно найти через следующие пункты главного меню Open Server [Дополнительно → PHP профайлер] .
Логи профилирования сохраняются в папку согласно настроенной директиве xdebug.profiler_output_dir . Имя генерируемого файла всегда начинается с cachegrind.out. и заканчивается либо идентификатором процесса PHP или процесса веб-сервера или crc32 хэшем каталога, в котором находится профилируемый сценарий.
4.2. Вкладка Execution Statistics
Во вкладке Execution Statistics (статистика выполнения) ты можешь изучить сводную информацию о метриках исполнения каждой вызываемой функции. Ты можешь увидеть все файлы, вызовы функций, сколько раз они были вызваны, и время (абсолютное и относительное) выполнения каждой функции.
В верхней сетке отображаются различные метрики:
- Own Time (собственное время) - количество времени, которое функция затрачивает на выполнение своего кода (без учёта вызова других функций).
В нижней сетке отображаются две вкладки: Callees (вызываемые) - функции, которые сценарий вызывает здесь и Callers (вызывающие) - откуда сценарий был вызван. Ты можешь видеть различные метрики и здесь:
- Time (время) - общее время выполнения.
- Calls (вызовы) - количество вызовов.
Функции с большим собственным временем выполения или большим количеством вызовов, безусловно, требуют проверки.
4.3. Вкладка Call Tree
Во вкладке Call Tree (дерево вызовов) отображаются пути выполнения твоего кода. Тут ты можешь увидеть более подробную информацию о времени выполнении каждой функции и так далее.
В верхней сетке отображаются деревья вызовов (какие функции вызываются в других функциях) и другие метрики:
- Callable (вызванный файл) - файл, который был выполнен.
- Time (время) - общее время выполнения.
- Calls (вызовы) - количество вызовов.
В нижней сетке отображаются две вкладки: Callees (вызываемые) - функции, которые вызываются здесь и Callers (вызывающие) - откуда вызывается функция. Ты можешь видеть различные метрики и здесь:
- Callable (вызванная функция) - функция, которая была выполнена.
- Time (время) - общее время выполнения.
- Calls (вызовы) - количество вызовов.
Контрольные вопросы
- Для чего профилируют PHP-приложения?
- Сколько существует основных способов включения профайлера Xdebug?
- Каким образом лучше действовать при профилировании CLI приложений и юнит-тестов?
- С помощью каких инструментов можно проанализировать логи профилирования?
- При анализе лога профилирования на какие метрики следует обратить внимание в первую очередь?
FirePHP - это расширение для firebug, которое в связке со своим маленьким php-классом, позволяет транслировать в консоль firebug"а данные от php, например всякие var_dump и прочую отладочную информацию. Главный плюс этого расширения в том, что вся трансляция отладочной информации происходит через заголовки и не замусоривает страницы и вообще никак не ломает логику работы приложения. Официальный сайт: http://firephp.org/ .
Основная идея.
Общий алгоритм профилирования заключается в следующем:- В начале страницы включаем профайлинг с помощью xhprof_enable()
- В конце страницы выключаем профайлинг с помощью xhprof_disable() и сохраняем собранные данные с помощью save_run()
- Далее с помощью php-класса firephp передаем ссылку на данные профайлинга на клиентскую часть
- В консоли firebug"а открываем нужную нам информацию
- Радуемся:)
В наших проектах почти во всех скриптах в начале подключается рабочий файлик с загрузчиком классов, подключением функций и прочими нужными штуками. Поэтому включение профайлинга мы вынесли в этот файл. А для того, чтобы иметь возможность включать/выключать отладочный режим по своему желанию добавили проверку на конфигурационную константу, плюс обернули эти проверки в некие мета-тэги, которые автоматически удаляются при сборке проекта. Тоже самое относится и к выключению профайлинга и записывании информации в заголовки с помощью 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 .
Не буду вдаваться в подробности установки данных расширений, ибо тут все просто. Скажу только про некоторые моменты настройки. В xhproof предусмотрена всего одна конфигурационная переменная - xhprof.output_dir, которая указывает на папку, куда будут сохраняться данные профайлинга. Поэтому убедитесь, что в указанную директорию у пользователя, из-под которого выполняются php-скрипты есть права на запись. Так что пропишите в свой php.ini что-то вроде этого:
extension=xhprof.so
xhprof.output_dir="/var/tmp/xhprof"
Так же не плохо поставить что-то типа dot или Graphviz для рисования графов вызовов. У меня под MacOS X стоит Graphviz.
Проделав вышеописанные процедуры мы получили возможность в любой момент прямо в браузере открыть и посмотреть на профайлинг любого нашего скрипта.