Профилирование PHP-кода. XHProf и xDebug - профилирование (profiling) кода 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, но это нам не помеха.

Теперь можем профилировать наш код.

1. В начале страницы включаем профайлинг с помощью xhprof_enable();
2. В конце страницы выключаем профайлинг с помощью xhprof_disable() и сохраняем собранные данные с помощью save_run();
3. Далее анализируем.

Функция 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

После в профиле нужно нажать для отображения и вуаля:

Теперь можете анализировать и улучшать код.

FirePHP - это расширение для firebug, которое в связке со своим маленьким php-классом, позволяет транслировать в консоль firebug"а данные от php, например всякие var_dump и прочую отладочную информацию. Главный плюс этого расширения в том, что вся трансляция отладочной информации происходит через заголовки и не замусоривает страницы и вообще никак не ломает логику работы приложения. Официальный сайт: http://firephp.org/ .

Основная идея.

Общий алгоритм профилирования заключается в следующем:

1. В начале страницы включаем профайлинг с помощью xhprof_enable()
2. В конце страницы выключаем профайлинг с помощью xhprof_disable() и сохраняем собранные данные с помощью save_run()
3. Далее с помощью php-класса firephp передаем ссылку на данные профайлинга на клиентскую часть
4. В консоли firebug"а открываем нужную нам информацию
5. Радуемся:)

Еще хочется сказать, что, конечно, ручное добавление этих функций в свои php-скрипты - это здорово. Но хочется, чтобы эта информация всегда была под рукой во время разработки, и при этом не попадала на боевые сервера. Мы решаем эту задачу следующим образом:

В наших проектах почти во всех скриптах в начале подключается рабочий файлик с загрузчиком классов, подключением функций и прочими нужными штуками. Поэтому включение профайлинга мы вынесли в этот файл. А для того, чтобы иметь возможность включать/выключать отладочный режим по своему желанию добавили проверку на конфигурационную константу, плюс обернули эти проверки в некие мета-тэги, которые автоматически удаляются при сборке проекта. Тоже самое относится и к выключению профайлинга и записывании информации в заголовки с помощью 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.

Проделав вышеописанные процедуры мы получили возможность в любой момент прямо в браузере открыть и посмотреть на профайлинг любого нашего скрипта.

Профилирование приложения - это сбор данных о скорости выполнения различных участков программы (файлов и функций). Существует множество инструментов профилирования PHP, но не все инструменты подходят для проведения анализа прямо на рабочем сайте.

XHProf и его форк Tideways - удобный и простой профайлер, который способен эффективно собирать статистику о работе приложения почти без снижения скорости работы вашего приложения (или вашего сайта).

Зачем профилировать код?

Если приложение начинает работать медленно (читай «сайт начал тормозить»), профилирование позволит узнать, какая именно часть наиболее медленная. Результат профилирования обычно представляет собой список выполненных функций вместе со временем их выполнения.

Процедура профилирования кода должна идти первой в процессе оптимизации приложения. Любые другие действия будут догадками и, скорее всего, неправильными. Нужно знать, что именно вызывает проблемы и «тормоза».

Профилирование - это процедура сбора и организации статистики о времени выполнения кода. Это не процесс оптимизации либо изменения программ. Результатом этого процесса обычно является расширенный отчёт о компонентах программы, статистика выполнения функций.

Именно для этого и было разработано решение XHProf. Оно предназначено для работы на реальных сайтах. Основная идея этого профайлера - создавать минимум нагрузки на приложение, при этом собирать все необходимые данные о скорости работы. Решение разработано специалистами из Facebook.

Как подключить php-профайлер в автоматическом режиме?

Наши специалисты потрудились и сделали данный процесс абсолютно автоматизированным.
Вам достаточно авторизоваться в , во вкладке «Домены» выбрать нужный домен, кликнуть по иконке «PHP.INI + PHP Профайлер» и включить чекбокс «Профайлер для домена».

На включение данной функции может потребоваться некоторое время, обычно не более 10 минут.

Для php версий 5.2, 5.3, 5.4, 5.5, 5.6, 7.0 мы используем профайлер XHProf , для php версии 7.1 и выше мы используем профайлер Tideways .

После включения на каждой странице вашего сайта, обрабатываемой php, в нижнюю её часть будет встроен специальный блок со ссылками на файл отчёта (ссылка будет выглядеть примерно так:

Domain-name.com/xhprof-master/xhprof_html/index.php?run=XXXXXXXXXXXX&source=someapp)

А вот как будет выглядеть файл отчета:

Таблица содержит список функций, которые были выполнены в рамках одной страницы с дополнительной информацией:

• Calls - количество и процентное соотношение вызовов функции
• Incl. Wall Time - время выполнения функции с вложенными функциями
• Excl. Wall Time - время выполнения функции без вложенных функций
• Incl. CPU - процессорное время с вложенными функциями
• Excl. CPU - процессорное время без вложенных функций
• Incl. MemUse - потребление памяти с вложенными функциями
• Excl. MemUse - потребление памяти без вложенных функций
• Incl. PeakMemUse - максимальное потребление памяти с вложенными функциями
• Excl. PeakMemUse - максимальное потребление памяти без вложенных функций

Нужно заметить, что отчет, построенный с помощью tideways, может немного визуально отличаться от этого отчета, но суть от этого не меняется.

Графические отчеты

Ресурсоёмкие участки кода выделены желтым (средние) и красным (самые тяжёлые). Это те участки кода, которые используют множество ресурсов относительно всей остальной программы. Это может быть одна медленная функция или большое количество вызовов быстрой функции. В нашем примере мы видим, что функция mysqli_multi_query() помечена красным из-за того, что выполняется медленнее всего.

Агрегатные отчеты

Интерфейс XHProf также позволяет просматривать агрегатную информацию сразу с нескольких отчетов. Для этого run_id передаются через запятую:

Domain-name.com/xhprof-master/xhprof_html/index.php?run=XXXXXXXXXXXX,YYYYYYYYYYY&source=someapp

Технические особенности

Автоматическое включение профайлера реализовано с помощью директив auto_append_file и auto_prepend_file , которые подключают два исполняемых php файла:

— auto_append_file выполняет инициализацию объекта сбора статистики и запускает его работу;

— auto_prepend_file завершает сбор статистики и генерирует файл-отчет со статистикой (в формате JSON);

Если в процессе выполнения вашего скрипта будет вызвана функция exit() или die(), то auto_prepend_file не будет выполнен, файл статистики не будет сгенерирован и в нижнюю часть страницы не будет включен блок, со ссылками на файл отчета.

1. Таким образом обращение к любой странице, обрабатываемой php, будет инициировать создание нового файла отчета, поэтому мы рекомендуем отключить профайлер после сбора статистики (обычно для этого хватает нескольких часов), во избежание переполнения дисковой квоты, которая может исчерпаться после генерации большого количества отчетов!
2. Важно: профайлер будет работать только если сайт прикреплен к серверу по стандартному пути, автоматическими средствами (то есть, с помощью панели управления хостингом), в противном случае для настройки профайлера вам нужно обратиться в техническую поддержку Hostland.
3. В автоматическом режиме профайлер подключается только к основному доменному имени, к поддоменам автоматического подключение профайлера не предусмотрено.
4. В автоматическом режиме профайлер собирает статистику только скриптов с расширением.php и.php5
5. Не возможно гарантировать бесперебойную работу сайта после подключения php-профайлера, поэтому, в случае некорректной работы сайта во время включенного профайлера его следует отключить и продолжить профилирование другими средствами.

Подведём итоги

Мы будем надеяться, что данный инструмент поможет вам сделать ваши сайты еще более быстрыми на хостинге Hostland.

В статье частично использованы материалы пользователя Den Golotyuk размещенные на сайте

Рассказывалось о том, как установить и настроить xdebug, описывались некоторые простейшие возможности, такие как улучшение вывода функции var_dump() или вывод трассировки стека вызовов при получении сообщения об ошибке. Во второй части мы рассмотрели такую возможность xdebug как трассировку. Трассировка содержит все вызовы функций и методов в программе, время запуска, опционально размер памяти, передаваемые и возвращаемые параметры. Лог трассировки может помочь вам понять пути выполнения сложной программы. Вместо того чтобы вставлять отладочный код внутрь программы, вы включаете или выключаете трассировку в тем места где нужно, а потом используете утилиты подобные grep или собственно написанные приложения на PHP для анализа лог файла.

В данной статье мы рассмотрим профайлинг. Профайлинг с первого взгляда похож на трассировку. Профайлинг-лог не предназначет для людей, не предназначен для визуализации потока выполнения программы, однако он обеспечивает нас данными для статистического анализа запущенной программы.

Создания профайлинг-лога

Ниже короткая выдержка из профайлинг-лога, созданного xdebug:

fl=php:internal
fn=php::define
106 3

Fl=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

Как вы видите, профайлинг-лог не возможно читать напрямую. Мы будем использовать дополнительный инструменты для визуализации и анализа полученных данных. Итак, профайлинг показывает как много раз запущена была та или иная строчка и сколько времени занял запуск.
Создание профайлинг-лога сильно ухудшает производительность, подобно создания лога трассировки, потому что надо описать прохождение каждой строчки. Поэтому также как и в случае трассировки, не запускаете профайлинг на боевых серверах… Однако существуют случаи, когда профайлинг необходимо запустить на live-системе. В этом случае будьте осторожны в одновременном запуске xdebug с дроугими расширениями Zend, такими как загрузчики, оптимизаторы или кэши.
Для того, чтобы xdebug начал записывать профайлинг-лог добавьте

Пожалуйста, отметьте, что вы не можете запустить профайлинг во время запуска путем запуска команды.
Так как профайлинг-лог предназначен для чтения программами-анализаторами, не существует дополнительных настроек, которые позволяют отображать дополнительную информацию, как в случае лога трассировки. Однако есть некоторые настройки, которые позволяют настроить профайлинг, похожие на те, которые мы использовали при настройке трассировки.
Во-первых, xdebug по умолчанию пишет профайлинг-лог в каталог /tmp. Если вы используете Windows, необходимо исправить php.ini, например так:

xdebug.profiler_output_dir=«c:\traces»

По умолчанию xdebug перезаписывает существующий профайлинг-лог. Вы можете настроить, чтобы он дополнял существующий, для чего добавьте следующую команду

в php.ini. Есть такие случаи, когда вы не хотите создавать профайлинг-лог для всех файлов, в тоже время активация профайлинга во время выполнения проблематична. Вместо периодического включения и выключения профайлинга, добавьте команду

xdebug.profiler_enable_trigger=On

в php.ini. Теперь вы можете включать и выключать профайлинг, передавая специальный GET или POST параметр XDEBUG_PROFILE в PHP-скрипт. Это включит профайлинг только для данного PHP-скрипта. Необязательно устанавливать значение этого параметра, не забудьте только добавить этот параметр в адрес test.php?XDEBUG_PROFILE.

Название профайлинг-лога

Имя, которое по умолчания xdebug присваивает профайлинг-логу «cachegrind.out.» плюч идентификатор процесса. Также как и в случае лога трассировки можно изменить названия лога, добавляя в php.ini соответствующие настройки. Название параметра xdebug.profiler_output_name. Аргументом является строка. которая может содержать различные модификаторы. Самые важные ниже:

• %p – идентификатор процесса
• %r – случайное число
• %u - время
• %H – значение $_SERVER["HTTP_HOST"]
• %R – значение $_SERVER["REQUEST_URI"]
• %s – имя, включающее полный путь, слеши конвертируются в знаки подчеркивания

Пожалуйста, отметьте, что модификатор %s используется только для xdebug.profiler_output_name. Если вы хотите узнать название профайлинг-лога, вы можете вызвать функцию xdebug_get_profiler_filename().

Анализ профайлинг-лога
Как уже говорилось выше, для анализа профайлинг-лога необходимы дополнительные программы для визуализации данных. Все профайлинг-логи, которые создает 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

Как вы можете отметить, необходимо прописать путь к текущей установке KDE-библиотеки. Если вы не знаете, где в вашей системе находятся библиотеки KDE, используйте

для отображения пути к библиотекам KDE.
После установки, вы можете запустить KCacheGrind из командной строки

Табличное отображение данных в KCachegrind очень похоже на WinCachegrind. Вы также можете переключаться между абсолютными и процентными значениями. Некоторые возможности KCachegrind не предназначены для PHP. На картинке внизу показан граф вызовов программы phpMyAdmin:

Как вы можете видеть, большая часть времени запуска прошла внутри 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, перескакивать через участки кода, смотреть, как и где переменные изменяют значения.

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.