Programista PHP

W trakcie procesu projektowania aplikacji nie jesteśmy w stanie dokładnie wyliczyć oraz przewidzieć czasu wykonywania się poszczególnych jej elementów. Możliwe jest to dopiero podczas etapu wdrażania i testowania systemu przy pomocy narzędzi zintegorwanych z platformą (CI, CakePHP etc.) na której rozbudowujemy projekt o ile z takowej korzystamy, czy też dzięki wykorzystaniu narzędzi zewnętrznych.

CodeIgniter posiada wbudowany profiler oraz benchmark, dzięki któremu możemy zmierzyć czas wykonywania się danego kontrolera, czy też poszczególnych bloków kodu. http://codeigniter.com/user_guide/general/profiling.html

Miłośników systemu Windows zapewne uszczęśliwi fakt dostępności łatwego i wygodnego IDE dla PHP, które posiada wbudowany profiler, mowa tutaj o PhpED od NuSphere. Wersja podstawowa kosztuje 119$ i oczywiście pozbawiona jest Advanced PHP profiler, natomiast wersja profesjonalna z udogodnieniami, których brak w wersji podstawowej warta jest 299$ (porówanie wersji).
Wydatek nie duży w przypadku, gdy zakupujemy program do firmy, natomiast zbyt wysoki dla przeciętnego Kowalskiego, który dojeżdża do pracy rowerem. Również zwolennik Open Source nie wyda swoich ciężko zarobionych pieniędzy na Software, nie ze względu na jego wysoki koszt ale na sam fakt, że w świecie wolnego oprogramowania za programy po prostu się nie płaci.

Instalacja Xdebug

Wykorzystamy do tego celu Xdebug, narzędzie do debugowania i profilowania aplikacji stworzonych w PHP, które występuje w postaci modułu dla tegoż właśnie języka programowania. Instalacji rozszerzenia można dokonać na kilka różnych sposobów, wszystkie dokładnie opisane zostały w dokumentacji projektu. Osobiście preferuję instalację ze źródeł, najnowsze można pobrać poprzez CVS

radek@:~ cvs -d :pserver:srmread@cvs.xdebug.org:/repository login
CVS password: srmread
radek@:~ cvs -d :pserver:srmread@cvs.xdebug.org:/repository co xdebug
radek@:~ cd xdebug
radek@:~ phpize && ./configure && make clean && make
radek@:~ cp modules/xdebug.so /folder/dla/modulu/

Gdy skopiujemy już gotowy moduł do wybranego folderu możemy przystąpić do konfiguracji. Domyślnie plik konfiguracyjny PHP pod Apache2 znajduje się w /etc/php5/apache2/php.ini dodajemy do niego następujące wpisy:

zend_extension=/folder/dla/modulu/xdebug.so

; General
xdebug.default_enable=on
xdebug.extended_info=1

; Profiling
xdebug.profiler_enable=1
xdebug.profiler_output_dir=/tmp/xdebug_profiler
xdebug.profiler_output_name=cachegrind.out.%p

Wyniki profilowania w postaci plików wyjściowych będą zapisywane w folderze /tmp/xdebug_profiler/ Upewnijmy się, czy taki folder aby na pewno istnieje i posiada prawa do zapisu (chmod 777). To tyle z procesu instalacji, możemy teraz zrestartować demona Apache i sprawdzić czy profilowanie działa.

Możemy tego dokonać poprzez wyświetlenie dowolnego pliku php na naszym lokalnym serwerze i sprawdzeniu czy analiza z uruchomienia została zapisana w /tmp/xdebug_profiler.

radek@:/ ls /tmp/xdebug_profiler/
-rw-r–r–  1 www-data www-data 1,8K 2008-02-03 14:24 cachegrind.out.7144

Wyniki Profilowania

Dzięki Xdebug jesteśmy w stanie wyłapać błędy w naszej aplikacji w postaci niezoptymalizowanego kodu, który jest przyczyną spadku wydajności. Obserwując wygenerowane wyniki w KCachegrind lub WinCacheGrind możemy w prosty sposób zlokalizować te warstwy aplikacji, które wykonują się najdłużej czy też te, które najczęściej były wywoływane. Mamy także możliwość poruszania się po wygenerowanym grafie (KCachegrind), który przedstawia strukturę odwołań.

KCachegrind

WinCacheGrind

Z powyższego zestawienia wynika, że trzema najdłużej wykonującymi się metodami w projekcie są kolejno:

1. konstruktor klasy Welcome - 1,7ms
2. konstruktor klasy Controller - 1,7ms
3. metoda _ci_initialize klasy Controller - 1,7ms

Tuż za nimi plasuje się z numerem czwartym metoda _run_hook z klasy CI_hooks z czasem 1,4ms.

Zlokalizowanie miejsca występowania anomalii zapewnia nam możliwość jej zlikwidowania oraz przywrócenia aplikacji właściwego stanu wydajności. Należy przy tym pamiętać o zagnieżdżonych odwołaniach do zewnętrznych modułów czy też implementacjach np. zapytań sql, przy których może okazać się konieczna ich optymalizacja aby uzyskać interesujące nas efekty optymalizacji. Profilowanie aplikacji jest rzeczą bardzo ważną, zależy od tego późniejsze funkcjonowanie naszego systemu, który powinien być niezawodny i przede wszystkim szybki.