Xdebug to rozszerzenie do PHP umożliwiające m.in debugowanie i profilowanie aplikacji napisanych właśnie w tym języku. O samej jego instalacji nie ma się co rozpisywać (użytkownikom Arch Linuksa tylko podpowiem, że znajduje się on w AUR).

Po zainstalowaniu, jeśli nasz system tego nie zrobi za nas, trzeba rozszerzenie wstępnie skonfigurować. Na przykładzie wspomnianego Archa zostaniemy dokładnie poinstruowani co trzeba zrobić:

 ==> Please add the following lines to your /etc/php/conf.d/xdebug.ini

 zend_extension=/usr/lib/php/xdebug.so
 xdebug.remote_enable=on
 xdebug.remote_host=<ip address>
 xdebug.remote_port=<port>
 xdebug.remote_handler=dbgp

Jednakże dla nas ważna jest tylko pierwsza linia tych ustawień, ponieważ pozostałe służą do komunikacji z osobnym klientem. Dlatego też można te linie zakomentować, bądź usunąć. Interesuje nas natomiast włączenie profilowania, co można uskutecznić poprzez dopisanie następujących linii do pliku konfiguracyjnego:

xdebug.profiler_enable=1
xdebug.profiler_output_dir=/tmp

Katalog docelowy jest domyślnie ustawiony na /tmp, więc ta linia tak naprawdę nic nie wnosi, poza tym, żeby było jasno widać jak można ten katalog zmienić.

Następnie restartujemy serwer włączamy stronę www. Po czym w katalogu docelowym powinny znajdować się już raporty o nazwach w rodzaju: cachegrind.out.<PID>.

Raporty takie można otworzyć za pomocą programów KCacheGrind, WinCacheGrind czy MacCallGrind i wyglądają mniej więcej tak:

Na koniec ostateczny wygląd xdebug.ini:

zend_extension=/usr/lib/php/xdebug.so
xdebug.profiler_enable=1
xdebug.profiler_output_dir=/tmp

Obiekt sfPropelPager nie potrafi „keszować” w sobie wyników zapytania do bazy. Innymi słowy każde wywołanie metody getResults() odpytuje bazę danych. Dlatego też, trzeba uważać czy nie wywołuje się tej metody więcej niż jeden raz podczas jednego żądania (np. przy kilkukrotnym iterowaniu po wynikach).

Krótkie spostrzeżenie na temat wydajności aplikacji (praktycznie nie wypełnionej danymi) po następujących aktualizacjach:

• Symfony 1.1 → Symfony 1.2
• Propel 1.2 → Propel 1.3
• PHP 5.2.0 → PHP 5.2.6
• PostgreSQL 8.1 → PostgreSQL 8.3

Prosty test został wykonany za pomocą ApacheBenchmarka:
ab -c 5 -n 300 -H 'Connection: close'. Jak widać symulacja bazowała na 300 użytkownikach, przy czym do 5 na raz wchodziło na stronę.

Przed

Próba 1:

Requests per second:    4.34 [#/sec] (mean)
Time per request:       1152.770 [ms] (mean)
Time per request:       230.554 [ms] (mean, across all concurrent requests)

Próba 2:

Requests per second:    4.79 [#/sec] (mean)
Time per request:       1043.581 [ms] (mean)
Time per request:       208.716 [ms] (mean, across all concurrent requests)

Po

Próba 1:

Requests per second:    5.33 [#/sec] (mean)
Time per request:       937.318 [ms] (mean)
Time per request:       187.464 [ms] (mean, across all concurrent requests)

Próba 2:

Requests per second:    5.39 [#/sec] (mean)
Time per request:       927.979 [ms] (mean)
Time per request:       185.596 [ms] (mean, across all concurrent requests)

Oczywiście z uwagi na brak testów pomiędzy poszczególnymi zmianiami ciężko jest powiedzieć coś więcej, niż tyle że warto aktualizować, choćby o tego jednego requesta na sekundę ;). Ot, taka ciekawostka.