Wo drückt denn der Schuh?

Software-Profiling in PHP
Kommentare

PHP-Projekte sind sehr oft fragile Systeme. In großen Projekten kann es durchaus vorkommen, dass die gesamte
Anwendung langsamer wird, nur weil man an einem kleinen Schräubchen gedreht hat. Diese Änderung lässt in den
meisten Fällen natürlich nicht darauf schließen, warum die Performance beeinträchtigt wurde. Vielleicht verändert
sie den Pfad durch den Programmcode so, dass nun eine sehr kostspielige Funktion häufig aufgerufen wird.
Vielleicht aber auch nicht. Kritische Stellen im Sourcecode zu finden, kann ohne die nötigen Werkzeuge schnell zu
einer Sisyphosarbeit werden. Die effektivsten Hilfsmittel zum Lösen dieser Probleme sind Profiler.

Profiler haben die Aufgabe, den Programmfluss zur Laufzeit zu analysieren. In den meisten Fällen sammeln sie dabei Daten über aufgerufene Methoden, Anzahl der Aufrufe, Dauer der einzelnen Calls, Speicherverbrauch und natürlich den Weg durch den Sourcecode. Eine Untersuchung dieser Kennzahlen erhöht die Chance, kritische Stellen im Code zu finden und existierende Schwachstellen zu beseitigen. Die Funktionsweise von Profilern ist dabei immer gleich. Sie werden als PHP-Erweiterung installiert und klinken sich in den Interpreter ein. Dort verankert, speichern sie alle Informationen, die sie benötigen, um später ein Profil über den Ablauf zu erstellen. Wie man einen Profiler zum Laufen bringt, wie man ihn verwendet und wie man das erstellte Profil interpretiert, soll Teil dieses Artikels sein. Als PHP-Entwickler hat man das Glück, gleich unter mehreren guten Profilern wählen zu können. Wir werden in unseren Beispielen Xdebug, Version 2.0 von title=“Derick Rethans“ target=“_blank“>Derick Rethans verwenden, da dieser lange Zeit als Quasistandard galt und sich auch heute noch sehr hoher Beliebtheit erfreut. Vorteil des Tools ist auch die zusätzliche Funktionalität, die es mit sich bringt. Neben der Möglichkeit, Profile zu erstellen, wird auch eine Debugging-Schnittstelle geschaffen, die problemlos in alle gängigen Entwicklungsumgebungen integriert werden kann. Ein weiteres Feature ist die erzeugte Statistik zur Codeabdeckung (Code Coverage), die zum Beispiel in Tools wie PHPUnit Einzug findet. Dieser Artikel kann leider nicht all diese Funktionalitäten behandeln, beschränkt sich deshalb auf den Profiling-Teil.

Installation

Die Installation von Xdebug erfolgt am Einfachtsten über PECL. In einem Linux-Betriebssystem mit installiertem PHP und Apache kann man folgenden Befehl zur Installation verwenden: pecl install xdebug. Bei der Installation über PECL wird Xdebug gegen PHP kompiliert. Es kann sein, dass die PHP-Sourcen fehlen. Sollte das der Fall sein, wird die Xdebug-Installation abbrechen. In diesem Fall sollte man die Source-Pakete der verwendeten Linux-Distribution nachladen, oder im Fall von XAMPP das Source.tgz. Nach der erfolgreichen Installation ist eine Anpassung der php.ini notwendig. Manchmal können in einer PHP-Umgebung mehrere php.ini-Dateien angelegt sein. Daher lohnt es sich, über phpinfo herauszufinden, welche php.ini gerade genutzt wird. Dazu kann man einfach folgenden Befehl an der Kommandozeile eingeben: php -i | grep -i php.ini. Dabei sollte dann etwas Ähnliches wie das Folgende angezeigt werden:

Configuration File (php.ini) Path => /opt/lampp/etc
Loaded Configuration File => /opt/lampp/etc/php.ini

Man weiß jetzt, dass die verwendete php.ini in /opt/lampp/etc/ liegt und kann sie editieren. Wenn die PHP-Version >= 5.3.0 ist oder PHP als CLI, CGI oder im Apache MPM Prefork gestartet wird: zend_extension=“/xdebug.so“. Und wenn die PHP-Version PHP in einem Thread gestartet wird (z. B. als ISAPI oder im Apache MPM Worker): zend_extension_ts=“/xdebug.so“. Dies fügt die gerade kompilierte Extension hinzu. Wichtig ist hier zum einen die Verwendung von zend_extension oder zend_extension_ts, und nicht einfach extension und die Angabe des absoluten Pfades. Zu beachten ist hierbei noch die Inkompatibilität zum Zend Optimizer und anderen Zend-Erweiterungen. Das heißt: Entweder Xdebug oder Zend. Mit dem Kommando php -m | grep -i xdebug kann man danach prüfen, ob Xdebug geladen wird.

Konfiguration

Im nächsten Schritt wird das Xdebug-Modul in der php.ini target=“_blank“>konfiguriert. Man soll das Profiling über einen GET-Parameter einschalten können und die Ausgabe soll für die Weiterverarbeitung im Grind-Format in einem lokalen Verzeichnis abgelegt werden, sodass man mit einem lokalen Tool wie WinCacheGrind, title=“KCacheGrind“ target=“_blank“>KCacheGrind, MacCallGrind oder einem Web-Frontend wie WebCacheGrind auf die Profiling-Daten zugreifen kann. Dazu werden der php.ini folgende Parameter hinzugefügt:

  • xdebug.profiler_enable=Off schaltet das Profiling permanent ein oder aus. Aus ist hier besser, da man das Profiling entweder über die Kommandozeile direkt einschalten oder den URL-GET-Parameter ?XDEBUG_PROFILE verwenden kann.
  • xdebug.profiler_output_dir=“/tmp“ gibt das Verzeichnis (auf dem Server) an, in dem die Logs gespeichert werden sollen.
  • xdebug.profiler_append=Off bedeutet Xdebug, das Profiling-Log neu zu schreiben und nicht zu erweitern.
  • xdebug.profiler_enable_trigger=On ermöglicht das Einschalten des Profilers für einen bestimmten URL über die Nutzung des GET-Parameters XDEBUG_PROFILE.
  • xdebug.profiler_output_name=cachegrind.out.%R%u: cachegrind.out.* ist die Dateiendung, die z. B. WinCacheGrind erwartet; %R benennt das Profile-Log nach dem verwendeten URI und %u hängt zusätzlich einen Zeitstempel an.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -