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

Я хочу знать, что является лучшим способом сравнить мои PHP-скрипты. Неважно, если задание cron или веб-страница или веб-сервис.

Я знаю, что могу использовать microtime, но действительно ли это дает мне реальное время PHP script?

Я хочу проверить и сравнить различные функции в PHP, которые делают то же самое. Например, preg_match vs strpos или domdocument vs preg_match или preg_replace vs str_replace`

Пример веб-страницы:

<?php
// login.php

$start_time = microtime(TRUE);

session_start(); 
// do all my logic etc...

$end_time = microtime(TRUE);

echo $end_time - $start_time;

Это выведет: 0.0146126717 (меняется все время - но это последнее, что я получил). Это означает, что для выполнения PHP script потребовалось 0,015.

Есть ли лучший способ?

Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

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

jmeter
Инструмент ApacheBench (см. пример)
dbench
http_load
curl-loader
httperf
siege
vegeta
код, который вы используете, тоже хорош, но с большим циклом (например, 1 000 000).

Ответ 3

Вам нужно посмотреть 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

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

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

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

Ответ 4

Попробуйте 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
)

Ответ 5

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

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

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

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

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

xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);

Чтобы остановить:

$xhprof_data = xhprof_disable();

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

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

НТН!

Ответ 6

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

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

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

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

Ответ 7

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

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

Ответ 8

Эрик,

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

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

Ответ 9

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