Performance-Analyse: The World Outside Your Code

Inhaltsverzeichnis

Jedes Stück Code ist von seiner Umgebung abhängig – nicht nur in der Welt der Microservices. Das führt gelegentlich zu schwer aufspürbaren Fehlern oder Schwierigkeiten, deren Ursachen nicht im Quellcode stecken, sondern in der Außenwelt. Zur Veranschaulichung mag folgender Vorfall dienen, der einem Kollegen passiert ist:

Er bekam die Aufgabe, ein Etikett für den Versand an einen Etikettendrucker neu zu gestalten. Dabei sollte der Code den Aufkleber nicht mehr wie bisher direkt in der Druckersprache des Herstellers verschicken, sondern mit JasperReports gestalten und als PDF umsetzen. Nachdem die Probeläufe im Testsystem erfolgreich waren, hat der Entwickler die Änderung in die Produktion überführt.

Kurz darauf hagelte es Proteste vom Kunden. Während das Drucken eines Etiketts früher weniger als eine Sekunde dauerte, benötigte der Druck seit der Änderung etwa 35 Sekunden. Der Kollege optimierte seinen Code und kam auf 32 Sekunden. Weitere Kollegen kamen hinzu und optimierten den Druckvorgang auf 31 Sekunden. Erst ein hinzugezogener Administrator konnte schließlich die Wurzel des Problems ausmachen: Zufällig hatte ein anderer Administrator auf dem produktiven Server einen neuen Druckertreiber installiert, der den Drucker fragte, ob er genug Etiketten für die Ausgabe hat. Diese Komfortfunktion war jedoch auf den produktiven Druckern deaktiviert, und der Treiber wartete bis zum Timeout auf eine Antwort. Zu den damit vergeudeten 30 Sekunden kam ein Implementierungsfehler des Treibers, der dazu führte, dass der Druckauftrag trotz fehlender Antwort an den Drucker ging.

Das große Ganze

Hier geht es nicht um Laufzeitanalysen oder dem Performance-Tuning einzelner Teile (Microperformance-Tuning), sondern um Wege zur globalen Analyse. In der Informatik beschreibt Performance das Leistungsverhalten von Hard- und Software. Ein Beispiel ist die Anzahl von Buchungen in einer bestimmten Zeit oder die Dauer einer Abfrage. Wichtig dabei ist, dass die Zeiten immer Bezug zu einer Umgebung haben. Wer die Performance eines Systems beurteilt, sollte die jeweilige Umgebung kennen. Ein Entwickler-PC ist beispielsweise nicht wie der Produktionsserver für die Massendatenverarbeitung ausgelegt.

Um ein besseres Verständnis dafür zu bekommen, hilft es, die jeweilige Umgebung zu skizzieren. Dabei geht es nicht um ein detailliertes Bild, sondern eins, das Entwicklern einen Weg durch ihre individuelle Umgebung zeigt und dabei unbekanntes Terrain berücksichtigt. Zum Gestalten der Skizze sollten zehn Minuten reichen. Schließlich muss es schnell gehen, wenn Performance-Probleme in der Produktion auftreten. Dabei bleibt keine Zeit für ein akademisch ausgereiftes Bild, das scheinbar vollständig ist, aber nicht zum Ziel führt. Ohnehin zeigt die Skizze unabhängig von der benötigten Zeit nur das, was Entwickler von ihrer Umgebung kennen. Blinde Flecken übersehen sie gezwungenermaßen, da sie nicht kennen, was fehlt.

Teams verfolgen bei der Informationssammlung in der klassischen Softwareentwicklung meist entweder den Top-Down- oder den Bottom-Up-Ansatz. Mit der Entweder-oder-Entscheidung im Vorfeld stoßen sie jedoch irgendwann an Grenzen, weil Systeme häufig nicht vollständig von der Oberfläche bis zum Zugriff auf die Datenbank zu verstehen sind. Gerade bei komplexen Systemen ist an vielen Stellen domänenspezifisches Wissen gefragt, das niemand für alle Bereiche umfänglich besitzt.

Um Zusammenhänge ans Licht zu bringen, ist es hilfreich, immer wieder einen Schritt zurückzugehen und einen neuen Ansatz zu versuchen. Zu vergleichen ist dieser Ansatz vielleicht mit einem Rasenmähroboter, der am Ende seiner Arbeit den ganzen Rasen gemäht hat, ohne vorher genau bestimmt zu haben, wie er die Fläche abgrasen wird.

Eine schnelle Skizze des Szenarios mit dem Etikettendruck gibt einen ersten Überblick über die einzelnen Komponenten (s. Abb. 1). Teams können das Bild gemeinsam an einem Whiteboard erstellen und damit die Gefahr der blinden Flecken minimieren. Schließlich ergänzen sich das Know-how und die Blickwinkel der Mitglieder. Das gilt vor allem für DevOp-Teams, bei denen sich die Perspektiven der Entwickler und die Administratorensicht gegenseitig ergänzen.

Im nächsten Schritt lässt sich die Skizze durch Tools zum Messen der Performance an den Schnittstellen ergänzen. Dabei gilt es auch zu ermitteln, wo sich blinde Flecken befinden, an denen sich die Performance nicht messen lässt.