Массив против JSON в PHP? [Дубликат]

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

Также убедитесь, что код идентичен

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

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

Вы хотите посмотреть 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 :

[/g5]

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

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

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

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

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

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

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

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

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

Эрик,

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

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

Я посмотрю на xhprof . Не имеет значения, запущен ли он в кли или через другой 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!