1. Bevezetés

Napjainkra a PHP olyannyira kedvelt nyelvvé vált, hogy nemcsak apró, ad-hoc jellegű szkriptek írására használják, hanem komoly látogatottságú oldalak motorjának elkészítésére is. Egyértelmű, hogy ilyen esetekben kiemelten fontos kódjaink adott szintű hatékonyságának biztosítása, hiszen sokszor a fejlesztés során történő odafigyeléssel nem kevés erőforrást, vagyis pénzt spórolhatunk. Gondoljuk arra az esetre, amikor egy szerveren több tucat portál fut, mondjuk fejenként csak 1000 egyedi látogatóval naponta. Ekkor, ha egy olyan kódrészletet találunk, ami minden oldalletöltéskor végrehajtódik, akkor erős a késztetésünk, hogy valamit optimalizáljunk rajta. Ha itt egy lekérdezés sokszor fut le egy ciklusban, és rájövünk, hogy felesleges mezőket is lekérdeztünk az adatbázisból, amely felesleges mezők között volt egy szép nagy szöveges mező is, akkor a racionalizálással kézzelfogható eredményt érhetünk el, ami a szerver terhelésében azonnal megmutatkozik.

Viszonylag egyszerű felépítésű és működésű kódokat képesek vagyunk egyszerű eszközökkel is megvizsgálni. Gondolhatunk itt a kézzel történő időmérésre (microtime), vagy arra is, hogy szépen újra átnézzük a kódunkat, hátha a fejünkhöz kapunk valami láttán (illetve megkérjük a szomszéd Pistikét, hogy tegye ugyanezt). A fentiek egyike sem hatékony módszer, ráadásul időben jóval többe is kerülhetnek, mint egy profilkészítő alkalmazása.

Ha már ennyit beszéltünk az angolul (és magyarul is gyakran így említett) profilingnak nevezett folyamatról, akkor próbáljunk valami definíciót kreálni hozzá: nevezzük profilkészítésnek azt a folyamatot, amikor egy összetett alkalmazás (rendszer) részeit meghatározott szemcsézettséggel, hatékonyság szempontjából elemzünk. A gyakorlatban ez azt jelenti, hogy egy honlapmotor esetében a jól elkülöníthető modulokat egyenként leteszteljük, majd azonosítjuk azokat a kódrészleteket, objektumokat, amelyek nagyon sokszor, vagy a kód többi részéhez képes sokáig foglalják az erőforrásokat.

Profilkészítés nélkül éles rendszert üzembe helyezni nem szabad, de nem is érdemes, akár olyan rendszerről legyen szó, ami egyetlen kliensgépen futó asztali szoftver, akár olyanról, ami egy szerveren futva szolgál ki több ezer felhasználót.

Asztali környezetben kódtesztelésre használhatók a fejlesztői környezetek (IDE) beépített debugger és profiler moduljai, de külön terméket is használhatunk, amilyen mondjuk az Intel Vtune is.

Webes környezetben szintén használhatjuk a fizetős IDE-k (pl. PhpED) beépített moduljait, de ingyenes megoldást is választhatunk (APD, Xdebug, DBG).

2. A profilkészítés elmélete

Az alábbiakban áttekintjük, hogy mivel érdemes tisztában lenni akkor, ha egy alkalmazás hatékonyság-elemzésébe szeretnénk kezdeni.

2.1. A profilkészítés irányelvei

Gondoljuk végig, hogy milyen módon lehet egy profiler adott feladatra való alkalmasságát értékelni. Általánosságban jó egy profilkészítő, ha:

• Transzparens, tehát használatához nem kell módosítanunk a kódot. Ez egyrészt kényelmes, másrészt nem hoz újabb hibalehetőséget a folyamatba. Találhatunk olyan házi profilkészítő eszközöket, amelyeket a vizsgálandó kódrészlet előtt meg kell hívni, ezek azonban többnyire rendkívül amatőr, ad-hoc jellegű eszközök, komoly tesztelésre nem érdemes használni őket. Itt kell még megjegyezni, hogy webes teszteléskor, ha már egy üzemelő motort tesztelünk, a kód módosítását tesztelés előtt nagyon ritkán vagyunk képesek elkerülni. Gondolhatunk itt egy távoli szervertől való adatlekérésre (ami változó válaszidőket produkálhat, így megtévesztő eredményt adhat), vagy akár a motor által megjelenített reklámokra, amelyek csak torzítják az eredményt, hiszen a megjelenítés hatékonyságát nem vagyunk képesek befolyásolni például egy flash banner esetében.
• Minimális többletterhelést (overhead) okoz. Nyilvánvaló, hogy alkalmazásunk lelassul a profilkészítés alatt, de egy jó profilerrel a lassulás arányos lesz, így az egyes eljárások, kódrészletek közötti teljesítménykülönbség arányaiban közel állandó marad.
• Egyszerűen értelmezhető kimenetet állít elő. Mondanunk sem kell, hogy a begyűjtött profiladatok mit sem érnek akkor, ha értelmezésük nehézkes, ugyanis így pont a profileres tesztelés lényegét veszítenénk el: a gyorsaságot. Szerencsére ezt a profilkészítők fejlesztői is felismerték, így többnyire táblázatos elrendezésben kapjuk meg a végeredményt, de nem ritka a grafikus felülettel támogatott megjelenítés sem.

2.2. A teszteszközök kiválasztása

Mielőtt eszközt választunk, érdemes feltérképezni, hogy mit nyújtanak az egyes megoldások, illetve végiggondolni, hogy nekünk vajon mi mindenre van szükségünk. Ha főállásban vagy szabadúszóként foglalkozunk webfejlesztéssel, és pénzt is hajlandók vagyunk áldozni egy fejlesztői környezetre, akkor érdemes megtekinteni a http://www.phped.com/ címen megtalálható PhpED IDE próbaverzióját, amelyben a profilkészítőt és a debuggert is kipróbálhatjuk.

Ha ingyenes megoldásra vágyunk, akkor választhatjuk Schlossnagle mester http://pecl.php.net/package/apd címen elérhető Advanced PHP Debugger alkalmazását, ami minden fent meghatározott irányelvnek megfelel, kimenete pedig egyszerűen értelmezhető.

Szintén ingyenesen elérhető az Xdebug a http://xdebug.org/ címen, ami kiterjedt konfigurálhatóságával, jó dokumentációjával és azzal emelkedik ki a mezőnyből, hogy a KCacheGrind nevű linuxos programmal grafikus felületen elemezhetjük ki az eredményeket (ez igaz az APD-re is). Képességei George Schlossnagle szerint ?elmaradnak az APD hasonló lehetőségei mögött, különösen a meglévő nyomkövetési adatok többirányú feldolgozása terén.?

3. Profilkészítés a gyakorlatban

Bármilyen profilkészítő eszközt használjunk is, az elmélet megértése után mindenképpen boldogulni fogunk, így vélhetően elegendő ehelyütt egyetlen megoldást bemutatni. Az Xdebugra egyszerű telepíthetősége és a KCacheGrind nagyszerű grafikus felülete miatt esett a választásom.

3.1. Az Xdebug telepítése és a KCacheGrind

Kezdjük akkor az Xdebug telepítésével. Menjünk a http://xdebug.org webhelyre, és szerezzük be a legfrissebb stabil változatot (jelenleg: xdebug 2.0.0RC4). Az érdekesség kedvéért ebben a leírásban a Windows-os modult telepítjük, míg az eredmények elemzését Linux alatt végezzük majd el. A KCacheGrind-nek létezik windowsos verziója is, a WinCacheGrind, ez azonban nagyon régen frissült, és sajnos rendszeresen fagy amellett, hogy képességei is elmaradnak a KCacheGrind mögött.

A tesztelésre használt virtuális szerveren a PHP 5.1.6-os verziója fut, ezért az Xdebug webhelyéről a php_xdebug-2.0.0rc4-5.1.2.dll fájlt kellett beszerezni, ami be is került a php5 /ext könyvtárába, xdebug2.dll néven.

Ha ezzel megvagyunk, szedjük elő a php.ini fájlt, ami vagy a PHP könyvtárában, vagy a Windows könyvtárban található (ha AppServ-et használunk). Itt keressük meg azt a szekciót, ahol a különböző kiterjesztések betöltéséről kell rendelkeznünk; például keressünk rá az extension=php_mysql.dll sorra, ami engedélyezve is van, ha használjuk a MySQL-t. Szúrjuk be a blokk végére a következő sort:
(ha pontosvesszőt teszünk a sor elejére, deaktiválhatjuk)

A modult akkor indítja el, ha a PHP /ext könyvtárába tettük a .dll fájlt, egyébként, ha nem ide másoltuk, meg kell adnunk a teljes elérési utat. Megjegyzés: az Xdebug Zend kiterjesztésként javasolja futtatni a modult, de nekem így nem akart működni (a logban is láttam, hogy panaszkodik emiatt), ezért a hagyományos módszert választottam ? sikerrel.

Ezután nem kell mást tennünk, mint az alábbi sorokat bejegyezni a php.ini fájlba, közvetlenül az extension-ös sorok után, hogy megfelelően beállítsuk az Xdebug-ot. A szögletes zárójelbe tett részek csak megjegyzések, hogy értsük is, mire valók.


Mindezek után indítsuk újra a webszervert, vagy a komplett gépet ízléstől függően. Ha elindult a rendszer, a profilkészítés már aktív.

A cikksorozat következő részében tesztkörnyezetünk gyakorlati használatát tekintjük át.