Die Last mit der Last und wie Performance-Tests Abhilfe schaffen können

Oder wie es dennoch möglich ist, Projekte in Bezug auf die Performance so zu gestalten, dass sie mit ruhigem Gewissen in Betrieb genommen werden können.

Dieser Artikel zeigt Ihnen, welche Herausforderungen im Zusammenhang mit der Last und der Leistung während eines Softwareprojekts auftreten können und welche technischen, organisatorischen, personellen und externen Auswirkungen diese haben. Außerdem erfahren Sie mehr über die häufigsten Ursachen und wie Sie mit diesen Risiken umgehen können, um das Projekt dennoch vor finanziellen Schäden zu bewahren.

Inhaltsverzeichnis

• Welche Herausforderungen können im Projektverlauf auftreten?
• Welche Komplikationen können später im Betrieb auftreten?
• Wie sieht die ideale Welt aus?
• Und wenn das Projekt dadurch zu teuer wird?
• Was tun bei Performance-Problemen, wenn das Projekt bereits läuft?
• Fazit

Welche Herausforderungen können im Projektverlauf auftreten?

Unsere Expertinnen und Experten beschäftigen sich intensiv mit dem Thema der nicht-funktionalen Anforderungen und analysieren die Ursachen, die die Performance beeinträchtigen können. Aus vielen bearbeiteten Anfragen und durchgeführten Projekten können wir folgende, häufig auftretende Ursachen feststellen:

• Schwächen in oder ganz fehlende Leistungsanforderungen führen oft spät im Projektverlauf zu unerwarteten Kosten. Kaum ein Projekt beschäftigt sich frühzeitig mit den nicht-funktionalen Anforderungen wie Performance. So fehlen oft aussagekräftige Kennzahlen wie Mengengerüste oder erwartete Nutzerzahlen. Dies führt regelmäßig dazu, dass die entwickelten Systeme überhöhte Antwortzeiten, langsame Verarbeitungen, häufige Serverfehler oder eine Anfälligkeit für Angriffe aufweisen.
• Es werden neue und unerprobte Technologien eingesetzt, bei denen zu Beginn der Entwicklung nicht klar ist, ob und wie die zu erwartende Last bewältigt werden kann. So werden aus Unerfahrenheit falsche Annahmen getroffen oder es gibt zu wenig belastbare Informationen darüber, wie sich die eingesetzte Software (Framework, Service etc.) bei höheren Nutzerzahlen oder häufiger und großer Datenverarbeitung verhält.
• Architekturen beziehungsweise notwendige Architekturabstimmungen im Projektverlauf fehlen. Dies ist insbesondere im agilen Umfeld der Fall, in dem es oft keine dedizierten Architekturspezialisten in den DEV-Teams gibt.

• Betriebsanforderungen, insbesondere zur Systemüberwachung, fehlen, sodass bereits in der Entwicklungsphase keine Leistungsbewertungen und damit auch keine Leistungsoptimierungen vorgenommen werden können. Über den gesamten Entwicklungsprozess fehlen Analysedaten, die Aufschluss darüber geben, ob das Zielsystem die impliziten oder auch explizit genannten Performance-Anforderungen erfüllt.
• Externe Software, die als Zulieferung von einem anderen Dienstleister oder als Standardsoftware ein Teil des Gesamtsystems bildet, kann den erwarteten Leistungsansprüchen nicht genügen.
• Eine unzureichende Kommunikation während des Projektverlaufs führt häufig zu weiteren Fehlern. Software, die ohne klare Abstimmung, mit unklaren Anforderungen oder auf Basis zahlreicher Annahmen entwickelt wird, kann zudem zu Performance-Einschränkungen führen.

Welche Komplikationen können später im Betrieb auftreten?

Einige Einschränkungen ziehen sich von der Entwicklungsphase bis in den Betrieb und werden selten mit geeigneten Maßnahmen angegangen.

• Fehlende Skalierung, die eine Ausnutzung der vorhandenen Ressourcen optimiert, sodass nur so viel Leistung verwendet wird, wie gerade benötigt wird. Die Systeme sollen im Idealfall dynamisch mitwachsen und damit erst bei Erreichen der Leistungsgrenzen die Ressourcen dazubuchen.
• Selbst bei festgelegter Leistung einer Umgebung sollte bestimmt werden können, welche Leistungsreserven diese besitzt. Gerade bei zunehmenden Datenaufkommen.
• Fehlendes oder unzureichendes Systemmonitoring im Betrieb der Software beziehungsweise des Systems verhindert ein frühzeitiges Eingreifen und proaktive Maßnahmen.

Wie sieht die ideale Welt aus?

Wie schon von vielen anderen Personen aus Produktentwicklung und -management erwähnt, ist die frühe Einbindung der QS, aber auch des Betriebs in den Projektverlauf immens wichtig. Man erreicht hiermit einen weiteren Blick mit möglichst allen Standpunkten derer, die in Entwicklung und Betrieb der Applikation involviert werden. So kann die frühzeitige Beschäftigung aller Rollen, mit Anforderungsanalyse, Design, Architektur und Spezifikationen, im Entwicklungsvorgehen einen finanziell attraktiven Beitrag leisten. Gerade Überlegungen und Festlegungen zu nicht-funktionalen Anforderungen wie Performance, Effizienz, Zuverlässigkeit, Wartbarkeit etc. können während der Entwicklung somit berücksichtigt werden.

So entstehen automatisch agile Prozesse und DevOps-Vorgehensweisen, die richtig umgesetzt und gefördert einen enormen Vorteil bieten.

Und wenn das Projekt dadurch zu teuer wird?

Das Prinzip der frühzeitigen Einbindung aller Rollen macht kein Projekt teurer, sondern die Aufwände verlagern sich stärker an den Anfang des Projekts. Die Mitarbeitenden werden auf andere Weise in den Gesamtablauf involviert. In einem agilen Vorgehen fällt dies durch die iterative Arbeitsweise kaum auf. Denn in den kurzen Zeiteinheiten, werden die Aufwände nur in andere Tätigkeiten überführt. So können User Stories Refinements aufwändiger ausfallen, aber dadurch werden Entwicklungsaufwände, nachträgliche Abstimmungsaufwände und Bugfixings beziehungsweise Change-Request-Aufwände vermieden.

Vielleicht ist die Aussage über höhere Kosten auch dem Umstand geschuldet, dass die Aufwandserfassung in keinem Projekt so kleinteilig erfolgt und damit nachgehalten werden kann. Und es ist auch bekannt, dass erhöhte zu erwartende Betriebskosten durch Einsparungen in der Entwicklung kaum als Risiko ermittelt werden und dieser übergreifende Blick oftmals fehlt. Auch wenn es keine Beispiele aus der IT sind, veranschaulichen Großprojekte wie die Elbphilharmonie und Stuttgart 21, wie stark Kosten unterschätzt werden können und welche Folgen unzureichende Risikoanalysen haben.

Was tun bei Performance-Problemen, während das Projekt bereits läuft?

Manchmal lassen sich frühere Fehler nicht mehr ändern und man muss durch die fortgeschrittene Zeit andere Aktivitäten angehen. Es wird nicht immer die beste Lösung sein, aber dennoch kann man ein zufriedenstellendes Ergebnis erreichen.

Schauen wir uns in dieser Situation die Rahmenbedingungen an, die wahrscheinlich eingetreten sind. Ein großer Teil des Budgets ist bereits verbraucht, wir können aus finanziellen Gründen nicht mehr zurück. Zeitlich sind wir schon so weit fortgeschritten, dass eine fristgerechte Fertigstellung kaum möglich ist. Ein Großteil der Anforderungen sind funktional umgesetzt, nur die Performance zeigt Schwächen. Dies ist eine kaum lösbare Situation, um alle Beteiligten zufriedenzustellen.

Grundsätzlich sollte eine klare Priorisierung der Anforderungen und Befunde mit ausreichend Abstufungen existieren. Denn nicht alles kann Prio eins sein. Außerdem sollten die Leistungsanforderungen erfasst und diese ebenfalls priorisiert werden. Zudem müssen die Hauptgeschäftsfälle definiert werden, die später als Szenarien in dem Performance-Test-Tool umgesetzt werden. Diese sollte man eher mit Bedacht auswählen, als zu viel und zu schwierig umzusetzende Szenarien zu wählen, es besteht Zeitmangel. Es ist wichtig, ein ausreichendes Systemmonitoring einzurichten, das jederzeit Einblicke in den Systemzustand gewährt und schnelle Reaktionen zulässt.

Für uns gibt es ab hier drei gute Möglichkeiten weiterzumachen:

• Eine Reihe von wiederholten Performance-Tests mit steigender Last wird ausgeführt und dazu die Metriken gesammelt, um zu zeigen, ob die Erwartungen und die tatsächliche Leistung des Systems übereinstimmen. So wird die Leistungsgrenze bestimmt und man kann in der Entwicklung an den richtigen Schrauben drehen und die Verbesserung stetig mit erneuten Wiederholungsläufen testen.
• Alternativ zu den wiederholten Performance-Tests wird mit Performance-Testläufen die Leistungsgrenze des Systems ermittelt. Auf Grundlage dieser Werte wird ein Betriebskonzept erstellt, in dem die Anzahl der User festgelegt werden, die in Betrieb gehen. Ein zusätzliches Systemmonitoring überwacht diesen und ermöglicht ein schnelles Eingreifen. Später können weitere Anwenderkreise aufgeschaltet werden, wenn das System weiterentwickelt wurde und die Leistungsmerkmale den stabilen Betrieb gewährleisten.
• Unser dritter Vorschlag besagt, dass die Weiterentwicklung hart gestoppt wird und nun alle Ressourcen in die Optimierung des bestehenden Systems gesteckt werden müssen. Somit bestünde die Chance, dass die erstrebte Zahl der Anwendenden erreicht wird. Auch hier müssen durch Performance-Tests die Hauptanwendungsfälle ausgeführt und die Leistungsgrenzen bestätigt werden. Sicherlich sind einige Iterationen notwendig, um die Zielgröße zu erreichen. Dies kann zu einer Lösung führen, die innerhalb des Zeitplans und des Budgets funktioniert. Nicht realisierte Funktionalitäten müssen zu einem späteren Zeitpunkt implementiert werden.

Fazit

Ein perfektes Anforderungsmanagement, Risikomanagement, Projektplanung, Architektur und Design würden nicht-funktionalen Anforderungen von Anfang an berücksichtigen. Durch die Komplexität erreichen wir jedoch selten diesen Idealzustand.

Wenn Sie aus verschiedenen Gründen schon mitten in der Projektumsetzung stehen, dann versuchen Sie, einem unserer Vorschläge zu folgen. Ziehen Sie sich zurück und lassen Sie sich beraten, was sie als Minimum an Funktionalität liefern können, und wie Sie mit den richtigen Mitteln die Performance-Probleme angehen und prüfen Sie Ihr System auf die Leistungsanforderungen. Aus Erfahrung wissen wir, dass fehlende Features und Budgetnachforderungen auf allen Seiten unangenehm werden. Sie werden um diese Diskussionen nicht herumkommen.

War dieser Artikel hilfreich für Sie? Oder haben Sie weiterführende Fragen zu Performance-Tests? Schreiben Sie uns einen Kommentar oder rufen Sie uns gerne an.