// December 27th, 2009 // 14 Comments » // Blog / Website, IT, Tutorials
Um den Performanceproblemen auf den Grund zu kommen, hat mir Uli Xdebug empfohlen. Xdebug ist ein Debugger und Profiler Tool für PHP:
The Xdebug extension helps you debugging your script by providing a lot of valuable debug information. The debug information that Xdebug can provide includes the following:
- stack traces and function traces in error messages with:
- full parameter display for user defined functions
- function name, file name and line indications
- support for member functions
- memory allocation
- protection for infinite recursions
Da Zypper, mit den Repositories von meinem Strato vServer, Xdebug leider nicht kannte, musste ich es manuell installieren. Dazu habe ich mir das aktuelle Paket in der Version 2.0.5 per wget geladen und entpackt:
wget http://xdebug.org/files/xdebug-2.0.5.tgz
tar xfvz xdebug-2.0.5.tgz
Da für die Ausführung phpize notwendig ist und mir das Paket autoconf fehlte, habe ich diese nachinstalliert (auf autoconf wird man nicht explizit hingewiesen, aber Google weiß ja alles):
zypper install php5-devel
zypper install autoconf
Anschließend führt man phpize aus, kompiliert die Sources und kopiert die Binary an einen Ort, den man gut wiederfindet:
phpize
./configure --enable-xdebug
make
cp modules/xdebug.so /to/wherever/you/want/it
Um das Modul für PHP zu aktivieren, gibt man die xdebug-Binary in der php.ini (bei mir /etc/php5/apache2/php.ini) an und startet den Webserver neu:
zend_extension="/wherever/you/put/it/xdebug.so"
/etc/init.d/apache2 restart
Anschließend kann man eine phpinfo-Datei auf dem Webserver erstellen um zu prüfen, ob das Modul erfolgreich eingebunden wurde.
In der php.ini ergänzt man den o.g. Eintrag um die folgenden Einstellungen
xdebug.profiler_enable="0"
xdebug.profiler_output_dir="/tmp/xdebug"
xdebug.profiler_output_name="cachegrind.out.%u.%p"
xdebug.profiler_enable_trigger="1"
Ich empfehle enable auf 0 zu belassen und enable_trigger auf 1, so dass die Logs nur generiert werden, wenn die Webseite über "http://url-des-webhosts/?XDEBUG_PROFILE" aufgerufen wird. Dies verhindert, dass der Festplattenspeicher vollläuft, was wirklich schnell passieren kann. Als nächstes sollte noch das Verzeichnis erstellt werden (sofern nicht bereits vorhanden), welches wir unter output_dir angegeben haben:
mkdir -p /tmp/xdebug
chmod 1777 /tmp/xdebug/
Zur Auswertung stehen einem unter Windows WinCacheGrind oder unter Linux KCacheGrind zur Verfügung:
Auf Feldstudie.net lagen die Probleme hauptsächlich bei den Plugins Global Translator, Similar Posts, WP-Syntax und WP-Ads. Ich habe diese nun entfernt. Außerdem habe ich das Javascript bzw. die Tab-Funktionalität aus der Sidebar entfernt und die letzten Kommentare über das Standardwidget eingebunden.
Zusammen mit der Reaktivierung der Compression (Deflate, GZip) konnte ich die Antwortzeit des Webservers von ca. 6-9 Sekunden auf 2-3 Sekunden senken. Ich denke, damit kann man getrost leben. 
Dank geht wiedermal an Uli, der mir Xdebug empfohlen hat.
mit dem Administration Kit zu überprüfen, kann beim Administration Kit 8 das "Protokoll über Versionen von Kaspersky-Lab-Anwendungen" genutzt werden. Allerdings müssen hier noch weitere Optionen aktiviert werden.
), habe ich mich gerade mal daran gemacht ein Batchscript zu schreiben, mit dem man Dateien und Verzeichnisse unterhalb eines anzugebenden Pfades löschen kann. Viele nutzen hierfür einfach den DOS-Befehl "RD". Dieser löscht jedoch das angegebene Verzeichnis selbst mit. Mir war es jedoch wichtig, dass das angegebene Verzeichnis bestehen bleibt.
