Web-Performance in sieben Schritten; Schritt 5: Überwachen und diagnostizieren

Letztes Mal habe ich über die Bedeutung von kontinuierlichen Leistungstests gebloggt. Wenn Sie Leistungstests genau wie Unit-Tests kontinuierlich schreiben und ausführen, erhalten Sie frühzeitig Erkenntnisse über die Leistung neuer und geänderter Funktionen Ihrer Software. So bleiben Überraschungen aus und Sie sind produktiver. Jetzt werde ich über Überwachung und Diagnose bloggen.Wenn eine neue Version der Software in die Produktionsumgebung freigegeben wird, stellt sich immer die Frage: Wird sie tatsächlich so funktionieren, wie wir es in den Test- und Abnahmeumgebungen gesehen haben? Und wir halten die Daumen gedrückt.

Daher ist es in solchen Fällen wichtig, sorgfältig zu überwachen, was mit der Leistung und Verfügbarkeit der Anwendung geschieht. Es gibt alle möglichen Tools und Dienste, um die Verfügbarkeit und die Antwortzeiten Ihrer Website zu überwachen, wie Uptrends, Site24x7 und Dotcom-monitor. Sie betrachten die Anwendung als eine Blackbox und messen einmal in mehreren Minuten. Das ist sehr nützlich, aber um im Falle einer Katastrophe die richtigen Maßnahmen ergreifen zu können, muss man das Problem genau lokalisieren können. Es ist daher unerlässlich, auf mehreren Ebenen und für mehrere interne Anwendungsteile zu überwachen. Denken Sie bei den Ebenen an Hardware, Betriebssystem, Anwendungsserver, Webserver, Datenbank und Anwendung. Die Messung interner Java-Anwendungsteile kann mit JAMon durchgeführt werden. JAMon ist eine Open Source Timing-API und funktioniert im Grunde wie eine Stoppuhr mit einem start()- und stop()-Aufruf. Jede Methode, die Sie messen möchten, erhält ihre eigene Stoppuhr (oder Zähler). Wir beschäftigen uns am ersten Tag unseres Kurses Speeding up Java Applications mit JAMon als einem der Tools zur Zeitmessung. Abbildung: JAMon API start()- und stop()-Aufrufe in einem Spring-Interceptor Jeder Zähler verwaltet Statistiken wie die Anzahl der Aufrufe, Durchschnitt, Maximum, Standardabweichung usw. und diese Informationen können angefordert werden. Die einzelnen Aufrufe werden nicht gespeichert. Dieser Ansatz führt zu einer geringen Speichernutzung und einem geringen Leistungs-Overhead, allerdings um den Preis eines gewissen Informationsverlusts. Vor kurzem ist ein neuer Konkurrent von JAMon erschienen: Simon. Er behauptet, der Nachfolger von JAMon zu sein, obwohl er noch einige Kinderkrankheiten hat (hatte).Dann stellt sich die Frage: Wo soll man messen? Die Antwort lautet, dass es am sinnvollsten ist, alle eingehenden Aufrufe wie Webanfragen und ausgehende Aufrufe z.B. an die Datenbank zu messen. Außerdem Teile wie Spring Beans, EJB's und DAO's. Die Messung dieser Teile ist nicht nur bei neuen Versionen relevant, sondern es ist auch sinnvoll, Trends und Nutzungsspitzen zu überwachen, um verschiedene Probleme schnell lösen und verhindern zu können. Das Open-Source-Tool JARep bietet die Möglichkeit, JAMon-Daten aus einem Cluster in einer Datenbank zu speichern und Trends und Veränderungen grafisch zu überwachen. Abbildung: JARep zeigt den Trend zu steigenden Antwortzeiten ab dem 15. Oktober auf zwei der vier Produktions-JVMs. Kundengeschichte Wir hatten folgende Situation bei unserem Kunden. Die Bearbeitung einer Bestellung nahm über einen Zeitraum von mehreren Wochen immer mehr Zeit in Anspruch. Dies geschah, obwohl keine neue Version eingeführt wurde und keine andere Seite langsamer wurde. Dieses Verhalten war uns ein völliges Rätsel, bis wir in unserem JARep-Überwachungstool genauer nachschauten. Es stellte sich heraus, dass der Störenfried eine DAO war, die eine vorbereitete Anweisung ausführte, bei der nur ein Teil der Variablen Bind-Variablen waren. Mit Hilfe von JARep konnten wir zurückverfolgen, wo der Trend der steigenden Antwortzeit begann und wann die Probleme auftraten. Wir konnten auch sehen, dass dieses Problem nur auf einem der beiden Rechner auftrat. Mit diesem Wissen und seinem Logbuch konnte sich der Betreiber daran erinnern, dass er am Starttag mit einem neuen JDBC-Treiber experimentiert hatte, um ein Speicherleck zu beheben. Dies schien an der Leistung nichts zu ändern, was anfangs auch der Fall war. Die Probleme traten erst in den folgenden Wochen langsam auf. Sie hatten den neuen Treiber an Ort und Stelle gelassen, der sich später als Zeitbombe entpuppte. Als wir den alten Treiber wieder einsetzten, verschwand das Problem. Diese Erfahrung aus dem wirklichen Leben zeigt, wie nützlich die Überwachung und Trendanalyse von Anwendungsinterna ist. Das nächste Mal werde ich über evidenzbasiertes Tuning bloggen.