Performanceproblem in PHP identifizieren mit DynaTrace

Im Rahmen der Untersuchung eines Performanceproblems in einem Internet Forum habe ich getestet, wie hilfreich DynaTrace bei einer PHP Anwendung sein kann um die Ursache des Problems zu finden.

Die Rahmenbedingungen und vorhergegangenen Maßnahmen beschreibe ich in diesem Artikel [http://www.sanchofock.de/?p=69]

Hier nur so viel: Das betroffene Internetforum verwendet die freie Software phpBB. Wie der Name schon sagt eine PHP Software, welche eine mySQL Datenbank verwendet.

Es traten teilweise sehr lange Wartezeiten insbesondere beim Absenden von Beiträgen auf.

Das Einrichten einer DynaTrace-Teststellung war bemerkenswert einfach. Vorausgesetzt man hat Zugriff auf die Konsole des zu überwachenden Systems und entsprechende Rechte.

Das Deployment des Agenten beinhaltete direkt die Einbindung in die WebUI. Das System wurde sofort erkannt auch die verwendeten Technologien.

Es war noch notwendig den Apache Server und den PHP Prozess neu zu starten, danach waren auch die Insights für Apache, PHP und mySQL verfügbar

 Also hinein in die Fehleranalyse:

Als erstes mal ein Blick unter Transactions & Services dieser Applikation. Tatsächlich ist ein Aufruf auffällig, der Aufruf von „posting.php“ Interessant ist es doch genau die Seite, die verwendet wird wenn ein Forumsbeitrag gespeichert wird.

Also hineingeschaut in den „PurePath“ wie DynaTrace es nennt. Also die Aufsplitterung der Service Aufrufe innerhalb einer Transaktion

 Einen langsamen Request rausgesucht:

Die Darstellung zeigt eine Aufgliederung der Teilprozesse. In diesem Fall handelt es sich um einige Datenbank Aktionen. Keine dieser Aktionen dauert signifikant lange. Doch etwas heruntergescrollt … was ist das? Das ist Interessant:

Zwischen dem Select auf die Tabelle Smilies und dem folgenden update liegen 3 Sekunden ohne das was passiert. Aber warum?

Bis hierhin passt das Bild perfekt zusammen. Die Antwortzeiten im Performancetest zeigten seltsame Antwortzeit Gruppen, die jeweils 3 Sekunden auseinander lagen. Die Analyse der Datenbank ergab, dass es keine lang laufenden Queries gab.

Aber wir wissen ja noch immer nicht, was die Ursache für diese Verzögerung ist, also müssen wir mal ins PHP hineinschauen.

Also hinein in die Antwortzeit Analyse, zunächst mal sehen wir auch hier, dass die PHP Ausführungszeit den Löwenanteil der Antwortzeit ausmacht.

Aber weiter Unten wird es endlich Konkreter:

Fast 91% der Zeit werden in der Methode gethostbyname verbraucht aus dem Modul phpbb_checkdnssrr.

Ohne den Souce Code zu kennen, liegt es also nahe, dass die lange Zeit bei DNS Server Abfragen entstehen.

Dies war der entscheidende Hinweis. Jetzt konnte ich das Problem weiter analysieren und beheben. Siehe dazu den Rahmenartikel XXX.

Fazit:

• Die Installation und das Deployment waren vorbildlich einfach.
• Auch ohne Tool-Experten Kenntnisse habe ich mich,  mit ein wenig suchen schnell zu recht gefunden und konnte das gesuchte Problem so schnell finden.
• Ein wenig Erfahrung mit DynaTrace und ähnlichen Tools habe ich mitgebracht, aber eine Analyse einer PHP Software hatte ich zuvor noch nie gemacht.
• Den Einsatz im professionellen Bereich kann ich nach dieser und vorherigen Erfahrungen durchaus empfehlen. In meinem kleinen Test lieferte DynaTrace den entscheidenden Hinweis.

Ich kann hier keine vollständige Tool Evaluation machen. Ob und wie gut das gleiche mit anderen Konkurrenten am Markt möglich ist sollte vor einer Anschaffung ggf. geprüft werden. Die folgenden Punkte und Überlegungen würde ich empfehlen zu berücksichtigen:

• Bei der von mir getesteten Version mit einem Datacenter muss die Verbindung zum Internet gegeben sein. Dies ist auf den ersten Blick eine technische Implikation, das Security Team muss also involviert werden. Aber es ist auch darauf zu achten, ob es im Unternehmen Security Policies gibt und ob der Einsatz auf diese Art danach zulässig ist.
• Über andere Deployment Modelle, die keine Verbindung ins Internet bedingen habe ich mich an dieser Stelle nicht informiert, das wäre ggf. mit dem Hersteller des Tools zu klären
• Über die Kosten habe ich mich an dieser Stelle ebenso nicht informiert, da ich ausschließlich an der Funktion interessiert war. Es versteht sich, dass wer den Einsatz von DynaTrace im professionellen Bereich ins Auge fasst hier eine eigene Kosten/Nutzen Betrachtung anstellt.
• Und zu guter letzt noch ein allgemeiner Rat: „A fool with a tool is still a fool“. Das sollte man niemals vergessen. Das Tool führt nicht zum Ziel, der Anwender des Tools tut das. Das Tool kann es ihm aber erheblich einfacher machen, wie in diesem Fall. Performancetests und Performance Analysen sind kein Hexenwerk, aber auch kein Nebenjob.