Die "Performance-Serie" Teil 1. Testgetriebene Leistung.

Einige meiner Kollegen und ich haben kürzlich beschlossen, unser Wissen zum Thema "Leistung" auf diesem Medium zu teilen. Sie lesen gerade den ersten Blog einer Serie, in der ich einen testbasierten Ansatz vorstelle, mit dem wir bei der Auslieferung unseres Projekts eine angemessene Leistung sicherstellen.

Getestet

Zunächst einmal sollten Sie wissen, dass "test-driven" in der Welt der Java-Programmierung üblich ist (oder sein sollte ;-). Es wird jedoch nur auf der Ebene der Unit-Tests angewendet: Man schreibt einen Unit-Test, der zeigt, dass eine bestimmte Funktion noch nicht (richtig) implementiert ist. Das Testergebnis ist "rot". Dann schreibt man den Code, der den Test "behebt", so dass der Test nun erfolgreich ist und "grün" anzeigt. Schließlich sieht man sich den Code an und "refaktorisiert" ihn, um sicherzustellen, dass Aspekte wie Wartbarkeit und Lesbarkeit erfüllt sind. Dieser Ansatz der Softwareentwicklung ist als "testgetriebene Entwicklung" bekannt und wird manchmal auch als "rot-grün-refactor" bezeichnet.

Testgesteuerte Leistung

Lassen Sie uns nun sehen, was passiert, wenn wir versuchen, "test-driven" auf eine nicht-funktionale Anforderung wie "Leistung" anzuwenden. Natürlich brauchen wir einen Test und das Testergebnis muss "rot" oder "grün" sein. Es gibt viele Aspekte im Bereich "Leistung", also nehmen wir einen für unsere Geschichte: Wir nehmen an, wir bauen eine webbasierte Anwendung und betrachten ihre Antwortzeiten. Nun kann unser Test etwa so aussehen: "Die mittlere Antwortzeit des Systems bei der Beantwortung der URL soundso muss unter 0,4 Sekunden liegen. Ich persönlich finde eine solche Anforderung hochinteressant, da sie zeitbezogen ist! Diese Art von nicht-funktionalen Anforderungen werden normalerweise für das Endergebnis des Projekts gestellt. Aber wie sieht es während des Projekts aus?

Testkriterien während eines Projekts

Ich behaupte, dass die Kriterien der nicht-funktionalen Anforderungen während eines Projekts geändert werden sollten. Die Reaktionszeiten des Systems sollten zu Beginn des Projekts extrem gut sein, da es kaum ein System gibt! Am Ende des Projekts, wenn fast alle Entwicklungsarbeiten abgeschlossen sind, muss die Reaktionszeit nur noch "gut genug" sein. Daher sollten die Kriterien z.B. mit Hilfe eines Bildes wie diesem geplant werden:

Abbildung 1. Planung eines mittleren Reaktionszeitkriteriums während eines Projekts

Was passiert, wenn wir "den Aufbau unterbrechen"?

Während der Entwicklung führen wir ständig Tests durch, zum Beispiel mit einem Tool wie JMeter. Wir sammeln die durchschnittlichen Antwortzeiten kritischer URLs und sehen, ob wir das Kriterium des Tages einhalten. Eines Tages "brechen wir den Build ab": wir erfüllen unser Kriterium nicht, da der Test "rot" ist. Was nun? Für mich ist das noch faszinierender als die flexiblen Kriterien, die wir oben gesehen haben. Bei der testgesteuerten Softwareentwicklung stoppt man normalerweise die gesamte Entwicklung, wenn der "Build kaputt ist". Alle Tests müssen grünes Licht zeigen. In unserem Fall rate ich Ihnen dringend: Handeln Sie nicht jetzt, sondern planen Sie eine Leistungsoptimierung! Während einer solchen Aktivität stimmen wir das System ab, bis der Test wieder "grün" ist. Unser fehlgeschlagener Antwortzeittest löst also eher eine Planungsaktivität aus, als dass er eine sofortige Aktion zur Behebung des Problems auslöst.

Vermeidung von Verschwendung

Angenommen, wir haben eine Leistungsoptimierung geplant, da unser Test "rot" ist. Wie viel Arbeit müssen wir leisten? Wie können wir den Arbeitsaufwand minimieren? Oder anders gesagt, wie verhindern wir Verschwendung? Wenn wir das System so einstellen, dass der Test gerade noch "grün" ist, ist die Wahrscheinlichkeit groß, dass er nächste Woche "rot" wird und wir erneut eine Leistungsoptimierungsmaßnahme durchführen müssen. Das ist nicht sinnvoll. Wenn wir andererseits weit über das "grüne" Kriterium hinaus optimieren, neigen wir dazu, zu viel Arbeit zu machen. Die Lösung ist einfach: Verwenden Sie eine Untergrenze! Wenn wir also das "grüne" Kriterium von, sagen wir, 0,2 Sekunden zu einem bestimmten Zeitpunkt nicht erfüllen, optimieren wir so lange, bis wir eine Reaktionszeit von 0,15 Sekunden erreicht haben, und hören dann auf zu optimieren. Dies führt zu einer Leistungsplanung wie dieser:

Abbildung 2. Planung einer mittleren Reaktionszeit während eines Projekts bei gleichzeitiger Vermeidung von Verschwendung

Testgetriebene Leistung in einer agilen Perspektive

Natürlich ist die anfängliche Leistungsplanung eine sehr wilde Schätzung. An einer solchen Schätzung ist nichts auszusetzen! Es ist das Beste, was wir zu diesem Zeitpunkt wissen. Während des Projekts passen wir unsere Leistungsplanung natürlich an. Das Wichtigste dabei ist, dass wir uns ständig um die Reaktionszeit des Systems kümmern, da wir immer einen Test zur Hand haben, der uns "rot" oder "grün" anzeigt.

Pro und Kontra

Der oben skizzierte Ansatz hat zwei große Vorteile. Offensichtlich erkennen wir schlechte Designentscheidungen, die zu schlechten Reaktionszeiten führen, in einem frühen Stadium. Daher hat das Projektmanagement die Kontrolle und ist nicht einem großen Projektrisiko ausgesetzt, da wir nicht mehr mit einem schlecht funktionierenden System in späten Phasen des Projekts konfrontiert werden. Zweitens vermeiden wir durch die Verwendung einer Untergrenze Verschwendung bei Optimierungen.Ein möglicher Nachteil ist, dass unser Ansatz im Vergleich zu einem Ansatz, bei dem wir das Verhalten eines Systems nur in der Produktion überprüfen und uns auf schnelle Reaktionen zur Behebung von Problemen verlassen, sehr wohl teurer sein könnte. Mein Kollege Adriaan Thomas wird diesen Aspekt im nächsten Blog dieser Serie näher beleuchten.