Bei modernen Performanztests geht es darum zu verstehen, wie sich ein System verhält und was es kostet, um es zu betreiben, und nicht nur darum, ob es eine hohe Last bewältigen kann. Kontinuierliche Releases erfordern Beobachtbarkeit und Überwachung statt wiederholter Lasttests in jedem Sprint. Lasttests sind nach wie vor wichtig für außergewöhnliche Ereignisse wie plötzliche Lastspitzen, aber die tägliche Basislinie wird durch Instrumente, Dashboards und Echtzeit-Telemetrie festgelegt.
Das Wichtigste in Kürze
- Es macht keinen Sinn, in jedem Sprint einen Lasttest durchzuführen: Kontinuierliche Releases mit kleinen Änderungen erfordern Beobachtbarkeit und Überwachung, nicht wiederholte Kapazitätstests, die für Spitzenereignisse konzipiert sind.
- Performanztests und Lasttests sind nicht dasselbe; sie als identisch zu betrachten, ist eine Gewohnheit, die von Wasserfallprojekten und Bare-Metal-Servern übrig geblieben ist und für moderne Cloud-Systeme nicht mehr gilt.
- Eine elastische Cloud-Infrastruktur beseitigt die harte Kapazitätsgrenze, schafft aber ein Kostenproblem: Ein System, das automatisch skaliert, ohne angepasst zu werden, kann weit mehr als nötig kosten und trotzdem eine schlechte Leistung erbringen.
- KI-Systeme sind mit Leistungskosten verbunden, die jetzt noch leicht zu unterschätzen sind, weil die Tokenpreise niedrig sind, aber schlecht konzipierte KI-Integrationen mit großen Kontextfenstern werden teuer, wenn sich die Preise normalisieren.
- Beobachtbarkeit, d. h. Agenten, Telemetrie und ein für Menschen lesbares Dashboard, ist der Ausgangspunkt für die Arbeit an jedem Projekt, nicht die Wahl eines Performanztest-Tools.
Performanztests sind keine Lasttests
Die häufigste Verwirrung in der Praxis besteht darin, dass Performanztests und Lasttests als ein und dasselbe angesehen werden. Das ist nicht der Fall. Beim Lasttest geht es um die Frage, ob ein System eine große Anzahl von Benutzern auf einmal bewältigen kann. Beim Performanztest geht es um die Frage, wie sich ein System unter realen Bedingungen verhält, reagiert und Ressourcen verbraucht.
Jahrelang wurden die beiden Begriffe synonym verwendet. Wenn jemand von Leistung sprach, meinte er einen Lasttest. Das war sinnvoll in einer Zeit, in der es noch Wasserfälle und physische Server gab, in der eine neue Version alle sechs Monate oder einmal im Jahr veröffentlicht wurde und man genau eine Box hatte, die jeden Datenverkehr aushalten musste.
Leandro Melendez, der seit 2007 im Bereich Performanztest arbeitet, zieht hier eine klare Grenze: Lasttest ist ein Szenario, nicht die ganze Disziplin. Wenn du beides trennst, ändert sich die Art und Weise, wie du planst, was du misst und wie oft du testest.
Wie Performanztests früher funktionierten
Früher bedeuteten Performanztests viel Skripting und eine Menge Detektivarbeit. Tools wie LoadRunner dominierten. Tester zeichneten den Datenverkehr von Browsern auf, analysierten Anfragen und suchten nach Token, Sitzungs-IDs und Korrelationen, um Skripte korrekt wiederzugeben.
Die Arbeit war mühsam. Den richtigen Wert in einem Meer von Anfragen zu finden, war wie die Suche nach einer Nadel im Heuhaufen. Leandro nennt die Anhänglichkeit an diese Plackerei eine Art Stockholm-Syndrom: Der Wahnsinn war echt, und nach einer Weile hat es dir trotzdem gefallen.
Dieses Modell passte zu seiner Umgebung. Die Systeme waren versiegelt, nur ein Administrator hatte Zugang, und ein einziger Produktionsserver lief manchmal unter einem Schreibtisch, neben dem nur eine Person saß. Einmaliges, gründliches Testen vor einer seltenen Veröffentlichung war die vernünftige Wahl.
Warum die alten Praktiken in der Cloud nicht funktionieren
Die Bedingungen, die umfangreiche geskriptete Lasttests in jedem Zyklus rechtfertigten, sind verschwunden. Agile Delivery, Cloud-Infrastruktur, Kubernetes und ephemere Umgebungen, die auftauchen und wieder verschwinden, machen den alten Rhythmus untauglich.
Du kannst nicht Sprint für Sprint nach Korrelationen suchen. Bei monatlichen oder schnelleren Releases kann der langsame Skripting-Zyklus einfach nicht mithalten. Die Architektur hat sich außerdem in Richtung APIs und Dienste verlagert, was sauberere Wege zur Messung des Verhaltens eröffnet als die Aufzeichnung einer Browser-Sitzung.
In jedem Sprint einen massiven Lasttest von Cloud-Geräten gegen die Cloud-Infrastruktur durchzuführen, ist Verschwendung. Er verbrennt Geld für wenig neue Informationen, vor allem, wenn ein Minimum Viable Product bereits in Produktion ist und beobachtet wird.
Lasttests gehören nicht in die kontinuierliche Pipeline
Lasttests sind immer noch wichtig, aber sie gehören nicht in die kontinuierliche Pipeline. Viele Teams machen den Fehler, in jedem Sprint Kapazitätstests durchzuführen, als ob die Nachfragespitzen nach einem festen Zeitplan einträfen.
Das ist aber nicht der Fall. Der schwarze Freitag findet nicht in jedem Sprint statt, und Taylor Swift kommt nicht alle zwei Wochen zu deinem Projekt. Wenn du in jedem Sprint auf eine extreme Nachfragespitze testest, verschwendest du Zeit und Geld für ein Szenario, das nur selten eintritt.
Die Fehlerwirkung von Ticketmaster während des Vorverkaufs von Taylor Swift zeigt die andere Seite: Das Auslassen von Lasttests vor einem bekannten Anstieg verursacht einen echten, öffentlichen und schweren Schaden. Die Lektion lautet: Timing, nicht Verzicht. Wenn ein großes Ereignis bevorsteht, solltest du einen ernsthaften Lasttest durchführen, aber außerhalb der Pipeline, als bewusste einmalige Aktion.
Stell dir das wie bei einem Auto vor. Nachdem du einen Reifen gewechselt hast, überprüfst du, ob er funktioniert und sich richtig anfühlt. Du fährst nicht auf eine Rennstrecke, um die Höchstgeschwindigkeit des Autos erneut zu testen. Die meisten Veröffentlichungen sind Reifenwechsel, keine Rennen.
Warum elastische Skalierung ein Geldproblem schafft
Die Cloud-Elastizität hat ein Problem gelöst und ein anderes geschaffen. Hochskalieren bedeutet nicht mehr, Hardware zu kaufen. Du hebst eine Grenze an und das System wächst nach Bedarf. Hinter diesem Komfort verbirgt sich eine Kostenfalle.
Ein System kann schnell sein und jeden Nutzer aufnehmen, aber darunter schlecht eingestellt sein. Leandros Bild ist ein Treibstofftank mit einem Leck: Du kannst immer mehr Treibstoff pumpen, aber wenn der Motor nur einen Kilometer pro Liter zurücklegt, zahlst du das Zehnfache von dem, was du eigentlich zahlen solltest.
Eine moderne Leistungsfrage lautet also nicht nur “kann er die Last bewältigen”, sondern “was kostet die Bewältigung der Last”. Ein reaktionsschnelles System, das viel mehr Ressourcen verbraucht als nötig, ist eine Fehlerwirkung, die sich in der monatlichen Rechnung und nicht in der Reaktionszeit misst.
Hier spüren die Teams jetzt frühzeitig Druck. Wenn die Cloud-Rechnung ansteigt, fragt das Management nach dem Grund. Diese Frage zwingt dazu, schon in der Entwurfsphase über die Leistung nachzudenken, anstatt sie als Test am Ende zu belassen.
Neue Metriken für ephemere Infrastrukturen
Die Antwortzeit des Kunden ist nicht mehr die einzige Zahl, die zählt. In ephemeren Umgebungen kommen Messungen hinzu, die bei der traditionellen Performance-Arbeit nie berücksichtigt wurden.
Wie schnell wird ein neuer Pod oder eine neue Instanz hochgefahren, wenn Last ankommt? Wie schnell wird sie beendet, wenn sie nicht mehr benötigt wird? Beide Richtungen sind mit Abstrichen verbunden. Wenn du die Instanzen aggressiv herunterfährst, um Geld zu sparen, wird der erste Benutzer nach einer ruhigen Phase auf das sich drehende Rad treffen, während das System aufwacht. Wenn du die Instanzen warm hältst, um eine reibungslosere erste Erfahrung zu machen, steigen die Kosten.
Ein Auto, das im Leerlauf steht, verbrennt Benzin, ohne irgendwo hinzufahren. Eine ungenutzte Instanz, die am Leben bleibt, tut dasselbe. Den goldenen Mittelweg zwischen niedrigen Kosten und einer schnellen Reaktion auf plötzliche Last zu finden, ist eine echte neue Herausforderung und zwingt zu einer schwierigen Entscheidung: Nimmst du ein schlechtes Erlebnis für den einen Nutzer in Kauf, der als erster ankommt, damit alle nach ihm ein schnelles Erlebnis haben?
Leistung hat auch in KI-Systemen einen Kostenfaktor
Das gleiche Spannungsfeld zwischen Geld und Geschwindigkeit tritt auch bei KI-gestützten Systemen auf, und es verdient Aufmerksamkeit, bevor die Rechnungen kommen. Die Cloud war anfangs billig, um die Akzeptanz zu erhöhen, dann wurden die Preise reifer. Aus demselben Grund sind KI-Token und -Credits jetzt billig.
Leandro spricht von “performanter KI”, wobei die Kosten die Hauptsorge sind. Ein allgemeines, großes Sprachmodell kann schnell antworten und fühlt sich leistungsfähig an, aber wenn du bei jedem Anruf den gesamten Kontext sendest, steigt der Token-Verbrauch schnell und damit auch die Kosten.
Ein Modell, das auf deinem eigenen Code und deinen Ergebnissen trainiert wurde, kann diese Kosten senken, da es nicht jedes Mal den gesamten Kontext bestanden haben muss. Bevor du MCPs oder Agent-to-Agent-Setups verbindest, frage dich, welche Art von KI du verwendest und wie viel sie sendet. Diese können außer Kontrolle geraten, wenn niemand auf den Verbrauch achtet.
Beginne mit der Performance-Arbeit, bevor das Projekt beginnt
Der stärkste Schritt ist das, was Leandro die Minus-Eins-Aufgabe nennt: die Festlegung von Grundregeln, bevor irgendein Code läuft. Entscheide, was du überwachen wirst, ob die Entwickler das System instrumentieren, automatisierte Messungen erstellen oder beides, und ob die Plattform selbst nützliche Metriken meldet.
Die meisten Projekte sind bereits im Gange und haben diesen Schritt übersprungen. Die praktische Antwort ist dann dieselbe, nur später angewandt: Füge die Beobachtbarkeit jetzt hinzu. Du brauchst keine Automatisierung, um zu wissen, wie dein System funktioniert. Du brauchst Agenten, Instrumentierung und Telemetrie.
Ein nützlicher Test für die Bereitschaft ist das Dashboard eines Autos. Du würdest kein Auto kaufen, das kein Dashboard hat, auf dem Geschwindigkeit, Kraftstoffverbrauch und Reichweite angezeigt werden. Du solltest kein Projekt ohne ein Dashboard durchführen, das Leistungsmetriken in einer Form anzeigt, die das ganze Team versteht. Für Menschen lesbare Zahlen und Farben, keine rohen Sensorspannungen.
Hier ist die Prioritätenreihenfolge für ein Team, das mit der Arbeit an der Leistung beginnt:
| Schritt | Was zu tun ist | Warum es zuerst kommt |
|---|---|---|
| Beobachtbarkeit | Agenten und Telemetrie einrichten | Man kann nicht verbessern, was man nicht sehen kann |
| Sichtbarkeit | Metriken für das ganze Team lesbar machen | Leistung ist nicht nur Ops- und SRE-Arbeit |
| Automatisierung | Lasst die Entwickler Messungen vorher, währenddessen und danach durchführen | Billiger und schneller, sobald die Sichtbarkeit gegeben ist |
| Lasttests | Führt sie bei bekannten Lastspitzen durch, außerhalb der Pipeline | Es ist ein Ereignis, keine Sprintaufgabe |
Das absolute Minimum ist, dass du deine Leistung kennst, ohne etwas Besonderes zu tun. Wisse es einfach.
Es gibt kein einziges Leistungstool
Die häufigste Frage, die Leandro gestellt wird, ist die nach dem besten Tool zur Leistungsmessung. Die ehrliche Antwort ist, dass es kein solches Werkzeug gibt.
Decken Sie einen vollen Tisch und fragen Sie, welches einzelne Utensil Sie zum Essen verwenden sollten. Die Prämisse ist falsch. Für die Arbeit an der Leistung brauchst du mehrere Werkzeuge und Plattformen, die du für die jeweilige Aufgabe auswählst, und du solltest vermeiden, dich auf einen Typ festzulegen.
Die Anbieter propagieren den Lasttest als erstes, weil sie das verkaufen. Dieser Ansatz ist veraltet und beruht auf Praktiken von vor fünfzehn oder zwanzig Jahren. Betrachte die Auswahl der Tools als eine Portfolio-Entscheidung und räume den Lasttests den ihnen gebührenden Platz ein: wichtig, gelegentlich und getrennt vom kontinuierlichen Fluss.
