PHP erőforrás logger
Pontosan mennyi erőforrást használ el egy PHP szkript? Mindig érdekelt, mennyi CPU időt esznek a szkriptjeim élő környezetben. Voltak kezdeti kíséleteim a problémára a microtime fügvénnyel, de ez a megközelítés eleve kudarcra volt ítélve, mivel a szerver egyszerre több kérést szolgál ki (multithread), így a több PHP szál természetesen hatással van egymás futási idejére.
Lézteznek modulok, mint az Advanced PHP Debugger amivel egészen a függvényekig lebontva részletes információkat kaphatunk, ezek azonban hibakereső felhasználásra születtek, nem igazán éles környezetbe. (Többszáz futtatás eredménye sok, nehezen értelmezhető logfile-t generál, és ezen kiterjesztések maguk is erőforrásigényesek).
Webhosting (tárhely) szolgáltatóknak
Ha ma webhelyet vásárolsz, a szerződés mindenütt tartalmazza a tárhely méretét. Nem lenne túl sikeres üzleti model korlátlan tárhelyet árulni, mert lehet, hogy százból 1 felhasználó ki is akarja majd használni. Gyakorlottabb hoszting cégek meghatároznak egy józan (havi) adatforgalmat is a tárhelyhez, nehogy egy weblap tele videókkal megegye a szerver egész sávszélességét.
Ugyanez a helyzet a gazdaságtalanul megírt PHP szkriptekkel. Nem csak friss, gyakrolatlan PHPzőkkel van ilyen gond. Kevesebb energiát (azaz munkaórát) igényel összedobni egy kódot, mint átgondolni egy jó modellt az oldal kiszolgálására. Szintén olcsóbb a meglévő kódot toldozni-foldozni ott ahol az újraírás lenne a megoldás.
Hathatós megoldás lenne a problémára, ha a szerver többi erősorrásához hasonlóan a CPU időre meghastározhatnánk egy ésszerű korlátot, mint később futni a pénzünk után.
Webfejlesztőknek
Számomra nagyon tanulágos volt az eredmény. Látni, hogy néha az egyszerűbbnek gondolt aloldalak kétszer annyit dolgoznak, mint a soksok widget-et tartalmazó index.php-im. Vagy akár összehasonlítani saját fórumomat a phpBB futásidejével stb stb stb.
Egy összegző program még hasznos adatokat nyújthat, például a logból átlagos futásidőket számolni, domainek szerint összegezni az adatokat, vagy a query-stringben keresendő RegEx-ek szerint (gondoljunk csak az index.php?module=hozzaszolas tipusú címekre).
A naplófájl
A kiterjesztés az Apache logokhoz hasonló naplót készít. Lássuk:
azoldal.hu 72.30.98.216 [13/Jul/2006:16:08:07 CEST] "/t3/mozi" 11722 38692 428 48692
www.masikoldal.hu 81.182.15.108 [13/Jul/2006:16:08:42 CEST] "/c124/hetvege-az-operencian-tul" 11712 33456 0 53456
www.masikoldal.hu 193.68.46.173 [13/Jul/2006:16:10:18 CEST] "/elerhetosegeink" 11714 30860 0 40860
A példa egy olyan környzetből való, ahol az összes VirtualHost egy közös logot hazsnál. Ilyenkor hazsnos, ha a host neve is látszik a kérés mellett, sőt enélkül elképzelhetetlen a közös naplófájl. Az általános forma:
[ http_host ] SPACE remote_addr SPACE "[" request_time "]" SPACE <"> request_uri <"> SPACE pid SPACE u_elapsed SPACE s_elapsed SPACE t_elapsed [ CR ] LF
Az u_elapsed a szál (és csakis ezen szál) USER módban töltött ideje, a s_elapsed pedig szintén ezen szál SYSTEM módban. A kettő összegeként megkapjuk mennyi CPU időt hasznát a szkript. A fordítás nem számít bele a mért időbe, sem pedig a külső processzek által végzett munka, mint például MySQL lekérdezések.
A t_elapsed a kiszolgálás teljes időtartamát méri. Ez a microtime-nál említett okokból megbízhatatlan, hiszen ha le van terhelve a rendszer minden PHP lassan fut, nem csak az, amelyik a processzort 90%ban bírtokoja. Azért szerepel mégis itt, mert egy 24 órás átlagot számítva rámutathat olyan hibákra is (pl. lassú SQL lekérdezések) amiről a másik két számláló nem adna információt.
Az időmérés nem feltétlenül pontos. Tapasztalatim szerint (Intel processzoron) átlagosan egy +/- 100 mikroszekundum pontatlansággal lehet számolni.
Telepítés
Tömörítsük ki a csomagot egy tetszőleges helyre, majd a következő parancsokkal fordítsuk le:
phpize
./configure
make
A fájlok a következő sorra kerülek a helyükre, root jogokkal (sudo) végrehajtva:
sudo make install
Aktiváljuk a kiterjesztést a következő sorral a php.ini fájlban. Ha nem tudjuk a helyét, a phpinfo() függvény megmondja.
extension=reslog.so
Az Apache újraindítása után a phpinfoban megjelenik a kiterjsztés:
Beállítás
A kiterjesztés a következő paramétereket kezeli:
A reslog.file paraméterrel állíthatjuk a logfile nevét, elérési útját. Alapértelmezésben ez /tmp/php-reslog. Célszerű megváltoztatni. Mivel a fájlt az Apache usere (általában www) írja, egy rosszindulatú php fájl is hozzáférhet. Ez ellen az open_basedir PHP direktívával lehet védekezni.
A reslog.showhost paraméterrel kapcsolhatjuk ki és be a hostnév (szerver) kijelzését a logban. Ez akkor hasznos, ha több hostra egy közös logfájlt használunk.
A reslog.usecanonical a logfájlban megjelenő hosztnevet befolyásolja. Logikája megegyezik az Apache UseCanonicalName direktívájával. Bekapcsolt állapotban a ServerName direktívában megadott hosztnevet látjuk a fájlban. Kikapcsolva (alapértelmezett) a klienstől kapott hostnevet látjuk. Mikor fontos ez? Egy VirtualHost több domainnév alatt más-más tartalmakat is kiszolgálhat. Gyakori eset, hogy az aldomain pl: akarmi.domain.hu valójában a domain.hu/akarmi címet jelenti.
Ezen beállítások felülírhatók .htaccess fájlokban, úgyhogy a php.ini mellett mindenképpen tanácsos az Apache konfigurációban rögzíteni az értékeket a php_admin_* paraméterekkel pl:
php_admin_value reslog.file /var/log/php-reslog
php_admin_flag reslog.showhost on
A forrás
- Letöltés - A kiterjesztés forrásának letöltése
Külső linkek
- Weblabor: Zend kiterjesztések - Kis betekintés a PHP lekivilágába
PHP kiterjesztések (extension) írásához
- Az alap - Itt lehet kezdeni az ismerkedést a kitejlesztések írásával
- Developing Custom PHP extensions - Windowsos build környezet és modul info készítése
- Browse-source: PHP - A teljes php forrás könnyen követhető és kereshető formában (elegedhetetlen)
- Jim Winstead: Writing a PHP Extension - Egy 2003-as előadás anyaga, tartalmaz néhány információt, amire az eddigiek nem térnek ki.