Performance-Analysen jenseits von Code

The world outside your code

Ein Kollege bekam die Aufgabe, ein Etikett neu zu gestalten. Dieses Etikett sollte mittels JasperReports designt und als PDF – und nicht wie bisher direkt in der Druckersprache des Herstellers – an einen Etikettendrucker gesendet werden.

Nachdem die Tests im Testsystem erfolgreich verliefen, wurde die Änderung in die Produktion überführt. Sofort hagelte es Proteste von Kunden! Während das Drucken eines Etiketts früher unter 1 Sekunde dauerte, nahm der Druck des neuen Etiketts nun ca. 35 Sekunden in Anspruch. Der Kollege optimierte seinen Code und konnte die Dauer auf 32 Sekunden reduzieren. Weitere Kollegen kamen zur Hilfe und optimierten den Druck auf 31 Sekunden. Dann wurde ein Administrator hinzugezogen, der den Netzwerkverkehr analysierte. Schnell wurde klar, dass ein anderer Administrator einen neuen Druckertreiber auf dem produktiven Server installiert hatte. Dieser Druckertreiber fragte den Drucker, ob genügend Etiketten zum Drucken verfügbar waren (Komfort-Funktion!). Da dieses Feature auf den produktiven Druckern jedoch deaktiviert war, wartete der Druckertreiber bis zu einem Timeout auf eine Antwort. Tja, dieses Timeout war 30 Sekunden lang! Hinzukam ein Implementierungsfehler des Treibers, der dazu führte, dass trotz fehlender Antwort der Druck an den Drucker geschickt wurde.

In diesem Blogbeitrag möchten wir zeigen, wie Sie mit Performance-Problemen in der „Welt da draußen“, jenseits von Code umgehen können.

Was ist überhaupt Performance?

In der Informatik beschreibt Performance das Leitungsverhalten von Hard- und Software. Ein Beispiel ist z.B. die Anzahl von Buchungen in einer bestimmten Zeit.

Wenn Sie die Performance eines Systems beurteilen wollen, sollten Sie auch die Umgebung kennen, in der diese erreicht wird. Versuchen Sie einmal ein Bild Ihrer Umgebung zu skizzieren. Wichtig ist dabei nicht die Schaffung eines möglichst detaillierten Bildes, sondern einer einfachen Skizze, die Ihnen konkret hilft! Die Optik ist dabei relativ unwichtig, auf Zusammenhänge und das gewonnene Verständnis kommt es an. Nehmen Sie sich für eine solche Skizze maximal 10 Minuten Zeit, denn wenn Performance-Probleme in der Produktion auftreten, muss es schnell gehen.

Bei dem Beispiel mit dem langsamen Etikettendruck sieht das Softwaresystem bspw. wie folgt aus:

Nehmen Sie nun das Bild und ergänzen sie es durch Tools, die ihnen helfen können, die Performance an den Schnittstellen zu messen.

Sicherlich gibt es immer wieder Punkte, an denen Sie hier keine Möglichkeit finden, die Performance zu messen; genau diese „blinden Flecken“ gilt es zu ermitteln.

Wo geht die Zeit verloren und wo finden Sie die relevanten User?

„Fühlt“ sich das System langsam an, so kann dies ein sehr subjektives Empfinden der User sein. Aber gerade diese User sind es, die ein System tagtäglich bedienen und deshalb sehr schnell merken, dass etwas „nicht rund läuft“. Daraus ergibt sich, dass Sie diese User in die Performance-Analyse einbeziehen sollten. Aber wo finden Sie die relevanten User?

So wie wir mittels Skizze die technische Umgebung des Etikettendrucks erkundet haben, benötigen Sie eine Übersicht, welche User Ihnen bei der Suche nach Performance-Problemen helfen können. Sie benötigen konkrete Ansprechpartner. Nutzen Sie das Bild der Systemumgebung und leiten Sie entsprechende Anwender ab. Fragen Sie sich bspw.:

• Wer nutzt das System an der Stelle, wo das Problem erkennbar wird?
• Wer arbeitet noch mit dem System: am Schritt davor, am Schritt danach?

Mit echten Menschen sprechen und gut zuhören

Ja, jetzt müssen Sie mit echten Menschen sprechen. Vielleicht scheuen Sie sich davor, Ihren Kunden anzusprechen, weil er gerade eben entnervt und wütend bei Ihnen angerufen hat. Versuchen Sie, sich in seine Lage zu versetzen. Entwickeln Sie Empathie. Das ist gar nicht so schwer, gutes Zuhören kann schon reichen.

Werfen wir einen Blick auf die verschiedenen Formen des Zuhörens. Oft hören wir zu, um selbst zu sprechen. Wir lauern auf die Gelegenheit, den Redefluss des anderen zu unterbrechen, um dann das Wort zu ergreifen. Für schwierige Situationen brauchen wir aber

• aufnehmendes,
• aktives und
• empathisches Zuhören.

Aufnehmendes Zuhören dient der Informationsbeschaffung!

Signalisieren Sie, dass Sie aufmerksam sind und lassen Sie das Gegenüber sprechen. Fragen Sie nach: „Erzählen Sie doch bitte mal, was gerade bei Ihnen los ist. Ich bin ganz Ohr!“.

Aktives Zuhören zeigt, dass Sie verstehen wollen!

Melden Sie zurück, was Sie gehört haben: „Ich würde gerne kurz zusammenfassen, was ich verstanden habe.“ „Bei mir ist angekommen, dass…“.

Empathisches Zuhören greift die Emotionen des Gegenübers auf!

Wir nehmen ernst, wie es dem anderen gerade geht. Das drücken wir aus, indem wir die Gefühle widerspiegeln, die wir bei dem anderen wahrnehmen: „Das klingt nach Frustration!“ „Da höre ich viel Ärger heraus!“.

Versuchen Sie, sich in die Lage des Nutzers zu versetzen. Welche Auswirkungen hat das Performance-Problem für ihn persönlich? Nehmen Sie sich wirklich Zeit zum Zuhören. Ihr Gegenüber fühlt sich dadurch besser verstanden und ernst genommen.

Die Fachlichkeit verstehen

Fragen Sie die Anwender, ob sie einen bestimmten, langsam laufenden Use Case ermitteln können. Sollten Sie die Antwort erhalten, dass einfach alles langsam funktioniert, so definieren Sie mit den Usern einen spezifischen Anwendungsfall, mit dem Sie versuchen, den Performance-Problemen auf die Spur zu kommen. Idealerweise beschreiben Sie einen Ablauf, den Sie im Anschluss selbst durchspielen können.

Nutzen Sie Visualisierungstechniken, damit Sie gemeinsam mit den Usern den Use Case Schritt für Schritt durchsprechen können. Machen sich auf die Suche nach Ausnahmen und alternativen Abläufen und notieren Sie diese stichpunktartig. Gehen Sie anschließend den gesamten Ablauf nochmals durch, um die Stellen zu identifizieren, an denen sich die Performance verändert.

Versuchen Sie ein Gefühl zu bekommen, ob der Ablauf großen Schwankungen unterworfen ist. Versuchen Sie herauszufinden, wo und wie Sie den konkreten zeitlichen Verlauf ermitteln können. Im einfachsten Fall wird die Zeit an bestimmten Stellen protokolliert, in anderen Situationen lässt sich sich evtl. durch Tools ermitteln. (Ein Tipp aus der Praxis: Sollten Daten bspw. zwischen verschiedenen Systemen ausgetauscht werden, achten Sie darauf, die Uhren der Systeme zu synchronisieren. Sollte dies nicht möglich sein, notieren Sie sich unbedingt die Differenz der Systeme.)

Ein weiterer wichtiger Punkt: Denken Sie daran – selbst wenn etwas bei Ihnen in einer Testumgebung schnell funktioniert, bei den Anwendern muss das nicht der Fall sein (Stichwort: The world outside your window). Im Zweifelsfall empfiehlt sich der Gang zur Fachabteilung und die Überprüfung der Performance vor Ort. Das hat zwei wesentliche Vorteile:

• Sie werden möglicherweise auf Randbedingungen stoßen, die Ihnen gar nicht so bewusst waren, die aber für die Lösung des Performance-Problems elementar sein können.
• Und rein menschlich werden Sie merken, dass diese Art der Wertschätzung sehr gut in der Fachabteilung bei den Anwendern ankommt und diese Ihnen gerne bei der Behebung des Problems helfen.

Machen Sie sich vorher etwas klar: Sie sind zwar der Experte für die Software, die Menschen in der Fachabteilung sind dagegen Experten in ihrem Job. Das Drucken von Etiketten aus unserem Beispiel mag sich vielleicht so anhören, als wäre dafür wenig bis keine Expertise notwendig. Es kann jedoch ein wesentlicher Schritt in einem Prozess sein, der für die Erbringung einer Gesamtleistung im Geschäftsprozess wichtig ist. Dafür sind die Anwender in der Fachabteilung die Experten. Und durch das Performance-Problem der Software können diese nun ihren Job nicht oder nur eingeschränkt ausführen.

Nehmen Sie also die Anwender mit ihrer Expertise ernst und zeigen Sie das auch. Bedanken Sie sich dafür, dass Sie Einblick in die Fachabteilung erhalten und die Anwender sich Zeit für Sie nehmen. Zusätzlich können Sie sich im Vorfeld geeignete Fragen überlegen:

• Was genau machen die Anwender mit dem System und welchen Job soll die Software für sie erledigen?
• Wie gravierend wirkt sich das Performance-Problem auf die Abläufe aus?
• Wie stark sind die Anwender in der Erledigung ihrer eigentlichen Aufgabe eingeschränkt?
• Wie wirkt sich das auf die Anwender persönlich aus? Wie geht es ihnen mit der Situation?

Sie werden feststellen, dass eine solche Offenheit und Einstellung, sowie entsprechende Fragen Ihre Expertise nicht schmälert. Im Gegenteil: Sie schaffen somit Vertrauen. Mit ehrlichem Interesse werden Sie noch stärker als Experte für die Lösung der Performance-Probleme wahrgenommen. Sie signalisieren, dass Sie die Situation und die Herausforderungen wirklich verstehen wollen, um die beste Lösung zu finden.

Und wenn Sie dann auch noch ein paar Kekse dabei haben, werden Ihnen alle Türen offen stehen! 😉

Fazit

Die Beseitigung von Performance-Problemen kann eine große Herausforderung sein. Oftmals ist nichts so, wie es scheint. Es klingt logisch, dass Entwickler – wie im Beispiel mit dem Etikettendruck beschrieben – lokale Optimierungen am Code vorzunehmen. Sinnvoller ist aber zu Beginn ein Blick über den Tellerrand hinaus, auf den Systemkontext und auf mögliche Ursachen jenseits des Codes. Bevor die Optimierung des Codes ansteht, lohnt ein Blick auf “die Welt da draußen”. Falls Sie einmal in eine solche Situation kommen, versuchen Sie diese Welt zu verstehen und die wahren Ursachen kennenzulernen. Die Anwender sind Ihnen dabei sicherlich behilflich.

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Wenn Sie sich mit den beiden Autoren Susanne Mühlbauer oder Thomas Ronzon austauschen wollen, schreiben Sie die beiden einfach auf LinkedIn an. Hier erreichen Sie Susanne Mühlbauer und hier Thomas Ronzon.

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.