{"id":39,"date":"2018-03-30T10:52:07","date_gmt":"2018-03-30T10:52:07","guid":{"rendered":"http:\/\/www.sanchofock.de\/?p=39"},"modified":"2018-03-31T17:53:20","modified_gmt":"2018-03-31T17:53:20","slug":"performanceproblem-in-php-identifizieren-mit-dynatrace","status":"publish","type":"post","link":"https:\/\/www.sanchofock.de\/?p=39","title":{"rendered":"Performanceproblem in PHP identifizieren mit DynaTrace"},"content":{"rendered":"

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.<\/span><\/span><\/p>\n

Die Rahmenbedingungen und vorhergegangenen Ma\u00dfnahmen beschreibe ich in diesem Artikel [http:\/\/www.sanchofock.de\/?p=69]<\/span><\/span><\/p>\n

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.<\/span><\/span><\/p>\n

Es traten teilweise sehr lange Wartezeiten insbesondere beim Absenden von Beitr\u00e4gen auf.<\/span><\/span><\/p>\n

Das Einrichten einer DynaTrace-Teststellung war bemerkenswert einfach. Vorausgesetzt man hat Zugriff auf die Konsole des zu \u00fcberwachenden Systems und entsprechende Rechte.<\/span><\/span><\/p>\n

Das Deployment des Agenten beinhaltete direkt die Einbindung in die WebUI. Das System wurde sofort erkannt auch die verwendeten Technologien.<\/span><\/span><\/p>\n

Es war noch notwendig den Apache Server und den PHP Prozess neu zu starten, danach waren auch die Insights f\u00fcr Apache, PHP und mySQL verf\u00fcgbar<\/span><\/span><\/p>\n

<\/span>\u00a0<\/span><\/span>Also hinein in die Fehleranalyse:<\/span><\/span><\/p>\n

Als erstes mal ein Blick unter Transactions & Services dieser Applikation. Tats\u00e4chlich ist ein Aufruf auff\u00e4llig, der Aufruf von \u201eposting.php\u201c Interessant ist es doch genau die Seite, die verwendet wird wenn ein Forumsbeitrag gespeichert wird.<\/span><\/span><\/p>\n

Also hineingeschaut in den \u201ePurePath\u201c wie DynaTrace es nennt. Also die Aufsplitterung der Service Aufrufe innerhalb einer Transaktion<\/span><\/span><\/p>\n

<\/span>\u00a0<\/span><\/span>Einen langsamen Request rausgesucht:<\/span><\/span><\/p>\n

<\/span>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 \u2026 was ist das? Das ist Interessant:<\/span><\/span><\/p>\n

<\/span><\/p>\n

Zwischen dem Select auf die Tabelle Smilies und dem folgenden update liegen 3 Sekunden ohne das was passiert. Aber warum?<\/span><\/span><\/p>\n

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.<\/span><\/span><\/p>\n

Aber wir wissen ja noch immer nicht, was die Ursache f\u00fcr diese Verz\u00f6gerung ist, also m\u00fcssen wir mal ins PHP hineinschauen.<\/span><\/span><\/p>\n

Also hinein in die Antwortzeit Analyse, zun\u00e4chst mal sehen wir auch hier, dass die PHP Ausf\u00fchrungszeit den L\u00f6wenanteil der Antwortzeit ausmacht.<\/span><\/span><\/p>\n

<\/span><\/p>\n

Aber weiter Unten wird es endlich Konkreter:<\/span><\/span><\/p>\n

<\/span><\/p>\n

Fast 91% der Zeit werden in der Methode gethostbyname verbraucht aus dem Modul phpbb_checkdnssrr.<\/span><\/span><\/p>\n

Ohne den Souce Code zu kennen, liegt es also nahe, dass die lange Zeit bei DNS Server Abfragen entstehen.<\/span><\/span><\/p>\n

Dies war der entscheidende Hinweis. Jetzt konnte ich das Problem weiter analysieren und beheben. Siehe dazu den Rahmenartikel XXX. <\/span><\/span><\/p>\n

Fazit:<\/span><\/span><\/strong><\/p>\n