Як орієнтувати ефективність PHP-скрипту

Я хочу знати, який найкращий спосіб орієнтувати мої сценарії PHP. Не має значення, чи це робота, чи веб-сторінка, чи веб-служба.

Я знаю, що я можу використовувати мікрочаси, але чи справді це дає мені реальний час сценарію PHP?

Я хочу перевірити та порівняти різні функції в PHP, які роблять те саме. Наприклад, preg_matchvs strposабо domdocumentvs 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 знадобилося 0,015 або близько того.

Чи є кращий спосіб?

Якщо ви дійсно хочете порівняти реальний світ, використовуйте такі інструменти, як Xdebug та XHProf .

Xdebug чудово підходить, коли ви працюєте в розробці / постановці, а XHProf - чудовий інструмент для виробництва, і його безпечно запускати там (доки ви читаєте інструкції). Результати завантаження однієї сторінки не будуть настільки актуальними, як бачення того, як працює ваш код, поки сервер забивається, щоб зробити мільйон інших речей, а ресурсів стає мало. Це викликає ще одне питання: чи ви обмежуєте процес на процесорі? ОЗП? 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 .

В основному, ви включаєте профайлер, і кожен раз, коли ви завантажуєте веб-сторінку, він створює кешгринд файл, який можна читати за допомогою 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, яку я написав для власного використання.

Спробуйте 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 . Не має значення, чи він працює на кліпі або через інший сапі (наприклад, 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 папки, ви звалювати на сервері і з мінімальною конфігурацією, ви можете візуалізувати дані , зібрані і почати буріння вниз.

HTH!

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

Також переконайтесь, що код однаковий для кожної функції, яку ви хочете орієнтувати, за винятком функції, яку ви призначаєте.

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

Якщо на комп'ютері, на якому ви використовуєте тест, є багато інших речей, це може вплинути на результати еталону, якщо трапиться сплеск процесора або використання пам'яті з іншого додатка, коли ваш бенчмарк працює. Але якщо у вас є багато ресурсів, щоб запасти на комп’ютері, я не думаю, що це буде проблемою.

Гарним початком є ​​використання xdebugs profiler http://xdebug.org/docs/profiler

Можливо, це не найпростіша річ у налаштуванні та використанні, але, як тільки ви це отримаєте, великі обсяги даних і простота перегляду незамінні.

Еріку,

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

Головною проблемою тут є сприйняття користувачами часу завантаження: скільки часу йому доводиться чекати між натисканням на посилання та отриманням повністю відтвореної сторінки. Погляньте на швидкість сторінки Google, яку можна використовувати як розширення Ff або chrome, та документацію Pagespeed, яка глибоко обговорює, як досягти хорошої продуктивності сторінки. Дотримуйтесь цих вказівок і намагайтеся покращити результати своєї сторінки краще, ніж 90/100. (Домашня сторінка google набирає 99/100, як і мій блог). Це найкращий спосіб отримати хороші сприйняття користувачем.

Також добре стежити за своїм PHP-кодом та перехресно перевірити за цим посиланням , щоб переконатися, що саме ваше кодування потенційно не порушує продуктивність програми.