Eine Skalierungsnachweisakte verbindet eine konkrete Vergabeanforderung mit einem überprüfbaren Last- und Kapazitätsergebnis. Sie hält Nutzerabläufe, Lasttreiber, Datenprofil, zeitlichen Verlauf, Systemgrenze, getestete Fassung, Vergleichbarkeit der Umgebung, Abnahmekriterien, Messwerte, Engpass, sichere Betriebszone, Überlastverhalten, Skalierungsschritt, Wirksamkeitszeit, Monitoring, Ausbauauslöser, Zuständigkeit und Freigabe fest. Beobachtete, berechnete, prognostizierte, geplante und noch ungeklärte Aussagen bleiben getrennt. Die Akte liefert dem Angebot eine sachliche Grundlage, ohne interne Adressen, Schutzschwellen oder eine angreifbare technische Topologie zu veröffentlichen.
Der fiktive Landkreis Birkenhain beschafft ein digitales Bauantragsportal. In der Leistungsbeschreibung stehen 24.000 gleichzeitige Sitzungen, 180.000 Dokumentseiten pro Tag und kurzfristige Lastspitzen vor gesetzlichen Stichtagen. Ein Entwurf antwortet, die Lösung sei mandantenfähig, horizontal skalierbar und für beliebige Nutzerzahlen ausgelegt. Der beigefügte Test hat jedoch nur kleine PDF-Dateien hochgeladen, keine Planprüfung ausgelöst und nach zwölf Minuten geendet. Die Datenbank war fast leer. Angezeigt werden der Mittelwert der Antwortzeit und die erzeugten HTTP-Anfragen, nicht erfolgreich abgeschlossene Anträge. Niemand hat geprüft, wann weitere Kapazität tatsächlich nutzbar wird oder was bei Überlast mit bereits angenommenen Unterlagen geschieht.
Eine Skalierbarkeitsaussage beginnt mit dem Fachvorgang des Auftraggebers. Zerlegen Sie Sitzungen, Uploads und Tagesmengen in Ankunftsraten, gleichzeitige Arbeit, Dateigrößen, Prüfungen, Suchzugriffe, Hintergrundaufgaben und externe Dienste. Testen Sie die angebotene Produktfassung mit einem repräsentativen Datenbestand und einem zeitlich passenden Lastprofil. Messen Sie erfolgreiche Vorgänge, Laufzeitverteilung, Fehler, Warteschlangen, Datenrichtigkeit und Ressourcendruck gemeinsam. Die Angebotsaussage nennt anschließend die belegte Betriebszone, ihre Bedingungen, die beobachtete Grenze und einen genehmigten Weg für zusätzliche Nachfrage.
Vergabeanforderung
Lesen Sie Gleichzeitigkeit, Tagesmenge und Stichtag gemeinsam
Beginnen Sie mit der genauen Frage und suchen Sie alle zugehörigen Mengen in Leistungsbeschreibung, Falltypen, Schnittstellenanlage, Betriebszeiten, Migrationsdaten, Wertung, Vertragsentwurf und Bieterinformationen. Birkenhains 24.000 gleichzeitige Sitzungen sagen noch nicht, wie viele Personen gerade einen Antrag lesen, große Pläne hochladen oder eine Signatur auslösen. Die Tagesmenge von 180.000 Seiten kann gleichmäßig eintreffen oder in einem kurzen Stichtagsfenster. Beide Verteilungen benötigen andere Tests.
Schreiben Sie für jeden Fachvorgang einen beobachtbaren Beginn und Abschluss. Ein Bauantrag ist nicht fertig, sobald der Browser eine Upload-Annahme zeigt. Je nach angebotener Funktion können Virenprüfung, Formatkontrolle, Metadatenvalidierung, Speicherung, Indexierung, Kartenzuordnung und Benachrichtigung folgen. Entscheiden Sie, welcher Punkt für den Nutzer und die Vergabeanforderung zählt. Der technische Request ist nur eine Teilstrecke.
Fehlen Ankunftsraten, Dateiverteilung oder Verhaltensanteile, behandeln Sie diese Werte als offene Auftraggeberfakten oder genehmigte Bemessungsannahmen. Bilden Sie mindestens Normalbetrieb, typische Tageswelle, Stichtagsspitze und erwartetes Wachstum. Eine Annahme bekommt Quelle, Bandbreite, zuständige Person und spätesten Prüftermin. Sie darf nicht als gemessener Auftraggeberbedarf in die Antwort rutschen.
| Vorgang | Lasttreiber | Repräsentative Prüfung |
|---|---|---|
| Antragsentwurf öffnen | Gleichzeitige Sitzungen, Rollen und Bestandsumfang | Lesen und Berechtigungsprüfung bei gefülltem Datenbestand |
| Planunterlagen hochladen | Dateizahl, Größe, Format, Parallelität und Netzweg | Gemischte Dateien mit vollständiger Nachverarbeitung |
| Antrag prüfen und einreichen | Validierungen, Signatur und gleichzeitige Schreibzugriffe | Fachlicher Abschluss mit nachgelagerter Kontrolle |
| Behördenexport erzeugen | Stapelgröße, Stichtag und Konkurrenz zu Online-Arbeit | Export unter laufender Nutzerlast mit geprüftem Ergebnis |
Testnähe
Ein fast leeres System liefert keinen Nachweis für das fünfte Betriebsjahr
Halten Sie Produktstand, aktivierte Module, Mandantenkonfiguration, Datenmodell, Suchindex, Speicherkondition und angebundene Dienste fest. Vergleichen Sie die Testumgebung mit dem angebotenen Betrieb nach den Merkmalen, die das Ergebnis verändern können. Dazu gehören Kapazitätsklasse, Region und Netzpfad, aber auch Datenalter, Rechteprüfung, Verschlüsselung, Protokollierung und Hintergrundarbeit. Beschreiben Sie Unterschiede sachlich, ohne einen internen Komponentenplan zu veröffentlichen.
Ein repräsentativer Datenbestand bildet Zahl und Verteilung von Verfahren, Beteiligten, Dokumenten, Versionen, Geodaten und Berechtigungen nach. Verwenden Sie dafür freigegebene synthetische oder ausreichend geschützte Daten. Die Prüfung braucht Eigenschaften und Beziehungen, keine echten Bauakten. Testen Sie übliche, große, unvollständige und zurückgewiesene Dokumente, weil Fehlpfade ebenfalls Ressourcen verbrauchen und Warteschlangen erzeugen.
Prüfen Sie den Lastgenerator unabhängig. Er muss geplante Raten, Verbindungen und Dateiübertragungen liefern können, ohne selbst CPU, Netzwerk oder Socket-Grenzen zu erreichen. Vergleichen Sie clientseitige Laufzeiten, serverseitige Beobachtungen und fachliche Abschlusszahlen. Ein Unterschied kann auf Netz, Zeitmessung oder unvollständige Abschlussdefinition hinweisen. Erst die geklärte Messkette darf in den Nachweis.
| Dimension | Festgehaltener Stand | Behandlung |
|---|---|---|
| Produkt und Funktionen | Getestete Freigabe mit bezeichneten Fachpfaden | Abweichende Funktionen werden nicht mitbeansprucht |
| Datenvolumen und Beziehungen | Synthetischer Bestand nach dem prognostizierten Betriebsjahr | Verteilung und Erzeugungsrezept bleiben im Testnachweis |
| Externe Dienste | Getestete Identitäts-, Karten- und Signaturwege oder definierte Ersatzmodelle | Nicht echte Abhängigkeiten werden als Einschränkung genannt |
| Betriebsdetails | Prüfbare Umgebungsklasse und Vergleichsmerkmale | Adressen, Zugangsdaten und Schutzschwellen bleiben intern |
Messgrößen
Eine schnelle Annahme ist noch kein gespeicherter Bauantrag
Bestimmen Sie für jeden Vorgang, wann er fachlich vollständig und nachprüfbar ist. Ein Upload zählt erst dann als erfolgreich, wenn die vereinbarte Verarbeitung beendet und das Ergebnis wieder auffindbar ist. Trennen Sie angenommene, verarbeitete, abgelehnte, abgebrochene, wiederholte und doppelte Arbeit. Wiederholungen erhöhen die Verkehrszahl und können bei Überlast zusätzlich Druck erzeugen. Sie erhöhen nicht automatisch den nützlichen Durchsatz.
Erfassen Sie die Laufzeit als Verteilung. Median, p95 und p99 können je nach Auftraggeberziel unterschiedliche Teile des Nutzererlebnisses zeigen. Veröffentlichen Sie keine Perzentile ohne Grundgesamtheit, Fehlerbehandlung und Messpunkt. Wenn gescheiterte Vorgänge aus der Dauerstatistik verschwinden, kann die Kurve trotz schlechterem Dienst schneller wirken. Führen Sie Laufzeit, Erfolgsquote, fachliche Richtigkeit und Fehlerarten deshalb pro Laststufe zusammen.
Warteschlangen benötigen Anzahl und Alter. Ein Bestand von tausend Aufgaben kann stabil erscheinen, während die älteste Aufgabe immer länger wartet. Messen Sie Zufluss, Abfluss, ältestes Element und Zeit bis zur vollständigen Abarbeitung nach der Spitze. Ergänzen Sie knappe Ressourcen in einer freigabefähigen Kategorie wie Rechenarbeit, Arbeitsspeicher, Verbindung, Speicher, Fremdquote oder serialisierte Verarbeitung. So bleibt die Diagnose nützlich, ohne interne Angriffsflächen zu beschreiben.
Versuchsplan
Die Lastform entscheidet, welchen Fehler der Test sichtbar macht
Planen Sie mehrere Versuchsarten nach dem Beschaffungsrisiko. Eine Stufenlast zeigt, wie sich Durchsatz und Laufzeit mit wachsendem Bedarf verändern. Ein Sprung prüft die Reaktion auf einen Stichtagsbeginn. Eine längere Belastung kann schleichende Speicher-, Verbindungs- oder Rückstandsprobleme zeigen. Kontrollierte Überlast legt offen, ob das System schützt, priorisiert, abweist oder unkontrolliert ausfällt. Die Erholungsphase prüft, was mit bereits angenommener Arbeit geschieht.
Legen Sie vor dem Start Zielwerte, Beobachtungsdauer, Wiederholungen, Abbruchgrenzen und Sicherheitsverantwortung fest. Ein Lasttest darf weder einen produktiven Dienst noch Fremdsysteme ohne Zustimmung gefährden. Produktionsnahe Umgebungen sind nützlich, wenn ihr Einsatz genehmigt und isoliert ist. Tests in Produktion benötigen eine eigene Risiko-, Datenschutz- und Betriebsfreigabe; eine Ausschreibung schafft diese Befugnis nicht.
Die ISO/IEC/IEEE-29119-Reihe beschreibt allgemeine Testbegriffe und Prozesse, nicht den passenden Lastwert für Birkenhain. ISO/IEC 25010 ordnet Leistungsfähigkeit in ein Produktqualitätsmodell ein, und ISO/IEC 25023 stellt Qualitätsmessungen bereit, ohne allgemeine Bestehenswerte vorzugeben. Verwenden Sie solche Quellen für eine saubere Methode. Die konkrete Akzeptanzschwelle kommt aus der Vergabeanforderung und der genehmigten Angebotsposition.
Betriebsgrenze
Suchen Sie den Knick in der Kurve und prüfen Sie die Zeit danach
Tragen Sie je Stufe angebotene Last, fachliche Abschlüsse, Perzentile, Fehler, Warteschlangenalter und Ressourcendruck auf einer gemeinsamen Zeitachse zusammen. Der erste Warnpunkt kann auftreten, bevor Fehler steigen: zusätzlicher Bedarf bringt kaum mehr erfolgreiche Abschlüsse, das Ende der Laufzeitverteilung wächst oder Hintergrundarbeit sammelt sich. Nennen Sie die beobachtete Ursache nur so genau, wie Messung und Freigabe sie tragen.
Die sichere Angebotszone liegt unter der beobachteten Instabilität. Ihre Reserve berücksichtigt Schwankungen, ungeplante Wartung, veränderte Daten, ungleiche Verteilung, Skalierungsverzug und Fremddienste. Es gibt dafür keinen allgemein richtigen Prozentsatz. Halten Sie Annahmen und zuständige Entscheidung fest. Wenn der Versuch ohne Knick endet, ist sein höchster Punkt eine belegte Untergrenze der Fähigkeit und kein gemessenes Maximum.
Führen Sie den Versuch kontrolliert über die vorgesehene Zone hinaus. Prüfen Sie, ob neue Arbeit geordnet abgewiesen oder angenommen wird, ob wichtige Vorgänge Vorrang erhalten dürfen, ob Daten vollständig bleiben und ob Rückstände nach Lastabfall abgebaut werden. Google SRE empfiehlt, Kapazitätsgrenzen und Überlastverhalten zu testen, weil Wiederholungen und Ressourcenerschöpfung Fehler verstärken können. Der Angebotsnachweis muss dennoch das Verhalten der eigenen angebotenen Lösung belegen.
| Phase | Beobachtung | Aussagegrenze |
|---|---|---|
| Normale Tageswelle | Abschlüsse folgen der Ankunft; Laufzeit und Rückstand bleiben stabil | Normalbetrieb unter der getesteten Vorgangsmischung belegt |
| Stichtagsspitze | Zusätzliche Kapazität wird nach gemessener Verzögerung wirksam | Skalierungsreaktion unter diesen Bedingungen beobachtet |
| Überlaststufe | Planprüfung sammelt Rückstand, während Statusabrufe stabil bleiben | Hintergrundverarbeitung ist der erste festgestellte Grenzpfad |
| Entlastung | Angenommene Aufgaben werden ohne Verlust oder Doppelverarbeitung beendet | Erholung für den getesteten Verlauf nachgewiesen |
Kapazitätsänderung
Mehr Kapazität hilft erst, wenn sie Fachvorgänge übernimmt
Dokumentieren Sie den vollständigen Skalierungsablauf: Messsignal, Auswertefenster, Entscheidung, Anforderung zusätzlicher Kapazität, Bereitstellung, Bereitschaft, Verkehrs- oder Arbeitsübernahme und messbare Wirkung. Ein gestarteter Prozess ist noch keine wirksame Kapazität, wenn er Daten lädt, Partitionen übernimmt oder keine Aufträge erhält. Erfassen Sie die Zeit bis zur Entlastung. Prüfen Sie auch das Zurückfahren, damit offene Aufgaben nicht unterbrochen werden.
Zusätzliche parallele Verarbeitung kann auf feste Grenzen treffen. Gemeinsame Datenspeicher, geordnete Warteschlangen, Suchindizes, Lizenzkontingente, regionale Quoten und externe Schnittstellen wachsen nicht zwingend im selben Verhältnis. Der Azure Architecture Center beschreibt Skalierbarkeit als Verhältnis zwischen Durchsatzgewinn und Ressourcenzuwachs und weist auf Synchronisationspunkte hin. Das ist ein brauchbarer begrenzter Maßstab, aber keine Zusage linearer Skalierung für jede Anwendung.
Erfassen Sie für Bedarf oberhalb der belegten Zone einen Ausbaupfad. Dazu können eine geänderte Konfiguration, frühere Vorhaltung, eine Quotenanhebung, Datenaufteilung, zusätzliche Region oder Entwicklungsarbeit gehören. Jeder Schritt braucht Auslöser, Vorlauf, Kostenbehandlung, Lieferabhängigkeit, Abnahmetest und Entscheidungseigentümer. Eine geplante Produktänderung bleibt außerhalb der aktuellen Aussage, bis Entwicklung und Test sie belegen.
Nachweisführung
Ein Diagramm ohne Versuchsakte ist nicht wiederholbar
Speichern Sie Testplan, Lastmodell, Datenerzeugung, Produktfassung, Umgebungsbeschreibung, Beginn und Ende, Generatorprotokolle, Messreihen, Rechenregeln, Abweichungen und Vorfälle. Halten Sie Wiederholungen und Streuung fest. IETF RFC 8239 gilt für Rechenzentrums-Netzwerkbenchmarks, fordert dort aber ausdrücklich wiederholte Ergebnisse und eine berichtete Methodik. Diese Idee lässt sich als begrenztes Vorbild nutzen; seine netzspezifischen Messgrenzen werden nicht auf ein Bauportal übertragen.
Jede Zahl im Angebot verweist auf einen eingefrorenen Ergebnissatz. Eine prüfende Person muss die Zahl einschließlich der Fehlerpopulation nachvollziehen können. Entfernte Intervalle, Testfehler und manuelle Korrekturen bleiben sichtbar. Wird eine Stufe durch den Lastgenerator verfälscht, wiederholen Sie sie oder begrenzen Sie die Aussage. Der beste Einzelversuch darf nicht ohne vorab festgelegte Auswahlregel die normale Fähigkeit repräsentieren.
Öffnen Sie die Akte nach relevanten Änderungen erneut. Dazu zählen Produktfreigabe, Datenmodell, Datei- oder Fallmix, Umgebungsklasse, Region, Fremddienst, Quote, Skalierungsregel und Beobachtungslücke. Eine neue Auftraggeberzahl oder ein anderer Stichtagsverlauf löst ebenfalls eine Prüfung aus. Ein älterer Test kann weiter passen, wenn diese Beziehung ausdrücklich bestätigt wird. Der gleiche Produktname reicht dafür nicht.
Angebotstext
Nennen Sie belegte Zone, Bedingungen und Ausbauweg
Beantworten Sie zuerst, ob und in welchem Umfang die angebotene Lösung das Mengengerüst trägt. Nennen Sie die Fachvorgänge, Testfassung, Daten- und Umgebungsnähe, Zeitprofil, erfolgreiche Abschlussmessung und belegte Zone. Erklären Sie die Skalierungsreaktion und das Verhalten oberhalb dieser Zone. Wesentliche Annahmen, Fremdgrenzen und spätere Nachweise gehören an die in den Vergabeunterlagen vorgesehene Stelle.
Für Birkenhain kann eine freigegebene Antwort etwa auf den getesteten Mix aus Lesen, Planupload, Validierung und Behördenexport verweisen, die betrachtete Datenpopulation benennen und Durchsatz, ausgewählte Laufzeitperzentile, Fehlergrenze, Skalierungszeit und Erholung berichten. Ein noch nicht direkt geprüfter Teil der 24.000 Sitzungen wird als Kapazitätsmodell mit geplantem Validierungspunkt bezeichnet. Die Formulierung verspricht weder beliebige Last noch einen Ausbau ohne Vorlauf.
Gleichen Sie den Text mit Service Levels, Preis, Betrieb, Support und Sicherheitsfreigabe ab. Der Test belegt Verhalten unter Bedingungen, schafft aber allein keine Vertragszusage. Performance- und Produktverantwortliche bestätigen Methode und Ergebnis. Betrieb genehmigt Reserve und Überlastweg. Informationssicherheit entscheidet über die offengelegte Tiefe. Finanzen und Vertrieb prüfen Kosten. Eine entsprechend bevollmächtigte Person gibt den genauen Angebotssatz frei.
| Inhalt | Fachliche Zuständigkeit | Freigabebedingung |
|---|---|---|
| Lastmodell und Testergebnis | Performance-Test und Produkt | Quelle, Methode, Fassung, Abweichungen und Rohdaten sind verknüpft |
| Sichere Betriebszone | Betriebsverantwortung | Reserve, Monitoring, Überlast und Erholung sind tragbar |
| Ausbaupfad | Engineering, Lieferanten und Finanzen | Maßnahme, Vorlauf, Preis und Abnahmetest sind genehmigt |
| Wortlaut für den Auftraggeber | Angebotsfreigabe | Der genaue Satz bleibt innerhalb von Evidenz und Vertragsposition |
Woran gute Arbeit erkennbar ist
Konkrete Ergebnisse für Skalierbarkeitsfrage im RFP beantworten
- Jede Mengenangabe des Auftraggebers wird einer fachlichen Operation, einer Zeiteinheit, einem Datenprofil und einer Quelle zugeordnet.
- Gleichzeitige Sitzungen, Ankunftsrate, offene Verbindungen, Anfragen und abgeschlossene Vorgänge werden nicht miteinander verwechselt.
- Der Nachweis bezeichnet Produktfassung, Funktionsumfang, Umgebungsklasse, Datenzustand, Fremdsysteme, Testdauer und Wiederholungen.
- Erfolgreicher Durchsatz zählt nur vollständig abgeschlossene und überprüfte Fachvorgänge.
- Perzentile, Fehlerarten, Warteschlangenalter, Datenintegrität und knappe Ressourcen werden für jede Laststufe zusammen gelesen.
- Die sichere Betriebszone besitzt eine begründete Reserve unterhalb der ersten Instabilität.
- Der Skalierungspfad beschreibt Auslöser, Verzögerung, feste Grenzen, Zustandsübernahme, Fremdabhängigkeiten und Kostenwirkung.
- Überlast, Abweisung, Priorisierung und spätere Abarbeitung werden als Verhalten erklärt und getestet.
- Der freigegebene Text ist prüfbar, vertrags- und preisverträglich und schützt betriebliche Sicherheitsinformationen.
Betriebsmodell
So wird die Arbeit ausgeführt
- 01
Anforderung und Angebotsstand festhalten
Sichern Sie Wortlaut, Mengengerüst, Definitionen, Wertungszweck, Los, Leistungsstand, Vertragsbezug, Antwortstelle und aktuelle Fassungen.
- 02
Fachliche Lastobjekte bilden
Ordnen Sie Sitzungen, Antragsschritte, Uploads, Prüfungen, Suchen, Bescheide, Exporte und Fremdaufrufe nach Häufigkeit und Zeitverlauf.
- 03
Daten- und Umgebungsnähe bewerten
Vergleichen Sie Fassung, Funktionen, Datenvolumen, Berechtigungen, Netzwege, Speicherkondition, Partner und Skalierungsregeln mit dem Angebot.
- 04
Erfolg und Abbruch vorab definieren
Legen Sie Fachabschluss, Laufzeitperzentile, Fehler, Datenprüfung, Warteschlange, Ressourcengrenze und sichere Abbruchbedingungen fest.
- 05
Last stufenweise und zeitgerecht ausführen
Prüfen Sie Normalbetrieb, Stichtagsrampe, Spitzenhaltezeit, kurzen Sprung, längere Belastung, kontrollierte Überlast und Erholung.
- 06
Betriebszone und ersten Engpass bestimmen
Suchen Sie den Punkt, an dem zusätzlicher Bedarf weniger Abschluss, längere Enden der Verteilung oder wachsende Rückstände erzeugt.
- 07
Kapazitätsschritt praktisch prüfen
Messen Sie Auslöser, Bereitstellungs- und Aufwärmzeit, Verkehrsübernahme, Zustandsarbeit, Quoten, Kosten und Rückkehr zum Normalstand.
- 08
Aussage begrenzen und freigeben
Gleichen Sie Ergebnis, Service Level, Preis, Sicherheit und Ausbauplan ab und verwenden Sie nur den genehmigten Wortlaut.
Bewertung
Fragen, die den Entscheid verändern
- Welche fachliche Leistung muss unter der genannten Last vollständig beendet werden?
- Welcher Zeitraum und welcher Ankunftsverlauf liegen hinter Tagesmenge, Spitzenlast und Wachstum?
- Wie verteilen sich Lesen, Schreiben, Upload, Validierung, Suche, Karte, Benachrichtigung und Stapelverarbeitung?
- Welche Dateigrößen, Dokumentarten, Projektstrukturen, Berechtigungen und Bestandsdaten bestimmen die Arbeit?
- Welche Aufgaben laufen nach einer sichtbaren Bestätigung weiter?
- Welche Identitäts-, Karten-, Signatur-, Scan- oder Zahlungsdienste begrenzen den Gesamtvorgang?
- Entsprechen getestete Fassung, Region, Konfiguration und Umgebung der angebotenen Lösung?
- Was zählt als fachlich erfolgreicher Abschluss und was als Ablehnung, Wiederholung oder Duplikat?
- Welche Perzentile, Fehlerschwellen und Datenprüfungen markieren das Ende der akzeptablen Zone?
- Welches Signal zeigt den ersten Engpass, und wurde die Lastquelle selbst ausgeschlossen?
- Wie verhält sich der Dienst oberhalb der vorgesehenen Last und wie arbeitet er angenommene Vorgänge ab?
- Wer darf technische Evidenz, Ausbaukosten, Vertragsaussage und Offenlegung genehmigen?
Fehlermuster
Wo Teams die Kontrolle verlieren
Die Zahl aller Konten wird als Zahl gleichzeitig arbeitender Personen ausgegeben.
Ein schneller Lesezugriff verdeckt langsame Upload-, Prüf- und Schreibpfade.
Kleine gleichartige Dateien bilden Planarchive, Bildseiten und fehlerhafte Unterlagen nicht ab.
HTTP-Antworten werden gezählt, obwohl Hintergrundprüfung oder Speicherung später scheitert.
Der Mittelwert bleibt niedrig, während ein relevanter Anteil sehr lange wartet.
Fehlerhafte Vorgänge fehlen in der Laufzeitstatistik und lassen das Ergebnis besser erscheinen.
Eine kurze Messung endet vor wachsenden Warteschlangen, Speicherproblemen oder verzögerter Indexierung.
Die Skalierung reagiert erst nach Überschreiten des zugesagten Zielwerts.
Eine Lizenz, ein Fremddienst oder eine feste Datenkomponente begrenzt trotz zusätzlicher Rechenleistung.
Der Nachweis veröffentlicht interne Schwellen und Verbindungen, die für die Bewertung nicht nötig sind.
Eine neue Produktfassung übernimmt einen alten Test, obwohl sie Lastpfad oder Datenmodell verändert.
Messung
Das fertige Ergebnis messen
Gemessen wird der abgeschlossene Prozess inklusive Review-Aufwand und Ausnahmen. Reines Output-Volumen beweist noch keine bessere Arbeitsweise.
- Lastannahmen mit Quelle, Zeitraum, Einheit, Unsicherheit und Freigabedatum
- fachlich erfolgreiche Abschlüsse je Operation und Messintervall
- p50-, p95- und p99-Dauer für Antrag, Upload, Prüfung, Suche und Statusabruf
- technische Fehler, fachliche Ablehnungen, Abbrüche, Wiederholungen und Duplikate
- Anzahl und Alter offener Hintergrundaufgaben während Last und Erholung
- Datenvollständigkeit und Konsistenz nach Spitzen- und Überlastversuchen
- zusätzlicher nützlicher Durchsatz je Kapazitätsschritt
- Zeit vom Skalierungsauslöser bis zur messbaren Entlastung
- Angebotsaussagen mit aktueller Nachweisakte und zuständiger Freigabe
- Behauptungen unbegrenzter Skalierung im freigegebenen Angebot; Zielwert null
Fragen
Häufige Fragen
Sind 24.000 registrierte Nutzer dasselbe wie 24.000 gleichzeitige Nutzer?
Nein. Erfassen Sie aktive Sitzungen, Ankunftsraten, gleichzeitig laufende Operationen und fachliche Abschlüsse getrennt. Das Verhältnis ergibt sich aus dem tatsächlichen Verhalten.
Reicht ein Lasttest mit kleinen Testdateien?
Nur wenn kleine Dateien das angebotene Nutzungsspektrum belegen. Sonst benötigen Sie eine dokumentierte Größen-, Format- und Fehlerverteilung samt nachgelagerter Verarbeitung.
Warum genügt die mittlere Antwortzeit nicht?
Der Mittelwert kann langsame Enden und ausgefallene Vorgänge verdecken. Zeigen Sie geeignete Perzentile, Fehler, Grundgesamtheit und fachlichen Abschluss je Laststufe.
Muss die gesamte technische Architektur ins Angebot?
Prüfen Sie die Vergabeunterlagen und den genehmigten Offenlegungsweg. Beschreiben Sie Systemgrenze, Umgebungsnähe, Messmethode und Ausbauprinzip in der geforderten Tiefe. Konflikte mit Sicherheitsvorgaben benötigen eine Klärung oder einen geschützten Austausch vor der Freigabe.
Beweist automatische Skalierung unbegrenzte Kapazität?
Nein. Auslösung, Bereitstellung, Aufwärmen, Zustandsarbeit, Quoten, feste Komponenten, Fremddienste und Kosten begrenzen den Vorgang. Berichten Sie die getestete Wirkung.
Darf eine kleinere Testumgebung hochgerechnet werden?
Nur mit offengelegten Annahmen, nachgewiesenen Proportionalitäten, Behandlung fester Grenzen und einem genehmigten Validierungspunkt. Eine bloße Multiplikation ist kein Messwert.
Wann verliert ein Performance-Test seine Aussagekraft?
Prüfen Sie ihn nach Änderungen an Produkt, Daten, Lastmix, Umgebungsklasse, Abhängigkeiten, Quoten, Skalierungsregeln oder Messung erneut. Das Datum allein entscheidet nicht.
Ist der Kapazitätsnachweis bereits ein Service Level?
Nein. Er zeigt getestetes Verhalten. Ziel, Messregel, Ausnahmen, Rechtsfolge, Preis und Vertragsvollmacht benötigen eine gesonderte Freigabe.
Quellen
Primärquellen
- ISO/IEC 25010:2023 zum Produktqualitätsmodell Internationale Organisation für Normung
- ISO/IEC 25023:2016 zur Messung der System- und Softwareproduktqualität Internationale Organisation für Normung
- ISO/IEC 25030:2019 als Rahmen für Qualitätsanforderungen Internationale Organisation für Normung
- ISO/IEC 25040:2024 als Rahmen für Qualitätsbewertungen Internationale Organisation für Normung
- ISO/IEC/IEEE 29119-1:2022 zu Grundbegriffen des Softwaretestens Internationale Organisation für Normung
- ISO/IEC/IEEE 29119-2:2021 zu Software-Testprozessen Internationale Organisation für Normung
- ISO-Übersicht zur Normenreihe ISO/IEC/IEEE 29119 Internationale Organisation für Normung
- NIST SP 500-307 zur Beschreibung von Cloud-Service-Messgrößen National Institute of Standards and Technology
- Google-SRE-Empfehlungen zu Kapazitätsplanung und Überlast Google Site Reliability Engineering
- Google-SRE-Kapitel zu Kaskadenfehlern und Lastabweisung Google Site Reliability Engineering
- Google-SRE-Kapitel zu verlässlichen Produkteinführungen unter Last Google Site Reliability Engineering
- Azure Well-Architected-Leitfaden für Performance-Tests Microsoft Learn
- Azure Well-Architected-Leitfaden für Kapazitätsplanung Microsoft Learn
- Azure Well-Architected-Leitfaden für Performance-Ziele Microsoft Learn
- Azure Architecture Center zur horizontalen Skalierung Microsoft Learn
- OpenTelemetry-Konventionen für HTTP-Messgrößen OpenTelemetry
- IETF RFC 8239 zur Benchmark-Methodik für Rechenzentren Internet Engineering Task Force
- Britischer Procurement Act 2023, Section 23 zu Zuschlagskriterien UK Legislation
- Aktueller britischer Leitfaden zur Bewertung von Angeboten UK Cabinet Office
- Richtlinie 2014/24/EU über die öffentliche Auftragsvergabe Europäische Union
- § 31 VgV zur Leistungsbeschreibung Bundesministerium der Justiz und Bundesamt für Justiz
- Französischer Code de la commande publique, Artikel R2152-7 Légifrance
Über den Autor
Tony Kim
Tony schreibt über angewandte AI, verlässliches Product Engineering und Systeme, die komplexe Response-Arbeit kontrollierbar machen.
Ziva
Proposal-Software für quellenbasierte Antworten auf RFPs, RFIs, DDQs und Fragebögen.
Bid-Management, Proposal-Teams, Presales sowie Security- und Compliance-Verantwortliche. Ausgangspunkt sind der bestehende Ablauf, seine Grenzen und die vorhandenen Nachweise.