PHP kód profilozása. XHProf és xDebug - PHP kód profilozása További értelmező paraméterek használata

Az xhprof telepítése php-hez:

Sudo apt-get install php5-xhprof

Indítsa újra az Apache-ot:

A Sudo szolgáltatás apache2 újraindítása

phpinfo(); és ellenőrizze, hogy a modul csatlakoztatva van-e vagy sem?

Ellenőrizzük az /etc/php5/apache2/conf.d fájlt, hogy ott van-e link az xhprof.ini konfigurációhoz.

Ha nem, akkor hozza létre saját maga a hivatkozást, és indítsa újra az Apache-ot.

Sudo ln -s /etc/php5/mods-available/xhprof.ini /etc/php5/apache2/conf.d/20-xhprof.ini sudo szolgáltatás apache2 újraindítása

Ellenőrizzük az xhprof kapcsolatot, ellenőrizzük, hogy a 20-xhprof.ini csatlakoztatva van-e:

A képernyőképen a 0.9.2-es verzió látható, bár a telepítés során a 0.9.4-es verzió jelent meg, de ez nem akadály számunkra.

Most profilozhatjuk kódunkat.

1. Az oldal elején engedélyezze a profilalkotást az xhprof_enable();
2. Az oldal végén kapcsolja ki a profilalkotást az xhprof_disable() segítségével, és mentse az összegyűjtött adatokat a save_run() paranccsal;
3. Ezután elemezzük.

Funkció xhprof_enable() jelzőket veszi argumentumként:

XHPROF_FLAGS_CPU processzorstatisztikák rögzítéséhez,

XHPROF_FLAGS_MEMORY - a memóriához,

XHPROF_FLAGS_NO_BUILTINS - a beépített funkciók figyelmen kívül hagyásához.

A mentéshez és a további lekérdezéshez telepítenünk kell egy profilelemző eszközt.

Töltse le az archívumot az elemző eszközzel az xhprof: oldalról, vegye át a 0.9.4-es verziót.

A szerveren vagy a helyi számítógépen hozzon létre egy localhost-on keresztül elérhető mappát vagy egy külön tartományt, amelybe kicsomagoljuk a letöltött archívumot:

Most már menthetjük a profilt.

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

A követőkód valahogy így néz ki:

// A profilozó inicializálása - a processzoridőt és a memóriafogyasztást is számoljuk xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);
// Profilkód # A profilkészítő leállítása $xhprof_data = xhprof_disable(); # Mentse el a jelentést, és hozzon létre egy hivatkozást a megtekintéséhez 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 = new XHProfRuns_Default(); $run_id = $xhprof_runs->save_run($xhprof_data, "xhprof_test"); echo "Jelentés: http://localhost/xhprof-0.9.4/xhprof_html/index.php?run=$run_id&source=xhprof_test"; echo "\n";

/var/www/html/xhprof-0.9.4 - annak a mappának az elérési útja, ahol kicsomagoltuk a szükséges könyvtárakat.

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

Így néz ki egy profilelemzés. Ez a táblázat megjeleníti az összes profilozott függvényhívást.

A táblázat címsoraira kattintva rendezhetjük a függvényeket.

Ha azt látjuk, hogy valamelyik függvény többször vagy nagyon sokáig fut, akkor erre a függvényre kattintva megnyílik egy hasonló táblázat, de belső hívásokkal a kérdéses függvényen belül és azon a szülőkörnyezeten belül, ahol a függvényt meghívták.

Mutatók:
Total Inc. Wall Time (a funkciók végrehajtására fordított idő, figyelembe véve a socketekből, fájlrendszerből és egyéb erőforrásokból érkező válaszok várakozását)
Total Inc. CPU (a funkciók végrehajtására fordított idő)
Total Inc. MemUse (memóriahasználat)
Total Inc. PeakMemUse (csúcs memóriahasználat)
Funkcióhívások száma

Lehetőség van a jelentés grafikus megjelenítésére is. Ehhez azonban meg kell győződnie arról, hogy telepítve van a graphviz könyvtár:

Apt-get install graphviz

Ezután a profilodban kattints a megjelenítéshez, és íme:

Most már elemezheti és javíthatja a kódot.

A FirePHP a firebug kiterjesztése, amely a kis php osztályával együtt lehetővé teszi, hogy adatokat sugározzon a php-ről, például mindenféle var_dump-ot és egyéb hibakeresési információkat a firebug konzolra Minden hibakeresési információ a fejléceken keresztül kerül továbbításra, és nem szennyezi az oldalakat, és semmilyen módon nem töri meg az alkalmazás logikáját: http://firephp.org/.

Fő gondolat.

Az általános profilalkotási algoritmus a következő:

1. Az oldal elején engedélyezze a profilalkotást az xhprof_enable() segítségével
2. Az oldal végén kapcsolja ki a profilalkotást az xhprof_disable() segítségével, és mentse az összegyűjtött adatokat a save_run() paranccsal.
3. Ezt követően a firephp php osztály használatával egy hivatkozást adunk át a profilozási adatokra a kliens résznek
4. A firebug konzolban megnyitjuk a szükséges információkat
5. Örülünk :)

Azt is szeretném elmondani, hogy természetesen nagyszerű, ha ezeket a funkciókat kézzel adjuk hozzá a PHP-szkriptekhez. De azt szeretném, hogy ezek az információk mindig kéznél legyenek a fejlesztés során, és ne kerüljenek az éles szerverekre. Ezt a problémát a következőképpen oldjuk meg:

Projektjeinkben szinte minden szkriptben már az elején be van kötve egy munkafájl osztálybetöltővel, összekötő funkciókkal és egyéb szükséges dolgokkal. Ezért ebbe a fájlba belefoglaltuk a profilalkotást. És annak érdekében, hogy tetszés szerint be- és kikapcsolhassuk a hibakeresési módot, hozzáadtunk egy ellenőrzést a konfigurációs állandóhoz, és ezeket az ellenőrzéseket néhány metacímkébe csomagoltuk, amelyeket a projekt felépítésekor automatikusan eltávolítanak. Ugyanez vonatkozik a profilalkotás kikapcsolására és a fejlécekbe való információ írására firephp segítségével - ezeket a feladatokat egy függvény oldja meg, amely minden PHP szkript végén meghívódik, és szintén meta tagokba van csomagolva. Valahogy így néz ki:

// A következő állandók az alkalmazás konfigurációs fájljában vannak beírva

/** A környezet működési módja * */
define("APPLICATION_ENV" , "dev" ); // dev - hibakeresés | pro - produkció
/** A profilkészítő elérési útja */
define("XHPROF_ROOT" , __DIR__ . "/ExtProcs/debug/xhprof-0.9.2");

/***************************************************************************************
* Ezután az egyes szkriptek elején betöltött fájlban elindítjuk a profilalkotást
* A DEV_START és a DEV_END a metacímkéink, a köztük lévő mindent kivágunk az összeállítás során
***************************************************************************************/

//-- DEV_START
//-- debug módban hibakereső könyvtárakat kapcsolunk

// Firephp betöltése
igényel_egyszer(__DIR__ . "/includes/ExtProcs/debug/firephp/FirePHP.class.php");
//-- betölti a profilozót
"/xhprof_lib/utils/xhprof_lib.php");
igényel_egyszer(XHPROF_ROOT. "/xhprof_lib/utils/xhprof_runs.php");
// A profilalkotás inicializálása a szükséges jelzőkkel. A zászlók részletes leírása
// a php.net/manual/ru/xhprof.constants.php címen található
xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);
}
//-- DEV_END

// Nos, ez a függvény minden szkript végén meghívásra kerül
// A hívása a DEV_START és a DEV_END nyelvekre is kiterjed

/**
* Hozzon létre egy hivatkozást a profilalkotás eredményéhez, és jelenítse meg a konzolon
*/
függvény dev_boot_Down() (
if (APPLICATION_ENV === "fejlesztő" ) (
// Inicializálja a firephp példányt
$firephp = FirePHP::getInstance(true);
// Profilozás kikapcsolása és adatok mentése
$xhprof_data = xhprof_disable();
$xhprof_runs = new XHProfRuns_Default();
$run_id = $xhprof_runs->save_run($xhprof_data, "xhprof_testing" );
// Hozzon létre egy hivatkozást a profilozási adatokhoz, és írja be a konzolba
$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, "profilozási adatok" );
}
}

* Ezt a forráskódot a Source Code Highlighter kiemelte.

Nem megyek bele a bővítmények telepítésének részleteibe, mert minden egyszerű. Csak a beállítás néhány szempontjáról szólok. Az xhproof-nak csak egy konfigurációs változója van - az xhprof.output_dir, amely arra a mappára mutat, ahová a profilozási adatok mentésre kerülnek. Ezért győződjön meg arról, hogy a felhasználó, aki alatt a PHP-szkriptek végrehajtásra kerülnek, rendelkezik-e írási jogokkal a megadott könyvtárba. Tehát írj valami ilyesmit a php.ini-be:

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

Nem rossz ötlet például a dot vagy a Graphviz telepítése a hívási grafikonok rajzolásához. Graphviz van MacOS X-en.

A fent leírt eljárások elvégzése után bármikor megnyithattuk és megtekinthettük bármelyik szkriptünk profilozását közvetlenül a böngészőben.

Az alkalmazásprofilozás a különböző programrészek (fájlok és függvények) végrehajtási sebességére vonatkozó adatok gyűjtése. Számos PHP profilkészítő eszköz áll rendelkezésre, de nem minden eszköz alkalmas közvetlenül a termelési helyszínen történő elemzés elvégzésére.

Az XHProf és forkja A Tideways egy kényelmes és egyszerű profilkészítő, amely hatékonyan gyűjthet statisztikákat egy alkalmazás működéséről anélkül, hogy az alkalmazás (vagy a webhely) sebessége szinte csökkenne.

Miért a profilkód?

Ha az alkalmazás lassan kezd működni (lásd: „a webhely lassulni kezdett”), a profilozás lehetővé teszi, hogy megtudja, melyik rész a leglassabb. A profilalkotás eredménye általában a végrehajtott függvények listája a végrehajtási idővel együtt.

A kódprofilozásnak első helyen kell lennie az alkalmazásoptimalizálási folyamatban. Minden más csak találgatás lenne, és valószínűleg rossz. Tudnia kell, hogy pontosan mi okozza a problémákat és a „féket”.

A profilalkotás a kód végrehajtási idejére vonatkozó statisztikák gyűjtésére és rendszerezésére szolgáló eljárás. Ez nem optimalizálási vagy programmódosítási folyamat. Ennek a folyamatnak az eredménye általában egy kiterjesztett jelentés a programösszetevőkről és a funkció teljesítménystatisztikáiról.

Az XHProf megoldást pontosan erre fejlesztették ki. Úgy tervezték, hogy valódi webhelyeken működjön. Ennek a profilozónak az a fő ötlete, hogy minimális terhelést hozzon létre az alkalmazáson, miközben összegyűjti az összes szükséges adatot a működési sebességről. A megoldást a Facebook szakemberei fejlesztették ki.

Hogyan lehet automatikusan csatlakoztatni a php profilert?

Szakembereink keményen dolgoztak, és ezt a folyamatot teljesen automatizálták.
Csak be kell jelentkeznie, válassza ki a kívánt tartományt a „Domains” fülön, kattintson a „PHP.INI + PHP Profiler” ikonra, és engedélyezze a „Domain Profiler” jelölőnégyzetet.

A funkció bekapcsolása eltarthat egy ideig, általában nem több 10 percnél.

A php 5.2-es, 5.3-as, 5.4-es, 5.5-ös, 5.6-os, 7.0-s verzióihoz az XHProf profilozót, a 7.1-es és újabb php verziókhoz a Tideways profilozót használjuk.

Miután engedélyezte, webhelyének minden PHP által feldolgozott oldalán egy speciális blokk kerül beépítésre a jelentésfájlra mutató hivatkozásokkal (a link így fog kinézni):

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

A jelentésfájl pedig így fog kinézni:

A táblázat az egy oldalon belül végrehajtott funkciók listáját tartalmazza további információkkal:

• Hívások – a függvényhívások száma és százalékos aránya
• Incl. Wall Time – beágyazott függvényekkel rendelkező függvény végrehajtási ideje
• Excl. Wall Time – a függvény végrehajtási ideje beágyazott függvények nélkül
• Incl. CPU - processzoridő beágyazott függvényekkel
• Excl. CPU - processzoridő beágyazott funkciók nélkül
• Incl. MemUse - memóriafelhasználás beágyazott függvényekkel
• Excl. MemUse - memóriafelhasználás beágyazott függvények nélkül
• Incl. PeakMemUse – maximális memóriafogyasztás beágyazott függvényekkel
• Excl. PeakMemUse - maximális memóriafogyasztás beágyazott funkciók nélkül

Megjegyzendő, hogy az árapályok segítségével készített jelentés vizuálisan kissé eltérhet ettől a jelentéstől, de a lényeg nem változik.

Grafikus riportok

A kód erőforrásigényes szakaszai sárga (közepes) és piros (legnehezebb) színnel vannak kiemelve. Ezek a kódrészletek, amelyek sok erőforrást használnak a program többi részéhez képest. Ez lehet egy lassú függvény, vagy több gyors függvény hívása. Példánkban azt látjuk, hogy a mysqli_multi_query() függvény piros színnel van megjelölve, mert az fut a leglassabban.

Összesített jelentések

Az XHProf felület lehetővé teszi több jelentés összesített információinak egyidejű megtekintését is. Ehhez a run_id vesszővel elválasztva kerül átadásra:

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

Műszaki jellemzők

A profilkészítő automatikus felvétele az auto_append_file és auto_prepend_file direktívák segítségével valósul meg, amelyek két végrehajtható php fájlt kötnek össze:

— az auto_append_file inicializálja a statisztikagyűjtő objektumot és megkezdi a munkáját;

— az auto_prepend_file befejezi a statisztikák gyűjtését, és jelentésfájlt generál statisztikákkal (JSON formátumban);

Ha az exit() vagy a die() meghívásra kerül, miközben a szkript fut, az auto_prepend_file nem kerül végrehajtásra. statisztikai fájl nem jön létreés a jelentésfájlra mutató hivatkozásokat tartalmazó blokk nem jelenik meg az oldal alján.

1. Így a php által feldolgozott bármely oldal elérése egy új jelentésfájl létrehozását indítja el, ezért javasoljuk a profilozó letiltását a statisztikák összegyűjtése után (általában néhány óra múlva), hogy elkerüljük a lemezkvóta túlcsordulását, amely a lemezkvóta kimerülése után nagyszámú riport!
2. Fontos: a profilkészítő csak akkor fog működni, ha a webhely szabványos útvonalon, automatikus úton (vagyis a hosting vezérlőpult használatával) csatlakozik a szerverhez, ellenkező esetben fel kell vennie a kapcsolatot a Hostland műszaki támogatásával a profilkészítő konfigurálásához.
3. Automatikus módban a profilkészítő csak a fő tartománynévhez csatlakozik, a profilkészítő nem kapcsolódik automatikusan az aldomainekhez.
4. Automatikus módban a profilkészítő csak a .php és .php5 kiterjesztésű szkriptekről gyűjt statisztikákat
5. A PHP profilkészítő csatlakoztatása után nem garantálható az oldal zavartalan működése, ezért ha az oldal nem működik megfelelően a profilkészítő bekapcsolt állapotában, akkor azt le kell tiltani és a profilalkotást más módon kell folytatni.

Foglaljuk össze

Reméljük, hogy ez az eszköz segít még gyorsabbá tenni webhelyeit a Hostland tárhelyen.

A cikk részben a Den Golotyuk felhasználótól származó anyagokat használt, amelyeket a webhelyen tett közzé

Megmutatta, hogyan kell telepíteni és konfigurálni az xdebug-ot, és bemutatott néhány alapvető funkciót, például a var_dump() függvény kimenetének javítását vagy a hívási verem nyomkövetésének kinyomtatását hibaüzenet esetén. A második részben ezt az xdebug funkciót követésnek tekintettük. A nyomkövetés tartalmazza az összes függvény- és metódushívást a programban, az indítási időt, opcionálisan a memória méretét, az átadott és visszaadott paramétereket. A nyomkövetési napló segíthet megérteni egy összetett program végrehajtási útvonalát. Ahelyett, hogy hibakereső kódot illesztene be a programba, szükség esetén be- vagy kikapcsolhatja a nyomkövetést, majd olyan segédprogramokkal, mint a grep vagy a saját PHP-alkalmazásaival elemezheti a naplófájlt.

Ebben a cikkben a profilalkotással foglalkozunk. Első pillantásra a profilalkotás hasonló a nyomkövetéshez. A profilalkotási napló nem embereknek készült, nem egy program folyamának megjelenítésére szolgál, hanem egy futó program statisztikai elemzéséhez szolgáltat adatokat.

Profilalkotási napló készítése

Az alábbiakban egy rövid részlet az xdebug által generált profilalkotási naplóból:

fl=php:belső
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
hívások=1 0 0
13 6
cfn=php::define
hívások=1 0 0
18 4
cfn=php::define
hívások=1 0 0
23 2

Mint látható, a profilalkotási napló közvetlenül nem olvasható. A kapott adatok megjelenítéséhez és elemzéséhez további eszközöket fogunk használni. Tehát a profilalkotás megmutatja, hogy egy adott vonal hányszor indult el, és mennyi ideig tartott az indítás.
A profilalkotási napló létrehozása nagymértékben rontja a teljesítményt, hasonlóan a nyomkövetési napló létrehozásához, mert le kell írni az egyes sorok áthaladását. Ezért, akárcsak a nyomkövetés esetében, ne futtassunk profilozást éles szervereken... Vannak azonban esetek, amikor a profilalkotást élő rendszeren kell futtatni. Ebben az esetben ügyeljen arra, hogy az xdebug-ot más Zend-bővítményekkel, például betöltőkkel, optimalizálókkal vagy gyorsítótárral egyidejűleg futtassa.
Ahhoz, hogy az xdebug elkezdje rögzíteni a profilalkotási naplókat, adja hozzá

Kérjük, vegye figyelembe, hogy parancs futtatásával nem futtathatja a profilalkotást az indításkor.
Mivel a profilalkotási naplót az elemző programoknak kell olvasniuk, nincsenek további beállítások, amelyek lehetővé tennék további információk megjelenítését, mint a nyomkövetési napló esetében. Vannak azonban olyan beállítások, amelyek lehetővé teszik a profilozás konfigurálását, hasonlóan azokhoz, amelyeket a nyomkövetés beállításakor használtunk.
Először is, az xdebug alapértelmezés szerint a /tmp könyvtárba írja a profilalkotási naplót. Ha Windowst használ, ki kell javítania a php.ini fájlt a következőképpen:

xdebug.profiler_output_dir="c:\traces"

Alapértelmezés szerint az xdebug felülírja a meglévő profilalkotási naplót. A következő parancs hozzáadásával konfigurálhatja úgy, hogy kiegészítse a meglévőt

a php.ini-ben. Vannak esetek, amikor nem akarunk minden fájlhoz profilozási naplót létrehozni, ugyanakkor a profilozás aktiválása futás közben problémás. A profilozás időszakos be- és kikapcsolása helyett adja hozzá a parancsot

xdebug.profiler_enable_trigger=Be

a php.ini-ben. Mostantól be- és kikapcsolhatja a profilalkotást egy speciális XDEBUG_PROFILE GET vagy POST paraméter átadásával egy PHP szkriptnek. Ez csak ehhez a PHP szkripthez engedélyezi a profilalkotást. Ennek a paraméternek az értékét nem szükséges beállítani, csak ne felejtse el hozzáadni ezt a paramétert a test.php?XDEBUG_PROFILE címhez.

Profilozási napló neve

Az xdebug a profilalkotási naplóhoz alapértelmezés szerint „cachegrind.out” rendelt név. plusz folyamatazonosító. Csakúgy, mint a nyomkövetési napló esetében, megváltoztathatja a napló nevét a megfelelő beállítások hozzáadásával a php.ini fájlhoz. Paraméter neve xdebug.profiler_output_name. Az argumentum egy karakterlánc. amelyek különféle módosítókat tartalmazhatnak. A legfontosabbak az alábbiak:

• %p – folyamatazonosító
• %r – véletlen szám
• %u - idő
• %H – $_SERVER["HTTP_HOST"] értéke
• %R – $_SERVER["REQUEST_URI"] értéke
• %s – név, beleértve a teljes elérési utat, a perjelek aláhúzásjelekké alakulnak

Kérjük, vegye figyelembe, hogy a %s módosító csak az xdebug.profiler_output_name esetén használható. Ha tudni szeretné a profilalkotási napló nevét, meghívhatja az xdebug_get_profiler_filename() függvényt.

Profilalkotási naplóelemzés
Mint fentebb említettük, a profilalkotási napló elemzéséhez további adatvizualizációs programokra van szükség. Az xdebug által létrehozott összes profilozási napló a Cachegrind formátumhoz hasonló formátumú. A Cachegrind egy profilkészítő, amely egy nagyobb teljesítményű Valgrind program része, amely egy szoftverhibakereső és -profilozó program Linuxhoz. A Cachegrind a gyorsítótárak, a memóriahasználat és a programparancsok statisztikáinak elemzésére készült. Egy másik Valgrind eszköz, a Callgrind, hívási grafikonokat rajzol. Ami a PHP-t illeti, ezt az alkalmazást használhatjuk a profilalkotási napló megjelenítésére és elemzésére.
Az xdebug által generált profilozási napló elemzésére általánosan használt eszköz az ún. A KCachegrind egy ingyenes, GPL licenc alatt álló szoftver (csak Unix rendszereken működik). Van azonban egy egyszerű program a Windows számára, amely szintén ingyenes. Nézzük először a Windows verziót.

WinCacheGrind: a profilalkotási naplók elemzése a Windows rendszerben

A WinCachegrind jelenlegi verziója (a cikk szerzője által írt) 1.0.0.12. Ez a verzió 2005-ig nyúlik vissza, ami azt jelenti, hogy a WinCachegrindet már régóta nem fejlesztették. Ha megnézzük a kiadási megjegyzéseket, a szerzők azt írják, hogy a programnak vannak olyan hibái, amelyek néha furcsán viselkednek.
Ezért javaslom a KCachegrind használatát, amely egy virtuális gép alapján indult el a legújabb Linux disztribúción, például az Ubuntuban (a fordító megjegyzése általában véve furcsa ajánlás; ebben az esetben csak a Linux telepítését javasolnám, nem pedig bekerítést). a virtuális gépek kertje). A Windows alatt hatalmas számú virtuális gép érhető el. Ha valamilyen okból nem lehetséges a Unix vagy egy virtuális gép használata, továbbra is használhatja a WinCachegrindet az egyszerű profilalkotási naplóelemzés érdekében. A WinCachegrind nem rajzol hívási gráfokat, ellentétben a KCachegrinddal.
A Wincachegrind telepítése rendkívül egyszerű. Futtassa a telepítőt, kattintson a gombra a licenc elfogadásához, és a telepítés kész. Most már futtathatja a programot, és megnyithatja az xdebug által létrehozott egyik cachegrind profilozási naplót.

Az órára vagy a szigma ikonra kattintva válthat az információk abszolút értékben és százalékban történő megjelenítése között. A százalékos kijelző megmutatja, hogy a teljes idő százalékában mennyi időbe telik egy függvény meghívása egy adott blokkban.
Két hasznos beállítás: Profiler -> Gyors funkciók elrejtése és Profiler -> Könyvtári funkciók elrejtése. Az első kapcsoló elrejti azokat a funkciókat, amelyek időbeli hozzájárulása a teljes programvégrehajtási időhöz jelentéktelen.
A második beállítás, a Profiler -> Hide Library Functions, elrejti a PHP-be épített függvényeket az általános elemzés elől. Ha mindkét beállítás engedélyezve van, kevesebb adatot lát, így a kód azon területeire összpontosíthat, amelyek optimalizálásra szorulnak.
A főablak két lapot tartalmaz: Soronként és Összességében. Mindkét lap ugyanazokat az információkat mutatja, de az Összesség lap összesíti az információkat a jobb megjelenítés érdekében. Az Self time a kód futási idejét jeleníti meg az aktuális blokkban, míg a kumulatív idő (Cum.) a függvények teljes futási idejét az adott blokkban.

KCacheGrind: profilalkotási naplók elemzése Unix rendszerben

A KCachegrind Unix verziója több funkcionalitást biztosít, mint a WinCachegrind. A KCachegrind megjeleníti az adatokat, és létrehoz egy hívási grafikont.
A használat megkezdéséhez telepítenie kell a KCachegrindet. Jelenlegi verzió . Elérhető egy újabb verzió (0.10.1), de ez a Valgrind csomag része.
Ha lehetséges, használjon csomagkezelőt a KCachegrind csomag telepítéséhez. A KCachegrind a GraphViz segítségével rajzolja meg a hívási grafikonokat, ezért telepítenie kell a GraphViz csomagot is, ha a csomagkezelő nem telepíti automatikusan a függő csomagokat.
Ha nem találja a KCachegrind bináris csomagot, magának kell lefordítania a KCachegrindet. A források letöltése után futtassa

./configure --prefix=/opt/kde3
készítsenek
telepítse

Mint láthatja, meg kell adnia a KDE könyvtár jelenlegi telepítésének elérési útját. Ha nem tudja, hol találhatók a KDE-könyvtárak a rendszeren, használja

a KDE-könyvtárak elérési útjának megjelenítéséhez.
A telepítés után a KCacheGrind parancssorból futtatható

Az adatok táblázatos megjelenítése a KCachegrindben nagyon hasonló a WinCachegrindhez. Válthat az abszolút és a százalékos értékek között is. Néhány KCachegrind szolgáltatás nem PHP-hez készült. Az alábbi képen a phpMyAdmin program hívási grafikonja látható:

Mint látható, az indítási idő nagy részét a common.inc.php-n belül töltötték. A következő képernyőképen a common.inc.php fájlban található függvényhívások láthatók:

Ez a kódblokk két követelmény_egyszert futtat, ami fele annyi idő, mint a common.inc.php futtatásához. Bármely téglalapra duplán kattintva mélyebbre viszi az adatelemzést.

Kódoptimalizálás profilalkotási adatok alapján

Optimalizálás előtt mindig profilozza meg alkalmazásait. Ön is elkezdheti az optimalizálást ott, ahol úgy tűnik, hogy ez az optimalizálás meghozza a hatását, de ez nem mindig igaz. Az optimalizálás elsősorban csak azokon a részeken fejti ki hatását, amelyek a legtöbb időt vesznek igénybe a végrehajtási folyamatban.
Ha egy program több példányát futtatja egyszerre, előfordulhat, hogy még mindig optimalizálnia kell a programnak azt a részét, amely a végrehajtási idő nagy részét foglalja el. Ebben az esetben az optimalizálás nem teszi gyorsabbá egy egyedi kérés kiszolgálását, de lehetővé teszi, hogy a szerver kezelje a nagy terheléseket, miközben kevesebb erőforrást használ fel a kérések kiszolgálására.
Amikor a profilkészítő futási időtartamait nézi, ne feledje, hogy az abszolút értékek kevésbé fontosak, mint a relatív értékek. Különböző rendszereken mérve az abszolút értékek változhatnak. Mielőtt azonban elkezdené a kód optimalizálását, vegye figyelembe a következőket.
Az optimalizálás fontos szabálya az I/O műveletek számának csökkentése. Egyes I/O műveletek nagyon időigényesek a számításokhoz képest. Az ilyen műveletek csökkentése nagyon hatékony módja lehet a program felgyorsításának. Egy I/O hívás eltávolítása hatékonyabb fejlődést eredményezhet, mintha sok órát töltene a kód optimalizálásával. Ezért a kódolás megkezdése előtt először az I/O műveletekre kell összpontosítania.
Az optimalizálás előtt növelheti a szerverek számát is. Vásárolhat egy hatalmasat, amivel kis mértékben növeli a termelékenységet. A fejlesztési idő drágább, mint egy új szerver ára. És ha növeli a hardver mennyiségét, akkor biztos lehet benne, hogy azonnal megkapja a növekedést anélkül, hogy bármilyen hatással lenne a PHP kódra. Amikor egy fejlesztő egy vagy két napot tölt a kód optimalizálásával, soha nem lehet megmondani, mennyivel nő a termelékenység. És a végén már nem lehet biztos abban, hogy az optimalizálás nem hoz semmilyen hibát.
Egyes oldalak statikus oldalakká alakítása a jobb teljesítmény elérésének egyik módja. Tegyük fel, hogy van egy nagy forgalmú oldal, ahol egy PHP szkript minden kéréshez létrehozza az első oldalt, kiválasztva az információkat egy adatbázisból vagy XML fájlból. Ha az oldalon lévő adatok elég gyakran változnak, újra létrehozhat egy statikus másolatot. Ha egy oldal esetében nem lehetséges a statikus nézetté konvertálás (néhány személyes információ megjelenik az oldalon), akkor egyes blokkokat statikus nézetté alakíthat.
Az optimalizálás egy másik szintje nem igényli a PHP kód módosítását. Mint tudjuk, a PHP egy értelmezett nyelv. Ez azt jelenti, hogy a parancsai futási időben köztes kódba kerülnek. Az adás minden alkalommal megismétlődik a szkript futtatásakor. Ez lassabbá teszi a PHP-t az olyan nyelvekhez képest, mint a C vagy a Java, amelyek nem igénylik a kód elemzését minden egyes futtatáskor. PHP esetén használhat köztes reprezentációs gyorsítótárakat (lásd a fordításomat...) a közbenső kód mentésére és újrafelhasználására, ami gyorsabbá teszi az indítást és a végrehajtást.
Mindez nem jelenti azt, hogy nem itt az ideje vagy helye a PHP kód optimalizálásának. Egyes kódoptimalizálások nagymértékben javíthatják a teljesítményt. Azonban mindig ne feledje, hogy a kód megváltoztatása mindig magában hordozza a további hibák és biztonsági problémák bevezetésének kockázatát. Ne feledje azt is, hogy a kód optimalizálása kevésbé olvashatóvá teszi azt.

Következtetés

A profilalkotási napló létrehozása és megjelenítése a PHP kód optimalizálásának egyik fontos feltétele. Tudnod kell, hogy a program mely helyei vesznek igénybe a legtöbb időt, és itt érdemes elkezdeni az optimalizálást.
A következő cikkben megvizsgáljuk az xdebug használatával végzett hibakeresést. Az xdebug lehetőséget biztosít a távoli hibakeresésre. Egy ilyen képességgel rendelkező kliens (például az Eclipse PDT) használatával hibakeresést végezhet a kódban anélkül, hogy azt megváltoztatná, töréspontokat állíthat be, átugorhat a kód szakaszain, és megnézheti, hogyan és hol változtatják meg a változók értékét.

A PHP Xdebug nevű kiterjesztése elérhető a PHP-alkalmazások profilalkotásában, valamint a futásidejű hibakeresésben. A profilkészítő futtatásakor a kimenet egy "cachegrind" nevű bináris formátumú fájlba kerül. Minden platformon elérhetők ezek a fájlok elemzésére szolgáló alkalmazások. A profilalkotás végrehajtásához nincs szükség az alkalmazáskód módosítására.

A profilalkotás engedélyezéséhez telepítse a bővítményt, és módosítsa a php.ini beállításait. Néhány Linux disztribúció szabványos csomagokkal érkezik (pl. az Ubuntu php-xdebug csomagja) Példánkban a profilt opcionálisan egy kérési paraméter alapján futtatjuk, és csak szükség szerint kapcsoljuk be a beállításokat.

# php.ini beállítások # Állítsa 1-re, hogy minden kérésnél bekapcsolja. xdebug.profiler_enable = 0 # Használjunk GET/POST paramétert a profiler bekapcsolásához. xdebug.profiler_enable_trigger = 1 # Az általunk továbbított GET/POST érték tetszőleges értékhez xdebug.profiler_enable_trigger_value = "" # A cachegrind fájlokat a /tmp fájlba írja ki, így rendszerünk később megtisztítja őket xdebug.profiler_output_dir = "/tmp" xdebug.profiler_output_name = "cachegrind.out.%p"

Ezután egy webes kliens segítségével kérjen az alkalmazásának profilozni kívánt URL-címére, pl.

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

Az oldal feldolgozása során a következőhöz hasonló nevű fájlba fog írni

/tmp/cachegrind.out.12345

Alapértelmezés szerint a fájlnévben szereplő szám az azt kiíró folyamatazonosító. Ez az xdebug.profiler_output_name beállítással konfigurálható.

Vegye figyelembe, hogy minden végrehajtott PHP kéréshez/folyamathoz egy fájlt ír. Így például, ha egy űrlapbejegyzést szeretne elemezni, egy profil lesz írva a GET kéréshez a HTML űrlap megjelenítéséhez. Az XDEBUG_PROFILE paramétert át kell adni a következő POST kérésnek az űrlapot feldolgozó második kérés elemzéséhez. Ezért a profilalkotás során néha könnyebb a curl futtatása az űrlap közvetlen POST-jához.

A kimenet elemzése

Miután megírta a profil-gyorsítótárat, egy alkalmazás, például vagy a Webgrind elolvashatja. A PHPStorm, egy népszerű PHP IDE is képes megjeleníteni ezeket a profiladatokat.

A KCachegrind például olyan információkat jelenít meg, mint:

• Funkciók végrehajtva
• Hívásidő, önmagában és a későbbi függvényhívásokkal együtt
• Az egyes függvények meghívásának száma
• Hívásgrafikonok
• Hivatkozások a forráskódhoz

Mit kell keresni

Nyilvánvaló, hogy a teljesítményhangolás nagyon egyedi az egyes alkalmazások használati eseteihez. Általában jó keresni:

• Az adatokat feldolgozó és lekérdező függvények ismételt hívása az alkalmazás gyorsítótárba helyezéséhez.
• Lassú futású funkciók. Hol tölti ideje nagy részét az alkalmazás? A teljesítményhangolás legjobb eredménye, ha az alkalmazás azon részeire összpontosít, amelyek a legtöbb időt igénybe veszik.

jegyzet: Az Xdebug és különösen annak profilalkotási funkciói nagyon erőforrásigényesek és lelassítják a PHP végrehajtását. Javasoljuk, hogy ezeket ne futtasd éles szerverkörnyezetben.