Sledovanie problému s výkonom v skutočnej aplikácii PHP môže byť samo o sebe dosť ťažké, ale čo robiť, keď ste si istí, že prekážkou je samotná aplikácia? Vynikajúce rozšírenie Xdebug má veľa užitočných funkcií na pomoc vývojárom aplikácií, ale dnes sa pozrieme na jednu konkrétnu funkciu, ktorá nám môže pomôcť presne zistiť, čo je v aplikácii pomalé: profilovanie.
Profilovanie aplikácie PHP môže vysvetliť, koľko času server strávil každou funkciou, každým súborom a každou cestou kódu. Môže vám tiež ukázať, koľkokrát bola funkcia alebo metóda volaná, čo je užitočné pri diagnostike programových chýb zahŕňajúcich nezmyselné opakovanie. Xdebug generuje súbory kompatibilné s cachegrindom (súčasť Sada nástrojov Valgrind), ktoré možno použiť aj na vytváranie ľahko pochopiteľných grafov pomocou KCachegrind.
Začnime s nejakým veľmi jednoduchým PHP kódom, ktorý sa len 10-krát zacyklí, aby sme mohli získať nejaký výstup z KCachegrindu. Nebudem sa tu zaoberať inštaláciou Xdebug, ale tu je konfigurácia, ktorú na to používam:
[php]; Povoliť rozširujúci modul xdebug
zend_extension=/usr/lib64/php/modules/xdebug.so
xdebug.profiler_output_dir=”/dev/shm/trace”
xdebug.profiler_append=Zapnuté
xdebug.profiler_enable_trigger=Zapnuté
xdebug.profiler_output_name=”%R-%u.trace”
xdebug.trace_options=1
xdebug.collect_params=4
xdebug.collect_return=1
xdebug.collect_vars=0
xdebug.profiler_enable=0
;xdebug.auto_trace=Vyp[/php]
Všimnite si, že výstup cachegrind ukladám na /dev/shm/trace. Je to preto, aby som neznižoval výkon v produkčnom systéme pri používaní profilovania Xdebug s automatickým sledovaním, ak sa snažím získať veľké množstvo vzoriek údajov. Tu to veru nie je potrebné, ale ani to ničomu neublíži, takže pri tom zostaneme.
Tu je kód PHP, ktorý spustíme:
[php]for ($i = 1; $i <= 10; $i++) {
echo $i;
}[/php]
Keď načítame stránku, v okne prehliadača sa vytlačí „12345678910“. Kvôli spôsobu, akým sme nakonfigurovali Xdebug, bude profilovať vykonávanie PHP iba vtedy, keď GET alebo POST špeciálny reťazec ‘XDEBUG_PROFILE’ . Takže za predpokladu, že náš malý testovací PHP skript je umiestnený na http://example.com/test.php , chceli by sme kliknúť na http://example.com/test.php?XDEBUG_PROFILE . Tým sa vygeneruje súbor s názvom približne takto: ‘_test_php_XDEBUG_PROFILE-1296249911_052628.trace’ . Všimnite si, že obsahuje názov súboru PHP, ktorý bol spustený, reťazec dotazu a časovú pečiatku UNIX (vrátane informácií o časovaní pod sekundou). Ak súbor otvoríme v textovom editore, môžeme vidieť obsah, ktorý v tomto režime nie je v skutočnosti určený na čítanie pre ľudí (hoci to môžete zmeniť, ďalšie informácie nájdete v dokumentácii Xdebug).
[php]==== NOVÝ PROFILOVACÍ SÚBOR ============================================= ===
verzia: 0.9.6
cmd: /chroot/home/magbench/magbench1.nexcess.net/html/test.php
časť 1
udalosti: Čas
fl=/chroot/home/examplec/example.com/html/test.php
fn={main}
zhrnutie: 23
0 23[/php]
Pozrime sa, čo sa stane, keď spustíme tento výstupný súbor cachegrind cez KCachegrind. Pretože naozaj nerád mrhám priestorom pri inštalácii knižníc KDE na mojom systéme Ubuntu, na ktorom beží Gnome, jednoducho som si nastavil virtuálny stroj Ubuntu Server a nainštaloval naň KCachegrind a všetky knižnice KDE. Potom sa k nemu pripojím pomocou ‘ssh -X user@vmhostname kcachegrind’, čo otvorí KCachegrind v novom okne, podobne ako keby som ho spúšťal lokálne.
Ako môžete vidieť, test.php zabral 100% času a neboli žiadne volania alebo volania externých skriptov / funkcií / metód.
Teraz sa pozrime, čo sa stane, keď to otestujeme pomocou nejakého jednoduchého softvéru PHP, ktorý máme radi: DokuWiki ( http://www.dokuwiki.org/dokuwiki ):
Aha, teraz sme na niečom. Na grafe môžeme vidieť, že funkcia ‘langsel’ zabrala ~ 63 % času spracovania pri vykonávaní skriptu, takže ak by sme chceli optimalizovať, najprv by sme sa tam chceli pozrieť.
Tu je ďalší príklad: Hlavná indexová stránka doku.php po nainštalovaní DokuWiki:
Štruktúru programu môžeme vidieť z grafu, a hoci väčšina z toho vyzerá normálne, bol by som trochu podozrievavý, prečo php::date_default_timezone_get trvalo tak dlho a zvážil by som, že by sa to malo urobiť ako konštanta, aby sa veci urýchlili (pomocou takmer 13 %!). Toto je, samozrejme, s nulovým skutočným obsahom wiki na stránke, takže veci by sa zmenili so zmenou obsahu, ale stále je to veľmi cenný nástroj na hlbšie preskúmanie toho, prečo je aplikácia pomalá.
Nabudúce sa budem venovať druhej strane ladenia výkonu aplikácií: profilovaniu SQL dotazov pomocou Maatkit.
Diagnostika pomalého vykonávania PHP pomocou Xdebug a KCachegrind
