Profilare cod PHP. XHProf și xDebug - profilarea codului PHP Folosind parametri suplimentari de interpret

Instalarea xhprof pentru php:

Sudo apt-get install php5-xhprof

Reporniți Apache:

Reporniți serviciul Sudo apache2

Printează phpinfo(); și verificați dacă modulul este conectat sau nu?

Verificăm /etc/php5/apache2/conf.d pentru a vedea dacă acolo apare un link către configurația xhprof.ini.

Dacă nu, atunci creați singur legătura și reporniți Apache.

Sudo ln -s /etc/php5/mods-available/xhprof.ini /etc/php5/apache2/conf.d/20-xhprof.ini sudo service apache2 restart

Verificăm conexiunea xhprof, verificăm dacă 20-xhprof.ini este conectat:

Captura de ecran arată versiunea 0.9.2, deși în timpul instalării a fost afișată versiunea 0.9.4, dar aceasta nu este o piedică pentru noi.

Acum ne putem profila codul.

1. La începutul paginii, activați profilarea folosind xhprof_enable();
2. La sfârșitul paginii, dezactivați profilarea folosind xhprof_disable() și salvați datele colectate folosind save_run();
3. În continuare analizăm.

Funcţie xhprof_enable() ia steaguri drept argumente:

XHPROF_FLAGS_CPU pentru înregistrarea statisticilor procesorului,

XHPROF_FLAGS_MEMORY - pentru memorie,

XHPROF_FLAGS_NO_BUILTINS - pentru a ignora funcțiile încorporate.

Pentru a salva și a informa în continuare, trebuie să instalăm un instrument de analiză a profilului.

Descărcați arhiva cu instrumentul de analiză de pe pagina xhprof:, luați versiunea 0.9.4.

Pe server sau pe computerul local, creați un folder accesibil prin localhost sau un domeniu separat în care dezarhivăm arhiva descărcată:

Acum putem salva profilul.

https://xn--d1acnqm.xn--j1amh/altadmin/posts/edit/188

Codul de urmărire arată cam așa:

// Inițializați profilerul - vom număra atât timpul procesorului, cât și consumul de memorie xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);
// Cod profilat # Opriți profilerul $xhprof_data = xhprof_disable(); # Salvați raportul și generați un link pentru a-l vizualiza include_once „/var/www/html/xhprof-0.9.4/xhprof_lib/utils/xhprof_lib.php”; include_once „/var/www/html/xhprof-0.9.4/xhprof_lib/utils/xhprof_runs.php”; $xhprof_runs = nou XHProfRuns_Default(); $run_id = $xhprof_runs->save_run($xhprof_data, "xhprof_test"); echo „Raport: http://localhost/xhprof-0.9.4/xhprof_html/index.php?run=$run_id&source=xhprof_test”; ecou „\n”;

/var/www/html/xhprof-0.9.4 - calea către folderul în care am dezarhivat bibliotecile de care avem nevoie.

Raport: http://localhost/xhprof-0.9.4/xhprof_html/index.php?run=57c32f3095d21&source=xhprof_test

Așa arată o analiză de profil. Acest tabel afișează toate apelurile de funcții care sunt profilate.

Putem sorta funcțiile făcând clic pe titlurile tabelului.

Când vedem că o funcție este executată fie de multe ori, fie pentru o perioadă foarte lungă de timp, putem face clic pe această funcție și se va deschide un tabel similar, dar cu apeluri interne în interiorul funcției în cauză și a mediului părinte în care a fost apelată funcția.

Indicatori:
Total Inc. Wall Time (timpul petrecut pentru executarea funcțiilor, ținând cont de așteptarea răspunsurilor de la socket-uri, sistemul de fișiere și alte resurse)
Total Inc. CPU (timpul petrecut executând funcții)
Total Inc. MemUse (utilizarea memoriei)
Total Inc. PeakMemUse (utilizare maximă a memoriei)
Numărul de apeluri de funcție

Există și opțiunea de afișare grafică a raportului. Dar pentru a face acest lucru, trebuie să vă asigurați că aveți instalată biblioteca graphviz:

Apt-get install graphviz

Apoi, în profilul dvs. trebuie să faceți clic pentru a afișa și voila:

Acum puteți analiza și îmbunătăți codul.

FirePHP este o extensie pentru firebug, care, împreună cu clasa sa mică php, vă permite să difuzați date din php, de exemplu, tot felul de var_dump și alte informații de depanare, către consola firebug. Principalul avantaj al acestei extensii este că toate informațiile de depanare sunt difuzate prin anteturi și nu împrăștie paginile și nu rupe în niciun fel logica aplicației.Site oficial: http://firephp.org/.

Ideea principală.

Algoritmul general de profilare este următorul:

1. La începutul paginii, activăm profilarea folosind xhprof_enable()
2. La sfârșitul paginii, dezactivați profilarea folosind xhprof_disable() și salvați datele colectate folosind save_run()
3. Apoi, folosind clasa firephp php, transmitem un link către datele de profilare către partea client
4. În consola firebug deschidem informațiile de care avem nevoie
5. ne bucuram :)

De asemenea, aș dori să spun că, desigur, adăugarea manuală a acestor funcții la scripturile dvs. PHP este grozavă. Dar vreau ca aceste informații să fie mereu la îndemână în timpul dezvoltării și să nu ajungă pe serverele de producție. Rezolvăm această problemă după cum urmează:

În proiectele noastre, în aproape toate scripturile, un fișier de lucru cu un încărcător de clasă, funcții de conectare și alte lucruri necesare este conectat la început. Prin urmare, am inclus includerea profilării în acest fișier. Și pentru a putea activa/dezactiva modul de depanare după bunul plac, am adăugat o verificare pentru constanta de configurare, plus că am împachetat aceste verificări în niște meta-etichete care sunt eliminate automat când proiectul este construit. Același lucru este valabil și pentru dezactivarea profilării și scrierea informațiilor în anteturi folosind firephp - aceste sarcini sunt rezolvate de o funcție, care este numită la sfârșitul fiecărui script PHP și este, de asemenea, înfășurată în meta-etichete. Arata cam asa:

// Următoarele constante sunt scrise în fișierul de configurare a aplicației

/** Modul de funcționare al mediului * */
define("APPLICATION_ENV" , "dev" ); // dev - depanare | pro - producție
/** Calea către profiler */
define("XHPROF_ROOT" , __DIR__ . „/ExtProcs/debug/xhprof-0.9.2”);

/***************************************************************************************
* În continuare, în fișierul care este încărcat la începutul fiecărui script, lansăm profilarea
* DEV_START și DEV_END sunt metaetichetele noastre, totul dintre ele este decupat în timpul asamblarii
***************************************************************************************/

//-- DEV_START
//-- în modul de depanare conectăm bibliotecile de depanare

// Încărcați firephp
require_once(__DIR__ . „/includes/ExtProcs/debug/firephp/FirePHP.class.php”);
//-- încărcați profilerul
„/xhprof_lib/utils/xhprof_lib.php”);
require_once(XHPROF_ROOT. „/xhprof_lib/utils/xhprof_runs.php”);
// Inițializați profilarea cu steagurile necesare. Descrierea detaliată a steagurilor
// poate fi găsit la php.net/manual/ru/xhprof.constants.php
xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);
}
//-- DEV_END

// Ei bine, această funcție este apelată la sfârșitul fiecărui script
// Apelul său este, de asemenea, împachetat în DEV_START și DEV_END

/**
* Creați un link către rezultatul profilării și afișați-l în consolă
*/
funcția dev_boot_Down() (
dacă (APPLICATION_ENV === „dev” ) (
// Inițializați instanța firephp
$firephp = FirePHP::getInstance(true);
// Dezactivează profilarea și salvează datele
$xhprof_data = xhprof_disable();
$xhprof_runs = nou XHProfRuns_Default();
$run_id = $xhprof_runs->save_run($xhprof_data, "xhprof_testing" );
// Creați un link către datele de profilare și scrieți-l în consolă
$link = "http://" . $_SERVER[„HTTP_HOST” ] . „/includes/ExtProcs/debug/xhprof-0.9.2/xhprof_html/index.php?run=($run_id)&source=xhprof_testing\n”;
$firephp->info($link, „date de profilare” );
}
}

* Acest cod sursă a fost evidențiat cu Sursa de evidențiere a codului.

Nu voi intra în detalii despre instalarea acestor extensii, pentru că totul este simplu aici. Voi spune doar câteva aspecte ale configurației. xhproof are o singură variabilă de configurare - xhprof.output_dir, care indică folderul în care vor fi salvate datele de profilare. Prin urmare, asigurați-vă că utilizatorul sub care sunt executate scripturile PHP are drepturi de scriere în directorul specificat. Deci, scrie ceva de genul acesta în php.ini-ul tău:

extensie=xhprof.so
xhprof.output_dir="/var/tmp/xhprof"

De asemenea, este o idee bună să instalați ceva precum dot sau Graphviz pentru a desena grafice de apel. Am Graphviz pe MacOS X.

După ce am finalizat procedurile descrise mai sus, am putut să deschidem și să ne uităm la profilarea oricăruia dintre scripturile noastre direct în browser în orice moment.

Profilarea aplicației este colectarea de date privind viteza de execuție a diferitelor secțiuni de program (fișiere și funcții). Există multe instrumente de profilare PHP disponibile, dar nu toate instrumentele sunt potrivite pentru a efectua analize direct pe un site de producție.

XHProf și fork-ul său Tideways este un profiler comod și simplu, care poate colecta eficient statistici despre funcționarea unei aplicații, fără aproape nicio reducere a vitezei aplicației dvs. (sau site-ului dvs.).

De ce codul de profil?

Dacă aplicația începe să funcționeze lent (a se citi „site-ul a început să încetinească”), profilarea vă va permite să aflați care parte este cea mai lentă. Rezultatul profilării este de obicei o listă de funcții executate împreună cu timpul lor de execuție.

Profilarea codului ar trebui să fie pe primul loc în procesul de optimizare a aplicației. Orice altceva ar fi o presupunere și cel mai probabil ar fi greșit. Trebuie să știți exact ce cauzează probleme și „frâne”.

Profilarea este o procedură de colectare și organizare a statisticilor despre timpul de execuție a codului. Acesta nu este un proces de optimizare sau modificare a programului. Rezultatul acestui proces este de obicei un raport extins privind componentele programului și statisticile de performanță a funcției.

Exact pentru asta a fost dezvoltată soluția XHProf. Este conceput pentru a funcționa pe site-uri web reale. Ideea principală a acestui profiler este de a crea o încărcare minimă a aplicației, colectând în același timp toate datele necesare privind viteza de funcționare. Soluția a fost dezvoltată de specialiști de la Facebook.

Cum se conectează automat php profiler?

Specialiștii noștri au muncit din greu și au făcut acest proces complet automatizat.
Trebuie doar să vă conectați, să selectați domeniul dorit în fila „Domenii”, să faceți clic pe pictograma „PHP.INI + PHP Profiler” și să activați caseta de selectare „Domain Profiler”.

Activarea acestei funcții poate dura ceva timp, de obicei nu mai mult de 10 minute.

Pentru versiunile php 5.2, 5.3, 5.4, 5.5, 5.6, 7.0 folosim profilerul XHProf, pentru versiunile php 7.1 si superioare folosim profilerul Tideways.

Odată activat, pe fiecare pagină a site-ului dvs. procesată de PHP, un bloc special cu link-uri către fișierul de raport va fi construit în partea de jos a acestuia (linkul va arăta cam așa:

Domain-name.com/xhprof-master/xhprof_html/index.php?run=XXXXXXXXXXXX&source=someapp)

Și iată cum va arăta fișierul de raport:

Tabelul conține o listă de funcții care au fost efectuate într-o singură pagină cu informații suplimentare:

• Apeluri - numărul și procentul apelurilor de funcții
• Incl. Wall Time - timpul de execuție al unei funcții cu funcții imbricate
• Excl. Wall Time - timpul de execuție a funcției fără funcții imbricate
• Incl. CPU - timp procesor cu funcții imbricate
• Excl. CPU - timp procesor fără funcții imbricate
• Incl. MemUse - consum de memorie cu funcții imbricate
• Excl. MemUse - consum de memorie fără funcții imbricate
• Incl. PeakMemUse - consum maxim de memorie cu funcții imbricate
• Excl. PeakMemUse - consum maxim de memorie fără funcții imbricate

Trebuie remarcat faptul că raportul construit folosind canalele de maree poate fi ușor diferit din punct de vedere vizual de acest raport, dar esența nu se schimbă.

Rapoarte grafice

Secțiunile codului care necesită mult resurse sunt evidențiate cu galben (medie) și roșu (cel mai greu). Acestea sunt acele secțiuni de cod care folosesc o mulțime de resurse în raport cu restul programului. Aceasta poate fi o funcție lentă sau mai multe apeluri către o funcție rapidă. În exemplul nostru, vedem că funcția mysqli_multi_query() este marcată cu roșu deoarece rulează cel mai lent.

Rapoarte agregate

Interfața XHProf vă permite, de asemenea, să vizualizați informații agregate din mai multe rapoarte simultan. Pentru a face acest lucru, run_id este transmis separat prin virgule:

Domain-name.com/xhprof-master/xhprof_html/index.php?run=XXXXXXXXXXXX,YYYYYYYYYYY&source=someapp

Caracteristici tehnice

Includerea automată a profilerului este implementată folosind directivele auto_append_file și auto_prepend_file, care conectează două fișiere php executabile:

— auto_append_file inițializează obiectul de colectare a statisticilor și își începe lucrul;

— auto_prepend_file completează colecția de statistici și generează un fișier de raport cu statistici (în format JSON);

Dacă exit() sau die() este apelat în timp ce scriptul dumneavoastră rulează, auto_prepend_file nu va fi executat. fișierul cu statistici nu va fi generatși un bloc cu link-uri către fișierul de raport nu va fi inclus în partea de jos a paginii.

1. Astfel, accesarea oricărei pagini procesate de php va declanșa crearea unui nou fișier de raport, așa că recomandăm dezactivarea profilelor după colectarea statisticilor (de obicei câteva ore), pentru a evita depășirea cotei de disc, care poate fi epuizată după generarea unui număr mare de rapoarte!
2. Important: profilerul va funcționa numai dacă site-ul este atașat la server printr-o cale standard, prin mijloace automate (adică folosind panoul de control al găzduirii), altfel trebuie să contactați suportul tehnic Hostland pentru a configura profilerul.
3. În modul automat, profilerul se conectează numai la numele de domeniu principal; profilerul nu este conectat automat la subdomenii.
4. În modul automat, profilerul colectează statistici numai pentru scripturile cu extensia .php și .php5
5. Nu este posibil să se garanteze funcționarea neîntreruptă a site-ului după conectarea profilelor PHP, prin urmare, dacă site-ul nu funcționează corect în timp ce profilerul este activat, acesta ar trebui dezactivat și profilarea continuată prin alte mijloace.

Să rezumam

Sperăm că acest instrument vă va ajuta să vă faceți site-urile și mai rapide pe Hostland hosting.

Articolul a folosit parțial materiale de la utilizatorul Den Golotyuk postate pe site

Acesta a arătat cum să instalați și să configurați xdebug și a acoperit câteva caracteristici de bază, cum ar fi îmbunătățirea rezultatului funcției var_dump() sau tipărirea unei urmăriri a stivei de apeluri la primirea unui mesaj de eroare. În a doua parte ne-am uitat la această caracteristică xdebug ca urmărire. Urmărirea conține toate apelurile la funcții și metode din program, timpul de pornire, opțional dimensiunea memoriei, parametrii trecuți și returnați. Un jurnal de urmărire vă poate ajuta să înțelegeți calea de execuție a unui program complex. În loc să inserați codul de depanare în program, activați sau dezactivați urmărirea acolo unde este necesar, apoi utilizați utilitare precum grep sau propriile aplicații PHP pentru a analiza fișierul jurnal.

În acest articol ne vom uita la profilare. La prima vedere, profilarea este similară cu urmărirea. Jurnalul de profilare nu este destinat oamenilor, nu este destinat să vizualizeze fluxul unui program, dar ne oferă date pentru analiza statistică a unui program care rulează.

Crearea unui jurnal de profilare

Mai jos este un scurt fragment din jurnalul de profilare generat de xdebug:

fl=php:intern
fn=php::define
106 3

Fl=C:\www\drupal\includes\bootstrap.inc
fn=require_once::C:\www\drupal\includes\bootstrap.inc
1 648
cfn=php::define
apeluri=1 0 0
13 6
cfn=php::define
apeluri=1 0 0
18 4
cfn=php::define
apeluri=1 0 0
23 2

După cum puteți vedea, jurnalul de profilare nu poate fi citit direct. Vom folosi instrumente suplimentare pentru a vizualiza și analiza datele obținute. Deci, profilarea arată de câte ori a fost lansată o anumită linie și cât timp a durat lansarea.
Crearea unui jurnal de profilare degradează foarte mult performanța, similar cu crearea unui jurnal de urmărire, deoarece este necesar să se descrie trecerea fiecărei linii. Prin urmare, la fel ca și în cazul urmăririi, nu rulați profilarea pe serverele de producție... Cu toate acestea, există cazuri când profilarea trebuie rulată pe un sistem live. În acest caz, aveți grijă să rulați xdebug simultan cu alte extensii Zend, cum ar fi încărcătoare, optimizatoare sau cache.
Pentru ca xdebug să înceapă înregistrarea jurnalelor de profilare, adăugați

Vă rugăm să rețineți că nu puteți rula profilarea la momentul pornirii rulând o comandă.
Deoarece jurnalul de profilare este destinat să fie citit de programele de analiză, nu există setări suplimentare care vă permit să afișați informații suplimentare, așa cum este cazul jurnalului de urmărire. Cu toate acestea, există unele setări care vă permit să configurați profilarea, similare cu cele pe care le-am folosit la configurarea urmăririi.
În primul rând, xdebug scrie jurnalul de profilare în directorul /tmp în mod implicit. Dacă utilizați Windows, trebuie să remediați php.ini, astfel:

xdebug.profiler_output_dir="c:\traces"

Implicit, xdebug suprascrie jurnalul de profilare existent. Îl puteți configura pentru a-l completa pe cel existent adăugând următoarea comandă

în php.ini. Există cazuri în care nu doriți să creați un jurnal de profilare pentru toate fișierele, dar, în același timp, activarea profilării în timpul execuției este problematică. În loc să activați și să dezactivați periodic profilarea, adăugați comanda

xdebug.profiler_enable_trigger=Activat

în php.ini. Acum puteți activa și dezactiva profilarea prin transmiterea unui parametru special GET sau POST XDEBUG_PROFILE unui script PHP. Aceasta va activa profilarea numai pentru acest script PHP. Nu este necesar să setați valoarea acestui parametru, nu uitați să adăugați acest parametru la adresa test.php?XDEBUG_PROFILE.

Nume jurnal de profilare

Numele pe care xdebug îl atribuie jurnalului de profilare în mod implicit este „cachegrind.out”. plus identificatorul de proces. La fel ca și în cazul jurnalului de urmărire, puteți schimba numele jurnalului adăugând setările corespunzătoare la php.ini. Nume parametru xdebug.profiler_output_name. Argumentul este un șir. care poate conţine diverşi modificatori. Cele mai importante sunt mai jos:

• %p – identificatorul procesului
• %r – număr aleator
• %u - timp
• %H – valoarea lui $_SERVER[„HTTP_HOST”]
• %R – valoarea lui $_SERVER[„REQUEST_URI”]
• %s – numele, inclusiv calea completă, barele oblice sunt convertite în litere de subliniere

Vă rugăm să rețineți că modificatorul %s este folosit doar pentru xdebug.profiler_output_name. Dacă doriți să aflați numele jurnalului de profilare, puteți apela funcția xdebug_get_profiler_filename().

Analiza jurnalului de profilare
După cum am menționat mai sus, pentru a analiza jurnalul de profilare, sunt necesare programe suplimentare pentru vizualizarea datelor. Toate jurnalele de profilare pe care le creează xdebug sunt într-un format similar cu formatul Cachegrind. Cachegrind este un profiler care face parte dintr-un program mai puternic numit Valgrind, un program software de depanare și profilare pentru Linux. Cachegrind a fost conceput pentru a analiza statisticile cache-urilor, utilizarea memoriei și comenzile programului. Un alt instrument Valgrind, Callgrind, desenează grafice de apel. În ceea ce privește PHP, putem folosi această aplicație pentru a vizualiza și analiza jurnalul de profilare.
Instrumentul care este utilizat în mod obișnuit pentru a analiza jurnalul de profilare generat de xdebug se numește . KCachegrind este un software liber licențiat conform GPL (funcționează numai pe sisteme Unix). Cu toate acestea, există un program simplu pentru Windows, care este și gratuit. Să ne uităm mai întâi la versiunea Windows.

WinCacheGrind: analiza jurnalelor de profilare în Windows

Versiunea actuală (la momentul scrierii de către autorul acestui articol) a WinCachegrind este 1.0.0.12. Această versiune datează din 2005, ceea ce înseamnă că WinCachegrind nu a fost dezvoltat de mult timp. Dacă te uiți la notele de lansare, autorii scriu că programul are bug-uri care uneori îl fac să se comporte ciudat.
Prin urmare, recomand să utilizați KCachegrind, lansat pe baza unei mașini virtuale pe cea mai recentă distribuție Linux, de exemplu Ubuntu (nota traducătorului, în general vorbind, o recomandare ciudată; în acest caz, aș recomanda doar instalarea Linux, și nu gard în grădina mașinilor virtuale). Există un număr mare de mașini virtuale disponibile sub Windows. Dacă nu este posibil să utilizați Unix sau o mașină virtuală dintr-un anumit motiv, puteți continua să utilizați WinCachegrind pentru o analiză simplă a jurnalului de profilare. WinCachegrind nu desenează grafice de apel, spre deosebire de KCachegrind.
Instalarea Wincachegrind este extrem de ușoară. Rulați programul de instalare, faceți clic pe butonul pentru a accepta licența și instalarea este completă. Acum puteți rula programul și deschide unul dintre jurnalele de profilare cachegrind create de xdebug.

Făcând clic pe ceas sau pe pictograma sigma, puteți comuta între afișarea informațiilor în valori absolute și procente. Afișajul procentual arată cât timp, ca procent din timpul total, este nevoie pentru a apela o funcție dintr-un anumit bloc.
Două setări utile sunt Profiler -> Hide Fast Functions și Profiler -> Hide Library Functions. Primul comutator ascunde funcții a căror contribuție în timp la timpul general de execuție a programului este nesemnificativă.
A doua setare, Profiler -> Hide Library Functions, ascunde funcțiile încorporate în PHP din analiza generală. Când ambele setări sunt activate, vedeți mai puține date, permițându-vă să vă concentrați asupra zonelor din cod care necesită optimizare.
Fereastra principală conține două file: Linie cu linie și General. Ambele file afișează aceleași informații, dar fila Overall reunește informațiile pentru o prezentare mai bună. Timpul propriu afișează timpul de rulare al codului în blocul curent, în timp ce Timpul cumulat (Cum.) arată timpul total de rulare al funcțiilor din blocul dat.

KCacheGrind: analiza jurnalelor de profilare în Unix

Versiunea Unix a KCachegrind oferă mai multe funcționalități decât WinCachegrind. KCachegrind vizualizează datele și construiește un grafic de apel.
Pentru a începe să-l utilizați, trebuie să instalați KCachegrind. Versiune curentă . Este disponibilă o versiune mai nouă (0.10.1), dar face parte din pachetul Valgrind.
Dacă este posibil, utilizați un manager de pachete pentru a instala pachetul KCachegrind. KCachegrind folosește GraphViz pentru a desena grafice de apel, așa că trebuie să instalați și pachetul GraphViz dacă managerul de pachete nu instalează automat pachete dependente.
Dacă nu găsiți pachetul binar KCachegrind, va trebui să compilați singur KCachegrind. După descărcarea surselor, rulați

./configure --prefix=/opt/kde3
face
face instalarea

După cum puteți observa, trebuie să specificați calea către instalarea curentă a bibliotecii KDE. Dacă nu știți unde se află bibliotecile KDE pe sistemul dvs., utilizați

pentru a afișa calea către bibliotecile KDE.
Odată instalat, puteți rula KCacheGrind din linia de comandă

Afișarea tabelară a datelor în KCachegrind este foarte asemănătoare cu WinCachegrind. De asemenea, puteți comuta între valori absolute și procentuale. Unele caracteristici KCachegrind nu sunt concepute pentru PHP. Imaginea de mai jos arată graficul apelurilor programului phpMyAdmin:

După cum puteți vedea, cea mai mare parte a timpului de pornire a fost petrecut în common.inc.php. Următoarea captură de ecran arată o vizualizare a apelurilor de funcții în interiorul common.inc.php:

Acest bloc de cod rulează două require_onces, adică jumătate din timpul necesar pentru a rula common.inc.php. Făcând dublu clic pe orice dreptunghi, veți aprofunda analiza datelor.

Optimizarea codului pe baza datelor de profilare

Întotdeauna profilați aplicațiile înainte de optimizare. Optimizarea o poti incepe singur, in locul in care ti se pare ca aceasta optimizare va aduce un efect, dar acest lucru nu este intotdeauna adevarat. Optimizarea are efect în principal doar în acele părți care ocupă cel mai mult timp în procesul de execuție.
Dacă executați mai multe copii ale unui program în același timp, poate fi necesar să optimizați partea din program care ocupă cea mai mare parte a timpului de execuție. În acest caz, optimizarea nu va face servirea unei cereri individuale mai rapidă, dar va permite serverului dvs. să gestioneze sarcini mari, consumând în același timp mai puține resurse pentru a deservi aceste solicitări.
Când vă uitați la duratele rulării profilerului, rețineți că valorile absolute sunt mai puțin importante decât valorile relative. Măsurate pe diferite sisteme, valorile absolute pot varia. Cu toate acestea, înainte de a începe optimizarea codului, luați în considerare următoarele lucruri.
O regulă importantă în optimizare este reducerea numărului de operațiuni I/O. Unele operațiuni I/O necesită mult timp în comparație cu calculele. Reducerea unor astfel de operațiuni poate fi o modalitate foarte eficientă de a vă accelera programul. Eliminarea unui apel I/O poate oferi o îmbunătățire mai eficientă decât petrecerea multor ore pentru optimizarea codului. Prin urmare, ar trebui să vă concentrați mai întâi pe operațiunile I/O înainte de a începe codarea.
De asemenea, puteți crește numărul de servere înainte de optimizare. Puteți cumpăra unul uriaș, care vă va oferi o mică creștere a productivității. Timpul de dezvoltare este mai scump decât prețul unui server nou. Și dacă creșteți cantitatea de hardware, puteți fi sigur că veți obține imediat creșterea fără niciun impact asupra codului PHP. Când un dezvoltator petrece una sau două zile optimizând codul, nu poți spune niciodată cât de mult va crește productivitatea. Și până la urmă, nu mai poți fi sigur că optimizarea nu va aduce nicio eroare.
Conversia unor pagini în pagini statice este o modalitate de a obține performanțe mai bune. Să presupunem că există un site cu mult trafic, unde un script PHP creează prima pagină pentru fiecare solicitare, selectând informații dintr-o bază de date sau fișier XML. Dacă datele dintr-o pagină se modifică suficient de frecvent, puteți recrea o copie statică a acesteia. Dacă conversia într-o vizualizare statică nu este posibilă pentru o pagină (unele informații personale sunt afișate pe pagină), puteți converti unele blocuri în vizualizare statică.
Un alt nivel de optimizare nu necesită schimbarea codului PHP. După cum știm, PHP este un limbaj interpretat. Aceasta înseamnă că comenzile sale sunt traduse în timpul execuției în cod intermediar. Difuzarea se repetă de fiecare dată când rulează scriptul. Acest lucru face ca PHP să fie mai lent în comparație cu limbaje precum C sau Java, care nu necesită analizarea codului de fiecare dată când îl rulați. Pentru PHP, puteți folosi cache-urile de reprezentare intermediară (vezi traducerea mea....) pentru a salva și reutiliza codul intermediar, acest lucru face pornirea și execuția mai rapide.
Toate acestea nu înseamnă că nu este momentul sau locul pentru optimizarea codului PHP. Unele optimizări ale codului pot îmbunătăți considerabil performanța. Cu toate acestea, rețineți întotdeauna că schimbarea codului implică întotdeauna riscul de a introduce erori și probleme de securitate suplimentare. De asemenea, rețineți că optimizarea codului îl face mai puțin lizibil.

Concluzie

Crearea și vizualizarea unui jurnal de profilare este una dintre condițiile importante pentru optimizarea codului PHP. Trebuie să știți care locuri din program iau cel mai mult timp și de aici ar trebui să începeți optimizarea.
În articolul următor ne vom uita la depanarea folosind xdebug. xdebug vă poate oferi posibilitatea de a face depanare la distanță. Folosind un client care are această capacitate, cum ar fi Eclipse PDT, puteți să vă depanați codul fără a-l schimba, să setați puncte de întrerupere, să treceți prin secțiuni de cod și să vedeți cum și unde variabilele își schimbă valorile.

O extensie pentru PHP numită Xdebug este disponibilă pentru a ajuta la profilarea aplicațiilor PHP, precum și la depanarea în timp de execuție. La rularea profilelor, rezultatul este scris într-un fișier într-un format binar numit „cachegrind”. Pe fiecare platformă sunt disponibile aplicații pentru a analiza aceste fișiere. Nu sunt necesare modificări ale codului aplicației pentru a efectua această profilare.

Pentru a activa profilarea, instalați extensia și ajustați setările php.ini. Unele distribuții Linux vin cu pachete standard (de exemplu, pachetul php-xdebug al Ubuntu). În exemplul nostru vom rula profilul opțional pe baza unui parametru de solicitare. Acest lucru ne permite să păstrăm setările statice și să pornim profiler-ul numai după cum este necesar.

# php.ini settings # Setați la 1 pentru a-l activa pentru fiecare solicitare xdebug.profiler_enable = 0 # Să folosim un parametru GET/POST pentru a porni profilerul xdebug.profiler_enable_trigger = 1 # Valoarea GET/POST pe care o vom transmite ; gol pentru orice valoare xdebug.profiler_enable_trigger_value = "" # Ieșiți fișierele cachegrind în /tmp, astfel încât sistemul nostru să le curețe mai târziu xdebug.profiler_output_dir = "/tmp" xdebug.profiler_output_name = "cachegrind.out.%p"

Apoi utilizați un client web pentru a face o solicitare către adresa URL a aplicației dvs. pe care doriți să o profilați, de ex.

Http://example.com/article/1?XDEBUG_PROFILE=1

Pe măsură ce pagina se procesează, va scrie într-un fișier cu un nume similar cu

/tmp/cachegrind.out.12345

În mod implicit, numărul din numele fișierului este id-ul procesului care l-a scris. Acesta este configurabil cu setarea xdebug.profiler_output_name.

Rețineți că va scrie un fișier pentru fiecare cerere / proces PHP care este executat. Deci, de exemplu, dacă doriți să analizați o postare de formular, va fi scris un profil pentru solicitarea GET pentru a afișa formularul HTML. Parametrul XDEBUG_PROFILE va trebui să fie trecut în cererea POST ulterioară pentru a analiza a doua cerere care procesează formularul. Prin urmare, la profilare, uneori este mai ușor să rulați curl pentru a POST direct un formular.

Analizând ieșirea

Odată scris, memoria cache a profilului poate fi citită de o aplicație precum sau Webgrind. PHPStorm, un IDE PHP popular, poate afișa și aceste date de profilare.

KCachegrind, de exemplu, va afișa informații, inclusiv:

• Funcții executate
• Timpul apelului, atât propriu-zis, cât și inclusiv apelurile de funcții ulterioare
• De câte ori este apelată fiecare funcție
• Apelați grafice
• Legături către codul sursă

Ce anume sa cauti

În mod evident, reglarea performanței este foarte specifică cazurilor de utilizare ale fiecărei aplicații. În general, este bine să căutați:

• Apeluri repetate la aceeași funcție pe care nu v-ați aștepta să o vedeți. Pentru funcțiile care procesează și interogează date, acestea ar putea fi oportunități principale pentru ca aplicația dvs.
• Funcții de funcționare lentă. Unde își petrece aplicația cea mai mare parte a timpului? cel mai bun profit în reglarea performanței este concentrarea pe acele părți ale aplicației care consumă cel mai mult timp.

Notă: Xdebug, și în special caracteristicile sale de profilare, consumă foarte mult resurse și încetinesc execuția PHP. Este recomandat să nu rulați acestea într-un mediu de server de producție.