Sparen mit Application Performance Engineering

Wer bei einem Software-Projekt zuerst die Umsetzung der fachlichen Anforderungen und erst dann die Performance fokussiert, macht einen fatalen Fehler.

Thomas Mahringer ist Senior Performance Architect & Training Manager bei dynaTrace Software.

Abbildung 1: Ereignisablauf einer Benutzeraktion durch die Systemkomponenten.

Praxisorientiertes, kosteneffizientes Application Performance Engineering bedingt, dass Architektur- und Leistungsschwachstellen früh erkannt und Diagnosedaten effizient zwischen allen Beteiligten ausgetauscht werden. Werden indes die fachlichen Anforderungen zu stark priorisiert und die Performance zu stiefmütterlich behandelt, führt ein unternehmenskritisches Software-Projekt nicht selten auf dem direkten Weg in die Verdammnis. Ein Szenario, das jedem Entwickler bekannt vorkommen dürfte.

Schon die Erfassung aller funktionalen und nicht-funktionalen Anforderungen sowie deren Nachverfolgbarkeit (Traceability) im Rahmen des Requirements Engineering bedingt die intensive Zusammenarbeit unterschiedlicher Stakeholder in einem Software-Projekt. Zunächst müssen die funktionalen Anforderungen verstanden und – basierend auf der geeigneten Software-Architektur – in geeignete Abläufe gegossen werden. Im Erwartungsdreieck «Ressourcen – Anforderungen – Qualität» wird dabei den nichtfunktionalen Anforderungen oft zu wenig Priorität eingeräumt. Vor allem die Performance wird oft vernachlässigt, da sie als zusätzliches «Deliverable» empfunden wird, das man auch in späteren Phasen nachreichen kann.

Ein fataler Fehler. Denn besonders in modernen Enterprise-Systemen, in denen viele Komponenten ineinander greifen und Frameworks einen guten Teil der Basis-Software-Infrastruktur abdecken, ist exaktes Verständnis der Performance-Implikationen dieses Zusammenspiels nötig. So kann zum Beispiel ein in serviceorientierte Komponenten zerlegtes System hervorragend wartbar, gut verständlich, leicht konfigurierbar und gut deploybar sein. Es mag überdies auch bei 100 konkurrenzierenden Anwendern hervorragend funktionieren. Doch wollen 500 User gleichzeitig damit arbeiten, treten plötzlich Performance- oder Speicherprobleme auf.

Grund für solche Probleme ist das Vorhandensein einer Art «transitiver Hülle» der in diesem System beteiligten Komponenten: Das Verhalten der Komponente N hat erheblichen Einfluss auf das Verhalten der Komponente N+M und umgekehrt. Die Gesamtleistung des Systems korreliert direkt mit dessen Gesamtarchitektur. Und zwar nicht nur mit der statischen Architektur, sondern vor allem auch mit dem anwendungsbezogenen Ablauf durch das Gesamtsystem. Abbildung 1 verdeutlicht den Sachverhalt: Jede Benutzeraktion löst einen Ablauf durch verschiedene verteilte Komponenten aus.

Diese Korrelation zwischen Leistung und Architekur bedingt, dass die dynamischen Zusammenhänge des Systems und deren Auswirkungen auf die Systemleistung bereits während der Architektur- und Designphase verstanden werden müssen. Eine zu späte Berücksichtigung führt unweigerlich zu umfangreichem Refactoring und damit zu neuerlichen Durchläufen von Entwicklung, Test und Integration. Die Folge sind wesentlich höhere Kosten.