© istockphoto.com/akindo
Werkzeuge für Analyse und Leistungssteigerung

Eine neue Ära der PHP-Profiler


Profiler wie Xdebug oder Facebooks XHProf sind mächtige Werkzeuge. Letztes Jahr haben namhafte Firmen wie Qafoo, Zend und SensioLabs ihre eigenen Profiler veröffentlicht, die das Analysieren von PHP-Anwendungen revolutionieren sollten. Engpässe oder ineffizienter Code gehören somit der Vergangenheit an. Zeit also, sich die Profiler einmal genauer anzuschauen, um herauszufinden, welcher Profiler den jeweiligen Bedürfnissen am nächsten kommt.

Video: Profiling with XHProf

Mit Profilern wird die Leistungsfähigkeit von PHP-Anwendungen analysiert. So lassen sich z. B. SQL-Abfragen in einer Schleife oder ein nicht aktiver Cache schnell aufspüren. Vielen dürfte in diesem Zusammenhang der Profiler Xdebug bekannt sein. Während er in der Anfangszeit gute Dienste leistete, brachte Facebook 2009 XHProf mit einem GUI heraus. Seit letztem Jahr gibt es neben diesen beiden Urgesteinen noch weitere Profiler, etwa Z-Ray, Blackfire und Tideways.

Warum sollte ich meinen Code analysieren?

Diese Frage ist einfach zu beantworten: Time is Money! Weniger Performance bedeutet weniger Einnahmen. Das kontinuierliche Testen der Performance sollte darum zum Entwicklungsworkflow gehören – getreu dem Motto: Nicht raten, sondern messen! PHP-Anwendungen sind heutzutage sehr komplex, und eine kleine Änderung am Code kann sowohl positive als auch negative Auswirkungen mit sich bringen. So wurde etwa der PHP Dependency Manager Composer mit nur einer einzigen Codezeile um 30 bis 90 Prozent beschleunigt. Bitte deaktivieren Sie jetzt aber nicht den PHP Garbage Collector in Ihrem Projekt. Das genannte Beispiel war wirklich ein Sonderfall.

Mit einer Analyse auf Codebasis werden also Bottlenecks oder besonders intensiv genutzte Ressourcen aufgedeckt. Da 80 Prozent der Performance im Frontend liegen, bleiben im Backend lediglich 20 Prozent übrig, um die Seite auszuliefern. Wenn wir davon ausgehen, dass eine Sekunde Ladezeit schnell ist, muss das HTML in 200 Millisekunden ausgeliefert sein. Allerdings kann die Netzwerklatenz 100 Millisekunden betragen, und es bleiben nur 100 Millisekunden, um den Ausgabecode auf den Weg zum Client zu schicken.

Das Profiling sollte in einer Cache-freien Umgebung stattfinden. Ernsthaft – Query, OPcache und andere Caches sollten deaktiviert sein. Ein Cache hat nicht direkt die Aufgabe, einen einzelnen Request der Anwendung zu beschleunigen, sondern vielmehr den Zweck, dafür zu sorgen, dass mehrere gleichzeitige Requests die Anwendung nicht verlangsamen, oder besser gesagt: dass sie genauso schnell sind wie ein einzelner Request. Wenn also die Anwendung bei einem Request langsam ist, sollte man der Ursache auf den Grund gehen, anstatt sich hinter einem Cache zu verstecken, denn: Nicht auf den Server, sondern auf den Code kommt es an! Die positive Auswirkung eines Caches wird dann später analysiert. Auch wenn Hardware heutzutage nicht teuer ist, kann sich eine Optimierung etwa auch auf den Geldbeutel auswirken. Es sollte darauf geachtet werden, dass die Zeit nicht mit Mikrooptimierungen verschwendet wird. Ein Beispiel wäre hier, print durch echo oder Double Quotes durch Single Quotes zu ersetzen. Folgende Frage hilft bei der Entscheidung für oder gegen einen Profiler: Habe ich ein Performanceproblem, und wenn ja, wie groß ist es? Auch sollte die Wartbarkeit der Software im Vordergrund stehen. Es bringt nichts, an jeder Stelle hochperformanten Code zu schreiben, der nicht verständlich ist. Optimierungen sollten sich auch auf dem Produktivsystem widerspiegeln, auch wenn dennoch Abweichungen zwischen Entwicklungs- und Produktivsystem auftreten können. Es empfiehlt sich also, das Entwicklungssystem identisch zum Produktivsystem aufzusetzen und Profiler gezielt live einzusetzen.

Profiling vs. Benchmarking

Unter Profiling wird das Messen der relativen Performance der Applikation auf Codebasis verstanden, während Benchmarks die aktuelle Performance der Anwendung, also das, was der Enduser sieht, untersuchen. Für Benchmarks oder Lasttests kommen z. B. ApacheBench, Siege oder Apache JMeter zum Einsatz. Bei den Profilern wird zwischen aktiven und passiven Profilern unterschieden. Aktive Profiler werden manuell vom Entwickler aktiviert und sammeln normalerweise mehr Informationen als passive Profiler. Sie sollten aber aufgrund der starken Performanceeinbuße nur auf dem Entwicklungssystem geladen sein. Passive Profiler aktivieren sich automatisch z. B. bei jedem hundertsten Request und haben kaum Auswirkungen auf die Performance der Anwendung. Somit steht einem produktiven Einsatz nichts im Wege.

Callers, Callees, Call Graph, Oh, My!

Neben Standardinformationen wie Speicherverbrauch, Ausführungszeit und Anzahl der Funktionsaufrufe gibt es noch Callers, Callees und einen Call Graph. Callers sind die Funktionen, die eine Funktion direkt aufrufen. Sie werden auch Parent Calls genannt. Callees sind so genannte Child Calls und geben an, was für Funktionsaufrufe von dieser Funktion ausgehen. Dann gibt es noch verschiedene Angaben mit Inclusive-, Exclu­sive- und Peak-Werten. Inclusive-Angaben beziehen sich dabei auf die Funktion selbst sowie auf ihre Callees. Die Inclusive Time kann kritische Pfade in der Applikation aufdecken. Exclusive-Angaben beziehen sich nur auf die Funktion selbst, also ohne Callees. Deshalb sollte man Funktionen mit hohen Exclusive-Werten zuerst analysieren und versuchen, sie zu optimieren. Peak-Werte sind wie Lastspitzen anzusehen. Der Call Graph ist eine hier...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang