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

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

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

• в JMeter
• ApacheBench (посмотреть пример)
• dbench
• http_load
• curl-loader
• 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

и вот скриншот на 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. Не имеет значения, запускается ли он на 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 для централизации данных (чтобы видеть все запуски со всех наших серверов).

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

HTH!

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

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

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

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

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

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

Эрик

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

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

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