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), gdyż każda większa dystrybucja powinna mieć Xdebuga wśród swoich pakietów.

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 lokalny serwer http i odpalamy stronę www, której działanie chcemy przeanalizować. W katalogu docelowym (/tmp) powinny znajdować się już raporty o nazwach w rodzaju: cachegrind.out..

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

Brak podobnych wposów.

let loaded_matchparen = 1

Oczywiście wciąż można używać kombinacji shift-5, aby „ręcznie” odnaleźć nawias z pary.

Podobne wpisy:

1. Krótko: uwaga na sfPropelPager::getResults()
2. Vim: łatwe zwiększanie/zmnieszanie liczb i liter
3. Vim: Znajdowanie plików w podkatalogach

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).

Podobne wpisy:

1. Krótko: Vim i powolna edycja plików PHP
2. Symfony: domyślny wygląd modułu
3. Migracja MySQL → PostgreSQL aplikacji w Symfony 1.1

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 aktualizacją

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 aktualizacji

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 zmianami ciężko jest powiedzieć coś więcej, niż tyle że warto aktualizować, choćby o tego jednego requesta na sekundę ;). Ot, taka ciekawostka.

Podobne wpisy:

1. Migracja MySQL → PostgreSQL aplikacji w Symfony 1.1
2. PostgreSQL: obliczanie odstępów czasu
3. Walidacja jednego pola formularza w symfony