Leistung

Erfassen Sie die Erwartungen der Benutzer in der Produktdefinitionsphase, quantifizieren Sie die Geschäftsanforderungen und nutzen Sie diese als Grundlage für die spätere Produktarchitektur und das Design.

Komponenten innerhalb einer gut strukturierten Lösung können unabhängig voneinander skaliert werden, beispielsweise durch das Hinzufügen einer weiteren Instanz eines Dienstes. Das Hinzufügen oder Entfernen von Komponenten kann jedoch Folgewirkungen in anderen Teilen der Lösung haben – beispielsweise kann das Hinzufügen eines weiteren Webservers zur Bewältigung eines Anstiegs des Webverkehrs die Notwendigkeit weiterer Message Queues erfordern, um mit Backend-Diensten zu kommunizieren. Die Kenntnis der Skalierungsabhängigkeiten im Voraus kann helfen, das Betriebsverhalten der Lösung zu verstehen und die Erschöpfung der Ressourcen durch Überskalierung einer einzelnen Ressource zu vermeiden.

Gut konzipierte Hybrid-Cloud-Lösungen profitieren von Multiplattform-Architekturen für Skalierungs- und Bursting-Strategien, um Leistung, Sicherheit, Betriebskosten und die Erwartungen der Endbenutzer zu optimieren. Beispielsweise können Workloads auf einer lokalen Infrastruktur mit starken Leistungsgarantien und festen Betriebskosten ausgeführt und bei Spitzenlasten auf einen Cloud-Service-Provider ausgewichen werden.

Das Verschieben von Daten ist teuer. Gut konzipierte Lösungen nutzen die Vorteile der Portabilität und Mobilität von containerisierten Workloads und platzieren Dienste so nah wie möglich an den Daten, die sie nutzen

Lösungen müssen die richtige Plattform und die richtigen Ressourcen auswählen, um den Wert ihrer Architekturen zu maximieren. Eine hybride Cloud-Lösung kann mehrere Clouds umfassen, einschließlich der On-Premises-Infrastruktur, was Architekten die Freiheit gibt, die optimale Ressourcenmischung für die Leistungsanforderungen ihrer Lösung auszuwählen

Lösungen sollten so konzipiert sein, dass sie ihre Verarbeitungskapazität durch Hinzufügen oder Entfernen einzelner Einheiten (Server, Dienste, Netzwerkschnittstellen usw.) erhöhen oder verringern können, anstatt die Kapazität bestehender Einheiten zu verändern, z. B. durch Hinzufügen weiterer CPUs zu einem Server. Um dies zu erreichen, sollten Lösungen die folgenden Architekturprinzipien berücksichtigen:

• Zustandslose Komponenten sind Komponenten, die den Client- oder Sitzungszustand (z. B. eine Benutzeridentität oder die beim vorherigen Aufruf eingegebenen Daten) zwischen Interaktionen nicht beibehalten, wodurch Abhängigkeiten zwischen Clients und einer bestimmten Instanz einer Komponente beseitigt werden. Diese fehlende Abhängigkeit zwischen den Komponenten und ihren Benutzern bedeutet, dass die Lösung durch Hinzufügen oder Entfernen von Komponenteninstanzen skaliert werden kann, ohne dass dies Auswirkungen auf die Benutzer der Dienste der Komponenten hat. Ein gutes Beispiel für eine zustandslose Komponente ist eine Kasse im Geschäft; Solange mindestens eine Kasse verfügbar ist, können die Kunden sich anstellen und ihre Lebensmittel bezahlen, wobei je nach Bedarf Kassierer eingesetzt werden. Der umgekehrte Fall wäre, wenn die Kunden zu Beginn ihres Einkaufs einen bestimmten Kassierer zugewiesen bekämen. Wenn der zuständige Kassierer überlastet oder gar nicht erst verfügbar ist, müssen die Kunden warten oder von vorne anfangen, worunter die Gesamtleistung des Lebensmittelgeschäfts (gemessen an Kunden pro Stunde) leidet.

• Vermeiden Sie langwierige Aufgaben. Wenn eine Lösung langwierige Aufgaben unterstützen muss (zum Beispiel die Durchführung einer komplexen wissenschaftlichen Berechnung), sollte die Aufgabe so gestaltet sein, dass sie durch eine Unterbrechungs- und Checkpoint-Funktion ein- oder ausskalieren kann, die es ermöglicht, die Lösung abzuschalten und neu zu starten, während Ressourcen hinzugefügt und entfernt werden.

• Daten an den Enden. Zustandslose Komponenten können theoretisch unbegrenzt skaliert werden und sind zwischen Clients wiederverwendbar. Hochleistungslösungen übertragen den Zustand, d. h. Benutzer- und Anwendungsdaten, an die Client-Anwendung und die Datenbanken am Ende der Lösungsarchitektur, und behalten keinen Zustand in den dazwischen liegenden Architekturschichten.

Ressourcen:
Zustandsfähig im Vergleich zu zustandslos

Das Entwerfen von Lösungen als eine Reihe von stark zusammenhängenden, lose gekoppelten Komponenten sorgt dafür, Komponenten unabhängig von der Nachfrage nach dem angebotenen Service zu skalieren. Architekturansätze wie serviceorientierte Architektur und Microservices verankern dies als zentrales Designprinzip, also eine Reihe zusammenhängender Dienste, die über hochrangige, locker gekoppelte APIs kommunizieren.

Das Verschieben von Daten zwischen den Komponenten einer Lösung ist oft das zeitaufwändigste Element einer Transaktion. Die Komponenten sollten so ausgelegt sein, dass Frequenz und Umfang der Kommunikation im Verhältnis zur verfügbaren Bandbreite optimiert werden. So kann eine Anwendung, die wiederholt einzelne Werte aus einer Datenbank abruft, bei der Bereitstellung in einem lokalen Netzwerk „ausreichend“ funktionieren, bei der Verlagerung der Komponente zu einem Cloud-Service jedoch ins Hintertreffen geraten.

Der in webbasierten Anwendungen häufig verwendete REST-Architekturstil (Representational State Transfer) ist ein gutes Beispiel für die Art von Ausgewogenheit, die eine gut konzipierte Lösung aufweist. Der vollständige repräsentative Zustand einer Ressource wird als JSON-, XML- oder anderes Dokument übertragen, das die Menge der zu übertragenden Informationen mit der hohen Latenzzeit einer webbasierten Interaktion in Einklang bringt.

Caching trägt dazu bei, den Bedarf an datenproduzierenden Ressourcen und Diensten zu begrenzen. Erwägen Sie die Verwendung von Caching für langlebige, relativ statische Daten und/oder Daten, deren Erstellung „teuer“ ist. Gut durchdachte Lösungen implementieren Caching-Mechanismen auf allen Ebenen der Lösungsarchitektur und platzieren Caches so nah wie möglich am Verbraucher, um die Kommunikation zwischen Verbraucher und Cache zu begrenzen und die Reaktionszeit insgesamt zu verbessern.

Architekten müssen bedenken, dass beim Caching übertrieben werden kann. Ein schlecht konzipierter Caching-Mechanismus oder ein zu großer Cache können die Gesamtleistung der Lösung negativ beeinflussen. Architekten sollten den Caching-Typ und die Strategie bewerten und anschließend die Effektivität des Caches während der Leistungstests und -analysen messen.

Durch asynchrone Nachrichtenübermittlung mittels Message Queues, Callback-Modellen oder anderen Mitteln können Lösungen sowohl effizient skalieren als auch bei Ressourcenknappheit einen sanften Leistungsabfall unter Last ermöglichen. Gut durchdachte Lösungen profitieren von asynchroner Kommunikation, insbesondere Nachrichtenwarteschlangen, um Endbenutzern eine responsive Erfahrung zu bieten und um zu verhindern, dass Benutzeranfragen „verloren“ gehen, wenn eine Komponente ausfällt. Derselbe Mechanismus kann auch verwendet werden, um Systeme miteinander zu verbinden, die unterschiedliche Service-Level oder Betriebszeiten haben. Beispielsweise ermöglicht eine Anwendung, die rund um die Uhr verfügbar ist und mit einem System of Record von 9 bis 17 Uhr über eine Nachrichtenwarteschlange verbunden ist, der Anwendung, Anfragen von Endbenutzern auch dann anzunehmen, wenn das System of Record nicht verfügbar ist.

Lösungen verändern sich im Laufe der Zeit, ebenso wie ihre Leistung. Die Integration einer Leistungsinstrumentierung, die es Entwicklungs-, Test- und Betriebsteams ermöglicht, die Leistungsmetriken einer Anwendung auf nicht-invasive Weise zu erfassen, trägt zur Entwicklung und zum Testen eines robusten Produkts bei, das auf evidenzbasierten Methoden beruht. Die Instrumentierung hilft auch bei Funktionstests, Fehleranalysen und ist eine unschätzbare Hilfe, um die Leistung einer Lösung aufrechtzuerhalten und die Ursachen von Leistungsproblemen in der Produktion zu identifizieren. Die konfigurierbare und nicht-intrusive Instrumentierung unterstützt die Produktüberwachung und gewährleistet die Observability der Lösung im Betrieb, wodurch die DevOps- und SRE-Teams unterstützt werden.

Aus betriebswirtschaftlicher Sicht ist die Gesamtleistung der Lösung wichtig, die sich in ganzheitlichen nicht-funktionalen Anforderungen widerspiegeln muss. Für die Leistungstests auf Einheitsebene, frühe Leistungstests mit Shift-Left-Paradigma und für die Ursachenanalyse von Leistungsproblemen muss man möglicherweise niedrige Anforderungen festlegen, die die Dauer einzelner Aufrufe, die Netzwerklatenz und weiteres einschränken.

Daher werden die allgemeinen Leistungsanforderungen in der Regel auf Prozess- oder Transaktionsebene angegeben, z. B. „Der Kreditvergabeprozess sollte in weniger als 2 Minuten abgeschlossen sein“, ohne Rücksicht darauf, wie die Leistung der einzelnen Prozessschritte und Teilprozesse zum Endergebnis beiträgt. Die Erstellung eines Leistungsbudgets, das jedem Schritt im Entwicklungsprozess Ziele zuweist, liefert messbare Ziele für die Funktionsentwicklungsteams, hilft bei der Identifizierung potenzieller Problembereiche und trägt dazu bei, die Leistungsoptimierung und -Sanierung dorthin zu richten, wo sie am vorteilhaftesten sind.

Leistungsbudgets sollten alle Ebenen der Lösung berücksichtigen, von der Hardware bis hin zum Anwendungscode. Wird auch nur einer dieser Aspekte ausgelassen, besteht die Gefahr, dass die Lösung die Erwartungen der Benutzer nicht erfüllt.

Beim Leistungstest gilt: Probieren geht über Studieren, nur durch die Prüfung der Lösung von Anfang bis Ende können wir also sicher sein, dass sie ihren Anforderungen gerecht wird. Dies spiegelt die ganzheitliche Natur der Leistungsanalyse wider. Das Testen einzelner Komponenten (z. B. Datenbank, Middleware usw.) liefert wertvolle Erkenntnisse in die Leistungsanalyse einer Lösung und hilft, Leistungsengpässe zu identifizieren. Aber das Testen der Komponenten allein reicht nicht aus, da die Interaktionen zwischen den Komponenten zu unerwarteten Engpässen oder anderen Hindernissen und somit zu suboptimalen Ergebnissen führen können.

Die Fokussierung auf die Nutzerwahrnehmung bedeutet, sich hauptsächlich auf die wahrgenommenen Reaktionszeiten und die allgemeine Reaktionsfähigkeit der Benutzeroberfläche zu konzentrieren. Der Kapazitätsabbau ist für die Benutzer in der Regel nicht sichtbar, bis die Produktleistung beeinträchtigt wird. Eine Studie aus dem Jahr 1968 ergab, dass es drei unterschiedliche Größenordnungen bei der Mensch-Computer-Interaktion gibt:

• Eine Reaktionszeit von 100 ms wird als unmittelbar wahrgenommen. Der Mensch hat eine durchschnittliche Reaktionszeit von 250 ms, daher wird alles darunter als sehr schnell/unmittelbar wahrgenommen.
• Reaktionszeiten von einer Sekunde oder weniger sind im Allgemeinen so schnell, dass die Benutzer nicht das Gefühl haben, durch die Systemleistung ausgebremst zu werden.
• Reaktionszeiten von über 10 Sekunden führen dazu, dass die Benutzer die Aufmerksamkeit vollständig verlieren.

Daraus wurde abgeleitet, dass eine Reaktionszeit von 2 Sekunden ideal wäre, und somit sind 2 Sekunden oder etwas mehr ein gutes Ziel für die Reaktionszeit bei Hybrid-Cloud-Lösungen, wenn möglich. Natürlich hängen die Erwartungen der Benutzer davon ab, was sie tun. Zum Beispiel erwartet niemand, dass eine Animation auf Knopfdruck 2 Sekunden dauert, aber 2-3 Sekunden sind ein gutes allgemeines Ziel für die benutzerorientierte Anwendung.

Ausgehend von diesem Prinzip sollten Lösungen mit Hilfe von Tools zum Testen der Benutzeroberfläche die Reaktionszeit der Benutzer als Teil ihres Qualitätssicherungszyklus testen. So wichtig die Latenzzeiten der API-Aufrufe auch für die Gesamtleistung des Produkts sind, die vom Benutzer wahrgenommene Leistung ist zur Gewinnung und Bindung der Benutzerbasis von Bedeutung.

Benutzer haben oft unterschiedliche Erwartungen an eine „gute“ Leistung. Ein Power-User, der eine Anwendung täglich mehrmals verwendet, hat beispielsweise ganz andere Leistungserwartungen als jemand, der dieselbe Anwendung vielleicht einmal im Monat verwendet. Die Benutzer stehen oft auch vor der Herausforderung, zu quantifizieren, was für sie eine „gute“ Leistung bedeutet, und bleiben häufig bei Anforderungen wie „ausreichend schnell“ hängen (was ein schwer zu erreichendes Ziel ist). Auch die individuelle Wahrnehmung der Leistung des Produkts aus Benutzersicht ist ganz unterschiedlich. Für einige ist beispielsweise eine Anmeldezeit von 10 Sekunden akzeptabel (insbesondere, wenn es sich um ein Singleton-Ereignis handelt), für andere könnte sie viel zu langsam sein (insbesondere, wenn die Anmeldung ein häufiger Bestandteil des Workflows ist).

Um die Erwartungen der Benutzer besser zu quantifizieren und zu steuern, wird Folgendes empfohlen:

•  Erstellen Sie die nicht-funktionalen Anforderungen unter Berücksichtigung guter Kenntnisse über die Benutzerbasis und deren typische Anwendungsnutzungsmuster.
  
  
•  Setzen Sie sich frühzeitig im Lösungsentwurfszyklus mit den Benutzern in Verbindung, um zu verstehen, welche Funktionen sie häufig verwenden und eine hohe Reaktionsfähigkeit erwarten, und welche Funktionen sie seltener verwenden und daher langsamere Reaktionszeiten tolerieren können.
  
  
• Verwenden Sie Perzentile, um durchschnittliche oder mittlere Reaktionszeitschwellenwerte zu definieren. Dies berücksichtigt einige unvermeidliche zufällige Variationen der Reaktionsfähigkeit des Produkts und stellt sicher, dass einige wenige Sonderfälle nicht zum Scheitern der allgemeinen Produktakzeptanz führen.
  
  
•  Integrieren Sie realistische Reaktionszeittests und Feedback in frühe Lösungsversionen und Vorschauen. Wenn Leistungstests bis zum Ende der Lösungsentwicklung aufgeschoben werden, kann dies manchmal dazu führen, dass Teams Leistungsprobleme nicht angehen können, ohne wesentliche Teile der Lösungsarchitektur „rückgängig“ zu machen. Die Behebung von Leistungsproblemen spät im Entwicklungszyklus kann teuer werden.
  
  
• Stellen Sie sicher, dass die Benutzeroberfläche Elemente wie Spinner und Statusleisten enthält, damit der Benutzer weiß, dass die Anwendung aktiv ist und funktioniert. Dadurch wird unnötige Frustration über die als langsam empfundene Leistung des Produkts vermieden.
  
  
• Wenn notwendig, führen Sie Recherchen zu ähnlichen und „gut abschneidenden“ Lösungen durch, analysieren Sie Branchentrends und Publikationen und befragen Sie Experten, um angemessene Reaktionszeit- und Kapazitätsziele zu entwickeln.

Überwachen und kommunizieren Sie Leistungsgrenzen an Kunden.

Missbrauch oder Fehlkonfiguration einer Produkt- oder Lösungskomponente kann eine Ursache für schlechte Leistung und eine negative Benutzererfahrung sein. Um diese Situation zu vermeiden, sollten Architekten Folgendes tun:

• Seien Sie sich der Leistungsbeschränkungen innerhalb der Lösung bewusst und kommunizieren Sie diese proaktiv an die Benutzer. Wenn eine Lösung beispielsweise einen langsamen Kommunikationskanal mit geringer Bandbreite nutzt, sollte der Architekt die Endbenutzer darauf hinweisen, dass das Herunterladen hochauflösender Bilder beeinträchtigt wird.

• Ermöglichen Sie es Systemen, zu erkennen und mitzuteilen, wenn Anfragen außerhalb der Designparameter der Lösung liegen, sofern dies möglich ist. Zum Beispiel sollte das System Benutzer aktiv warnen, wenn sie versuchen, große Dateien über einen langsamen Kanal herunterzuladen.

Ein gängiger Ansatz bei Leistungstests besteht darin, zu prüfen, ob die Lösung ihre Reaktionszeitvorgaben bei der für die Lösung erwarteten maximalen Last erfüllt. Dabei wird angenommen, dass eine Lösung, die bei der maximal erwarteten Last gut funktioniert, auch für geringere Lasten gut geeignet ist. Die Herausforderung bei diesem Ansatz ist, dass er nur einen Datenpunkt pro getesteter Spitzenlast liefert, fast wie eine Pass/Fail-Übung.

Eine gut konzipierte Lösung wird mit dem explorativen Ansatz auf ihre Reaktionsfähigkeit bei einer Reihe von Lasten getestet, die sich in Größe, Benutzertypen und Kombination der getesteten Funktionen unterscheiden. Dadurch erhält das Lösungsteam wertvolle, vielschichtige Informationen darüber, wie die Lösungskomponenten interagieren und die Leistung beeinflussen, wo potenzielle Engpässe liegen und wie die Lösung skaliert werden kann, um kleinere oder größere Workloads zu bewältigen.

Mit diesem Ansatz können zusätzliche Tests vermieden werden, wenn sich die erwarteten Lastziele ändern und Metriken unter verschiedenen Lastbedingungen erfasst werden müssen. Inter/Extrapolation der bestehenden Leistungsabhängigkeiten von den Lastgrößen ermöglicht die Berechnung von Leistungsmetriken für jede Last innerhalb des Spektrums der ursprünglich getesteten Lasten (von null bis zu den Bruchpunktgrößen und höher).

Die typische Vorgehensweise bei Leistungstests folgt dem vereinfachten Muster „Messung der Reaktionszeiten bei vorgegebenen Lasten/Durchsätzen“. Dieser Ansatz beantwortet die Frage, ob die Reaktionszeit der Haupttransaktionen bei Spitzenwerten die bestehenden Service Level Agreements (SLA) erfüllt. Meist beschränken sich die getesteten Größen auf „niedrig“, „Spitze“ und „Belastung“. Dieser Ansatz kann die Frage nach den Reaktionszeiten bei typischen Belastungen beantworten, aber er vermittelt kein vollständiges Bild der Systemleistung in verschiedenen Situationen.

Der fortgeschrittenere Ansatz *Exploratory Performance Testing* zielt darauf ab, den *Performance Snapshot* der getesteten Lösung zu erstellen. Das Snapshot enthält einen umfassenden Satz von Leistungskennzahlen, die im breitesten unterstützten Lastspektrum gesammelt werden – von Einzelbenutzermessungen bis zu den Lasten nach dem Breakpoint (sofern möglich, außer wenn das System abstürzt). Dazu gehört eine Sammlung der Reaktionszeiten der Transaktionen, der Transaktions- und Datendurchsätze sowie der Ressourcenverbrauchsdaten, die unter steigenden Lastbedingungen erhoben werden. Unter „Transaktion“ verstehen wir eine endliche Arbeitseinheit des Systems – von Makrotransaktionen wie Login oder Kontoaktualisierung bis hin zu einzelnen Untertransaktionen (wie dem Authentifizierungsaufruf innerhalb der Login-Transaktion) oder einfachen HTTP-Anfragen.

Der umfassende Datensatz mit Leistungsdaten, der Leistungssnapshot, enthält die oben genannten Leistungsmetriken für den Bereich niedriger Last, den sogenannten „linearen“ Lastbereich (in dem die einzelnen verarbeiteten Threads die Anwesenheit der anderen nicht spüren und die Antwortzeiten mit zunehmender Last nicht ansteigen), den Bereich, in dem die Antwortzeiten mit zunehmender Last ansteigen, die Sättigungspunkte, an denen der Durchsatz mit zunehmender Last nicht mehr steigt und ein Sättigungsniveau erreicht, und den Bereich nach dem Erreichen des Breakpoints, in dem die Leistung abnimmt, nachdem der Durchsatz das Maximum erreicht hat und die Antwortzeiten die SLA-Werte überschreiten.

Die Abdeckung des gesamten Lastbereichs erfordert von den Testteams in der Regel nicht mehr Aufwand als die bloßen Tests in den Größenordnungen „Spitzen“ und „Belastung“ und die Dauertests, da dieselben Testskripte verwendet werden (der Hauptaufwand besteht in der Regel darin, diese Skripte zu erstellen). Die Erstellung eines solchen Leistungssnapshots hat jedoch folgende Vorteile:

• Sie müssen nicht Zeit und Mühe darauf verwenden, die richtige Testkonfiguration zu erraten, die den „richtigen“ Transaktionsdurchsatz („Spitzenwert“ oder „Stresswert“) erzeugt. Sie erhöhen einfach Ihre Last und decken *alle* unterstützten Lastgrößen und Durchsätze ab.

• Man kann feststellen, bei welchen Lasten die Reaktionszeiten anfangen anzusteigen, wo sie die SLA-Vorgaben überschreiten und wo der Durchsatz ein Maximum erreicht.

• So können Sie die Kapazität des Systems direkt messen, z.B. die Höhe der Last, bei der die Breakpoint-Bedingung erreicht wird (die Antwortzeit übersteigt das SLA, oder der Durchsatz erreicht das Maximum, oder die Auslastung der Systemressourcen gerät in den festgelegten „roten Bereich“, die CPU-Auslastung erreicht zum Beispiel 90 %, oder das System stürzt ab - was auch immer zuerst passiert). Das bedeutet, dass die üblicherweise auf Schätzungen basierenden Ansätze zur Kapazitätsanalyse und -planung nicht mehr erforderlich sind.

• Sollten sich die erwarteten Bedingungen des Produktionsbetriebs ändern (beispielsweise wenn die erwarteten durchschnittlichen und Spitzenlasten vom Unternehmen neu definiert werden), ist es nicht nötig, die Leistungstests erneut durchzuführen: Die gesuchten Metriken für die verschiedenen Lastgrößen können einfach durch Interpolation oder Extrapolation der bestehenden Ergebnisse ermittelt werden.

• Die Berücksichtigung des gesamten Lastspektrums anstelle weniger vordefinierter Größen ermöglicht es uns, einen umfassenden Überblick über die Systemleistung zu erhalten und keine möglichen Leistungsprobleme zu übersehen, indem wir das Produkt unter extremen Bedingungen testen.

• Wenn wir sicherstellen, dass die Tests das Erreichen der Leistungsgrenzen des Systems umfassen, wissen wir, wo die Leistungsengpässe liegen und welche Verbindung, Komponente oder Schicht zuerst ausfällt, wenn die Lasten steigen. So können Sie den Architektur- und Designteams ein nützliches und evidenzbasiertes Feedback geben, um die Robustheit und Leistung des Produkts zu verbessern.

Es gibt verschiedene Arten von Performance-Tests, die auf einer Lösung durchgeführt werden können. Eine gut konzipierte Lösung nutzt sie alle.

• Manuelles Benchmarking ist das, was sein Name schon verrät: Die manuelle Ausführung von Lösungsfunktionen, um aus erster Hand ein Gefühl dafür zu bekommen, wie die Lösung auf einen Benutzer reagiert.
• Kalibrierungstests sind Tests, die durchgeführt werden, um die Ergebnisse automatisierter Testtools mit anderen Quellen wie manuellen Tests oder integrierten Leistungsmetriken zu vergleichen, um die Korrektheit der Testskripte und der Ergebnisse des Testtools zu validieren.
• Bei einem Soak-Test oder Dauertest wird die Lösung über einen längeren Zeitraum unter Last getestet, um sicherzustellen, dass sie unter Last stabil ist und sich mit der Zeit nicht verschlechtert, zuverlässig betrieben werden kann und den erwarteten Ressourcenverbrauch einhält (d. h. keine Speicherlecks).
• Bei Spitzentests wird die Lösung unter der erwarteten Spitzenlast getestet, beispielsweise am geschäftigsten Tag des Jahres, um die Stabilität der Lösung zu gewährleisten und wichtige Kennzahlen wie Reaktionszeit und Ressourcenverbrauch unter der erwarteten Maximallast zu erfassen.
• Spannungs- und Spitzentests werden verwendet, um die Lösung auf einer vielfachen (zum Beispiel doppelten oder dreifachen) erwarteten Spitzenlast über einen kurzen Zeitraum (ein Belastungstest) oder sogar höhere Lasten für eine sehr kurze Zeit (Spitzentests) zu testen. Diese helfen dabei, Engpässe innerhalb der Lösung zu identifizieren und dem Lösungsteam zu ermöglichen, die Skalierungsabhängigkeiten der Lösung zu ermitteln.
• Variable Lasttests oder Breakpoint-Tests werden verwendet, um die Lösung unter verschiedenen Lasten zu testen, die Leistung der Lösung bei unterschiedlichen Lastgrößen zu verstehen und dem Lösungsteam zu helfen, Trends und Ressourcengrenzen innerhalb der Lösung zu erkennen. Diese Tests ermöglichen es auch, die Breakpoints des Produkts zu registrieren, die Lösungskapazität zu messen und die schwächsten Komponenten des Produkts (die am wahrscheinlichsten versagen) zu erkennen.

Ziel ist es, das Beste aus der Vielfalt der in den Tests erfassten Leistungsdaten herauszuholen:

• Wenden Sie kreative, explorative Methoden zur Analyse der Testergebnisse an. Nutzen Sie *Was-wäre-wenn*-Ansätze, um weitere Szenarien zu erkunden.
• Übertragen Sie die Ergebnisse auf Umgebungen unterschiedlicher Größe und Architektur, um die Leistung der Lösung in verschiedenen Plattformen und Bereitstellungen vorherzusagen.
• Ermitteln Sie alle Unstimmigkeiten der erhaltenen Leistungsdaten, indem Sie unerwartete Muster und Trends erkennen (z. B. führt eine *erhöhte* Auslastung zu *verringerten* Transaktionsraten).
• Verwenden Sie Modellierungstechniken, um die gemessene Systemkapazität mit der entsprechenden Größe der Benutzerbasis zu verknüpfen – basierend auf den angenommenen Nutzungsmustern.
• Denken Sie immer daran, die gegenseitige Leistungsauswirkung verschiedener Workflows zu bewerten, die gleichzeitig in der Produktion ausgeführt werden können.
• Nutzen Sie verschiedene Quellen von Leistungsdaten: von Pilotprojekten über Unit- und Funktionstests bis hin zu DevOps und SRE Goldsignalen. Bei der Leistungsanalyse haben alle Daten einen Wert.
• Teilen Sie die Ergebnisse der Analyse häufiger mit den Stakeholdern. Es hilft oft, nützliches Input von anderen zu erhalten, verbessert das Bewusstsein über den Fortschritt der Performance-Tests und -Analyse, hilft anderen, einen so technischen Bereich wie Performance- und Kapazitätsanalyse besser zu verstehen, und verbessert die Sichtbarkeit der gesamten nicht-funktionalen Validierungsbestrebungen.