Zastávám názor, že už při psaní kódu bychom měli mít na paměti rychlost jeho vykonávání. Samozřejmě by to nemělo být v rozporu s kvalitou kódu, ale naopak v souladu s ní – vyhýbat se zbytečně složitým konstrukcím a vytvářet elegantní kód, který se bude nejen dobře spravovat, ale zároveň i rychle vykonávat. Pokud však na rychlost vykonávání kódu při psaní nemyslíme, nebo pokud je i přes to kód pomalý, přichází ke slovu profiler. Ten nám řekne, kde naše aplikace tráví nejvíce času.
Pro PHP je k dispozici profilerů několik, některé jsou přímo součástí vývojových prostředí, já mám dobrou zkušenost s rozšířením APD, což je rozšíření přímo do Zend enginu, v php.ini
se tedy aktivuje direktivou zend_extension_ts = C:/PHP/ext/php_apd.dll
nebo podobnou. Poté stačí v okamžiku, kdy chceme zahájit profilování, zavolat funkci apd_set_pprof_trace, čímž vznikne soubor, který lze následně analyzovat třeba skriptem pprofp
. Výstup potom vypadá např. takto:
%Time | Real | User | System | Calls | secs/call | summ s/call | Name | |||
---|---|---|---|---|---|---|---|---|---|---|
excl | cumm | excl | cumm | excl | cumm | |||||
33.3 | 0.02 | 0.02 | 0.02 | 0.02 | 0.00 | 0.00 | 7 | 0.0029 | 0.00 | require_once |
33.3 | 0.01 | 0.01 | 0.02 | 0.02 | 0.00 | 0.00 | 55 | 0.0004 | 0.00 | sprintf |
33.3 | 0.00 | 0.00 | 0.02 | 0.02 | 0.00 | 0.00 | 144 | 0.0001 | 0.00 | feof |
Z tohoto výstupu se dá následně poznat, ve kterých funkcích skript tráví nejvíce času, a na tato místa se následně zaměřit.
Dobrou alternativou je Xdebug spolu s WinCacheGrind nebo KCachegrind.
U většiny webových aplikací problém nicméně není v rychlosti PHP kódu, ale v práci s databází. Té můžeme nejlépe pomoci správným návrhem indexů.
Přijďte si o tomto tématu popovídat na školení Výkonnost webových aplikací.
Diskuse je zrušena z důvodu spamu.