Performance-Budgets: Messung und Grenzen

Bietet Benchmarks, Lastmodelle, Instrumentierung, Schwellenwerte, Regressionsprüfungen und Anleitungen zur Behebung für Performance-Budgets. Es definiert Annahmegrenzen und beobachtbare Fehlerbelege, während umgebungsspezifische Grenzen konfigurierbar bleiben.

Paketstatus: Referenzkontext bereit für menschliche Überprüfung. Der Vertrag und die Testszenarien sind abgeschlossen, es wird jedoch nicht behauptet, dass eine übernehmende Implementierung diese bestanden hat.

Entscheidung

Für Performance-Budgets wird ein gemessenes Arbeitslastmodell und ein explizites Ressourcenbudget übernommen. Behandle den Block als Release- und Regressionsvertrag, der aus repräsentativen positiven, Grenz-, Verweigerungs-, Fehler- und Wiederherstellungsfällen aufgebaut ist. Dieses Paket ist ein Referenzvertrag: Das übernehmende Team muss numerische Grenzen, Anbieter, Rechtsgebiete und operative Verantwortliche anhand von Belegen in der eigenen Umgebung auswählen.

Umfang

• Die Performance-Budgets-Akteure, Eingaben, Ausgaben, Zustände, Richtlinien- oder Schema-Versionen und extern sichtbare Ergebnisse, die durch diesen Testblock beschrieben werden.
• Primäre und alternative Schnittstellen, Hintergrundarbeiten, Caches, Integrationen, Support-Pfade und Belege, die dieselbe Grenze beanspruchen können.
• Annahmespezifische Konfiguration, Rollout, Wiederherstellung und Verifikationsverantwortlichkeiten, die für eine sichere Anwendung der Referenz erforderlich sind.

Außerhalb dieses Blocks

• Die Wahl eines universellen Anbieters, Frameworks, Rechtsgebiets, numerischen Schwellenwerts, Aufbewahrungszeitraums oder Service-Level-Objectives für jeden Übernehmer.
• Die Behauptung, dass verpackte Szenarien gegen eine nachgelagerte Implementierung ausgeführt wurden oder dass diese Referenz eine rechtliche, Sicherheits- oder Barrierefreiheitszertifizierung gewährt.

Vertrag

• Zustandsrepräsentative Anforderungsform, Parallelität, Datenvolumen, Verteilung, Umgebung, Aufwärmphase und Messfenster mit jedem Ergebnis angeben.
• Verwende Perzentil-Latenz, Fehler, Durchsatz, Sättigung und Kosten zusammen; ein Durchschnitt allein kann keinen Kapazitätsanspruch autorisieren.
• Begrenze Warteschlangen, Batches, Parallelität, Speicher, Nutzlasten, Kardinalität und Wiederholungen, einschließlich Überlastzulassung und Degradationsverhalten.
• Vergleiche Regressionen mit einer versionierten Basislinie und erfordere Untersuchung oder eine explizite Budgetänderung vor dem Release.
• Zeichne Fixture-Version, Umgebung, Konfiguration, beobachtetes Ergebnis und Belegort für jeden entscheidungstragenden Lauf auf.
• Trenne Produktfehler, Abhängigkeitsfehler, Testinfrastrukturfehler und unklare Belege in Berichten.
• Verteile End-to-End-Budgets über Client, Edge, Service, Datenspeicher, Warteschlange und Drittanbieterarbeit mit einer expliziten nicht zugewiesenen Marge.
• Eine Komponente darf ihr Budget nur unter der deklarierten Arbeitslast ausgeben; Budgetänderungen erfordern gemessene Auswirkungen und Genehmigung durch den Verantwortlichen.

Implementierungsanleitung

• Erstelle den kleinsten deterministischen Fixture-Satz, der Risikoklassen abdeckt, und füge Produktionsfälle erst nach datenschutzsicherer Prüfung hinzu.
• Modelle Performance-Budgets Eingaben, Ausgaben, Akteure, Zustände, Invarianten, Nebeneffekte und Belege, bevor Framework- oder Anbieterdetails ausgewählt werden.
• Speichere die anwendbare Performance-Budgets-Vertrags- oder Richtlinienversion mit materiellem Zustand, damit Migrationen, Wiedergabe und Supportentscheidungen nachvollziehbar bleiben.
• Führe den Pfad hinter kontrolliertem Rollout ein, vergleiche erwartete und beobachtete Ergebnisse und halte eine getestete Wiederherstellungsroute, bis Annahmebelege vollständig sind.

Fehlerbehandlung und Schutzmaßnahmen

• Bei Sättigung wende deklarierte Rückstau- oder Ablehnungsmechanismen an, während die Identität der akzeptierten Arbeit und die Systemwiederherstellungskapazität erhalten bleiben.
• Ungültiger oder widersprüchlicher Performance-Budgets-Zustand wird abgelehnt oder isoliert; die Implementierung schätzt niemals einen Wert, der Autorität erweitert oder einen Effekt dupliziert.
• Wiederholungen sind begrenzt und verwenden dauerhafte Identität; nach Erschöpfung erreicht die Arbeit einen überprüfbaren Endzustand mit verantwortlichem Eigentümer.

Verifikation und Betrieb

• Führe die Suite zweimal aus einem sauberen Zustand aus und bestätige, dass Reihenfolge, Wiederholungen und parallele Ausführung das Urteil nicht verändern.
• Überwache Performance-Budgets-Erfolg, Verweigerung, Validierungsfehler, Abhängigkeitsfehler, Wiederholungsermüdung und Wiederherstellung nach Vertragsversion ohne sensible Nutzlastdimensionen.
• Führe gepaarte positive und negative Fixtures nach Richtlinien-, Schema-, Abhängigkeits-, Migrations- oder Grenzänderungen erneut aus und bewahre die resultierenden Belege auf.

Annahmen zur Übernahme

• Namen und Werte im Beispiel sind ein konkretes Fixture, keine universellen Standardwerte; Übernehmer ersetzen sie durch dokumentierte Belege und Verantwortlichkeit.
• Das übernehmende System kann authentifizierte Identität, dauerhafte Betriebs- oder Versionsaufzeichnungen, begrenzte Telemetrie und einen kontrollierten Änderungsweg bereitstellen.

Die ausführbar aussehenden Beispiele in diesem Paket sind Fixtures und Akzeptanzverträge. Führe den Collection Validator aus, um Struktur und Metadaten zu prüfen, übersetze und führe dann die Szenarien im Ziel-Repository aus, bevor Implementierungsbelege aufgezeichnet werden.