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

Question

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

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

Я хочу протестировать и сравнить различные функции в PHP, которые делают одно и то же. Например, preg_match против strpos или domdocument против preg_match или preg_replace против 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 потребовалось около 0,015.

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

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

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

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

Answer 4

Try 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
)

Answer 5

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

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

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

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

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

xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);

Для остановки:

$xhprof_data = xhprof_disable();

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

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

НТН!

Answer 6

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

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

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

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

Answer 7

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

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

Answer 8

Мой ответ получен из: https://stackoverflow.com/a/28868536/3066563

<?php
function yourFunction(){
  echo 'Code Im benchmarking';
}

$time_start = microtime(true);

$times=0;               // This couldn't be tough
while($times<1000)
{
   yourFunction();
   $times++;
}


$time_end = microtime(true);
$time = $time_end - $time_start;

echo "Did yourFunction in $time seconds\n";
?>

Просто измените код в вашей функции на эталонный тест.

Answer 9

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

Answer 10

Эрик

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

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