Как проверить эффективность скрипта PHP

Если вы действительно хотите сравнить реальный код мира, используйте такие инструменты, как Xdebug и XHProf .

Xdebug отлично подходит, когда вы работаете в dev / staging, а XHProf – отличный инструмент для производства, и его безопасно запускать там (пока вы читаете инструкции). Результаты любой загрузки одной страницы не будут столь же важны, как просмотр того, как ваш код работает, пока сервер забивается, чтобы сделать миллион других вещей, а ресурсы становятся скудными. Возникает еще один вопрос: неудобны ли вы в CPU? ОЗУ? I / O?

Вы также должны смотреть за пределами кода, который вы используете в своих сценариях, на то, как ваши скрипты / страницы обслуживаются. Какой веб-сервер вы используете? В качестве примера я могу сделать nginx + PHP-FPM всерьез из-за того, что mod_php + Apache, который, в свою очередь, получает вызов для статического контента, используя хороший CDN.

Следующее, что нужно рассмотреть, это то, над чем вы пытаетесь оптимизировать?

• Является ли скорость, с которой страница отображает в браузере пользователей приоритет номер один?
• Получает ли каждый запрос на сервер, отбрасываемый как можно быстрее, с наименьшим потреблением ЦП?

Первому можно помочь, выполняя такие вещи, как gzipping всех ресурсов, отправленных в браузер, но при этом может (в некоторых случаях) оттолкнуть вас дальше от достижения последнего.

Надеемся, что все вышеперечисленное может помочь показать, что тщательно изолированное «лабораторное» тестирование не будет отражать переменные и проблемы, с которыми вы столкнетесь в процессе производства, и что вы должны определить, какова ваша цель на высоком уровне, а затем что вы можете сделать, чтобы добраться туда, прежде чем отправиться в путь микро / досрочной оптимизации в ад .

Чтобы проверить, как быстро ваш полный скрипт работает на сервере, есть множество инструментов, которые вы можете использовать. Сначала убедитесь, что ваш сценарий (например, preg_match vs strpos) должен выдавать те же результаты, чтобы квалифицировать ваш тест.

Вы можете использовать:

• JMeter
• Инструмент ApacheBench ( см. Пример )
• dbench
• http_load
• завиток-погрузчик
• httperf
• осада
• Вегета
• код, который вы используете, тоже хорош, но с большим циклом (например, 1 000 000)

Вы захотите взглянуть на Xdebug и, более конкретно, на возможности профилирования Xdebug .

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

Xdebug может быть немного сложным для настройки, так что вот соответствующий раздел моего php.ini для справки:

 [XDebug] zend_extension = h:\xampp\php\ext\php_xdebug-2.1.1-5.3-vc6.dll xdebug.remote_enable=true xdebug.profiler_enable_trigger=1 xdebug.profiler_output_dir=h:\xampp\cachegrind xdebug.profiler_output_name=callgrind.%t_%R.out на [XDebug] zend_extension = h:\xampp\php\ext\php_xdebug-2.1.1-5.3-vc6.dll xdebug.remote_enable=true xdebug.profiler_enable_trigger=1 xdebug.profiler_output_dir=h:\xampp\cachegrind xdebug.profiler_output_name=callgrind.%t_%R.out 

И вот скриншот файла .out в WinCacheGrind :

Это должно предоставить подробные сведения о том, насколько эффективен ваш PHP-скрипт. Вы хотите настроить таргетинг на то, что занимает больше времени. Например, вы можете оптимизировать одну функцию, чтобы получить половину времени, но ваши усилия будут лучше обслуживать, оптимизируя функцию, которая называется десятками, если не сотни раз во время загрузки страницы.

Если вам интересно, это просто старая версия CMS, которую я написал для моего собственного использования.

Попробуйте https://github.com/fotuzlab/appgati

Он позволяет определять шаги в коде и время отчетов, использование памяти, загрузку сервера и т. Д. Между двумя шагами.

Что-то вроде:

  $appgati->Step('1'); // Do some code ... $appgati->Step('2'); $report = $appgati->Report('1', '2'); print_r($report); 

Пример массива вывода:

 Array ( [Clock time in seconds] => 1.9502429962158 [Time taken in User Mode in seconds] => 0.632039 [Time taken in System Mode in seconds] => 0.024001 [Total time taken in Kernel in seconds] => 0.65604 [Memory limit in MB] => 128 [Memory usage in MB] => 18.237907409668 [Peak memory usage in MB] => 19.579357147217 [Average server load in last minute] => 0.47 [Maximum resident shared size in KB] => 44900 [Integral shared memory size] => 0 [Integral unshared data size] => 0 [Integral unshared stack size] => [Number of page reclaims] => 12102 [Number of page faults] => 6 [Number of block input operations] => 192 [Number of block output operations] => [Number of messages sent] => 0 [Number of messages received] => 0 [Number of signals received] => 0 [Number of voluntary context switches] => 606 [Number of involuntary context switches] => 99 ) 

Я бы посмотрел на xhprof . Не имеет значения, запущен ли он на кли или через другой sapi (например, fpm или fcgi или даже модуль Apache).

Наилучшая часть о xhprof заключается в том, что он даже достаточно подходит для работы на производстве. Что-то, что не работает с xdebug (последний раз я проверил). xdebug влияет на производительность и xhprof (я бы не сказал, что их нет) управляет намного лучше.

Мы часто используем xhprof для сбора проб с реальным трафиком, а затем анализируем код оттуда.

Это не настоящий показатель в плане того, что у вас есть время и все такое, хотя оно и делает это. Это просто упрощает анализ производственного трафика, а затем сворачивается до уровня функции php в собранном call-графе.

После того, как расширение скомпилировано и загружено, вы начинаете профилирование кода:

 xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY); 

Остановиться:

 $xhprof_data = xhprof_disable(); 

Затем сохраните данные в файле или в базе данных – независимо от того, что плавает ваша ловушка и не прерывает обычное время выполнения. Мы асинхронно нажимаем это на S3 для централизации данных (чтобы видеть все прогоны со всех наших серверов).

Код в github содержит папку xhprof_html, которую вы дампируете на сервере и с минимальной конфигурацией, вы можете визуализировать собранные данные и начать сверление.

НТН!

Поместите его в цикл for чтобы сделать каждую вещь 1 000 000 раз, чтобы получить более реалистичный номер. И только запустите таймер непосредственно перед кодом, который вы на самом деле хотите сравнить, а затем запишите время окончания сразу (т. Е. Не запускайте таймер перед session_start() .

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

Как выполняется сценарий (cronjob, php из командной строки, Apache и т. Д.) Не должны иметь значения, поскольку вы только определяете относительную разницу между скоростью различных функций. Таким образом, это соотношение должно оставаться неизменным.

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

Хорошим началом является использование профайлера xdebugs http://xdebug.org/docs/profiler

Может быть, это не самая простая задача для настройки и использования, но как только вы ее поймете, чистые объемы данных и простота просмотра незаменимы.

Эрик,

Вы задаете себе неправильный вопрос. Если ваш скрипт исполняется в ~ 15 мсек, тогда его время в значительной степени не имеет значения. Если вы запускаете совместную службу, тогда активация изображения PHP займет ~ 100 мсек, чтение в файлах сценариев ~ 30-50 мсек при полной кешировании на сервере, возможно, 1 или более секунд при загрузке с фермы NAS на сервере. Задержки сети при загрузке мебели страницы могут добавить много секунд.

Основная проблема здесь – восприятие пользователями времени загрузки: сколько времени он или она должен ждать между нажатием на ссылку и получением полностью отображаемой страницы. Посмотрите на скорость страницы Google, которую вы можете использовать в качестве расширения Ff или chrome, и документацию Pagespeed, в которой подробно обсуждается, как добиться хорошей производительности страницы. Следуйте этим рекомендациям и постарайтесь улучшить показатели своей страницы, чем 90/100. (Главная страница google оценивает 99/100, как и мой блог). Это лучший способ получить хорошую пользовательскую производительность.

Также полезно следить за кодом PHP и перекрестно проверять с помощью этой ссылки , чтобы убедиться, что ваша кодировка сама по себе не нарушает производительность приложения.