Wie man realistische Verkehrsmuster für Unternehmensanwendungen erstellt

Die meisten Enterprise-Lasttests beginnen mit einer Zahl, die jemand in einem Meeting ausgewählt hat. Fünftausend virtuelle Nutzer. Zehntausend. Der Test besteht, der Bericht wird abgelegt und die Anwendung stürzt dennoch am ersten Montag des Quartals ab.

Runde Zahlen sind leicht zu vereinbaren und sagen fast nichts aus. Echter Traffic kommt in Schüben an, verteilt sich ungleichmäßig über Funktionen und verändert seine Zusammensetzung genau in dem Moment, in dem das Volumen seinen Höhepunkt erreicht. Ein Test, der eine gleichmäßige Wand von identischen Anfragen sendet, durchläuft einen anderen Codepfad als die Produktion, mit Cache-Verhalten, Abfrageplänen und Sperrkonflikten, die keinerlei Verbindung zum Livesystem haben.

So bauen Sie ein Traffic-Modell aus Daten, die Sie bereits sammeln, und wie Sie es ausführen, damit die Ergebnisse aussagekräftig sind.

Inhaltsverzeichnis

1. Was macht Enterprise-Traffic schwer zu simulieren
2. Wo die Traffic-Daten bereits vorhanden sind
3. Wie man ein Traffic-Modell aus Produktivdaten erstellt
4. Wo Traffic-Modelle scheitern
5. Wie echte Enterprise-Traffic-Muster aussehen
6. Wie man das Modell in LoadView ausführt
7. Wie man das Modell mit der Produktion abgleicht
8. Das Fazit
9. Häufig gestellte Fragen

Was macht Enterprise-Traffic schwer zu simulieren

Drei Dinge bringen Teams zum Straucheln, die direkt von einer Personenzahl zu einem laufenden Test übergehen.

Gleichzeitigkeit und Ankunftsrate sind nicht dieselbe Zahl. Wenn ein Stakeholder sagt: „Wir müssen 5.000 Benutzer bewältigen“, fragen Sie, welche Zahl er meint. Fünftausend Personen, die simultan eingeloggt sind, sind ein völlig anderer Test als fünftausend Sitzungen, die jede Stunde starten. Verstehen Sie das großzügig falsch, verbringen Sie Wochen damit, für eine Last zu optimieren, die nie auftauchen wird. Verstehen Sie es falsch in die andere Richtung, sagt der Test Ihnen nichts. Gleichzeitige Benutzertests machen nur dann Sinn, wenn Sie wissen, auf welche der beiden Zahlen Sie abzielen. Dies ist die Trennung zwischen einem ankunftsratengetriebenen Modell, das widerspiegelt, wie Nutzer tatsächlich erscheinen, und einem gleichzeitigkeitgetriebenen Modell, das eine feste Population im System hält. Öffentlich zugänglicher Traffic ist fast immer das erste. Systeme mit einer begrenzten Benutzerbasis – Callcenter-Desktops, lizenzierte Arbeitsplätze, Agentenportale – verhalten sich tatsächlich wie das zweite.

Traffic hat eine Form, und die Form macht den Schaden. Verbindungs-Pools, Autoscaling-Gruppen und JIT-erwärmte Anwendungsserver reagieren auf die Änderungsrate, nicht nur auf die Obergrenze. Ein System, das 2.000 gleichzeitige Benutzer problemlos handhabt, kann auf dem Weg zu 2.000 scheitern, wenn es diese Zahl in neunzig Sekunden erreicht.

Die Transaktionsmischung verändert sich mit dem Volumen. Bei durchschnittlichem Volumen sieht eine E-Commerce-Seite meist Browsing. Während eines Blitzverkaufs nehmen Checkout- und Bestandsanfragen einen viel größeren Anteil der gleichen Anfragezahl ein. Die Gesamtzahl sieht auf einem Dashboard identisch aus. Die Datenbanklast nicht.

Eine konstante virtuelle Benutzerzahl und eine geformte Ankunftskurve können denselben durchschnittlichen Durchsatz erzeugen, während sie völlig unterschiedliche Teile des Stacks belasten.

Wo die Traffic-Daten bereits vorhanden sind

Sie benötigen keine neue Instrumentierung. Das meiste davon wird bereits irgendwo auf der Festplatte geschrieben. Die Arbeit besteht darin, diese Daten zu Sessions zusammenzufügen und Bot-Traffic herauszufiltern, bevor Sie etwas zählen.

Interne Enterprise-Anwendungen haben meist gar keine Analytics-Tags. Authentifizierungsprotokolle und Anwendungsserver-Protokolle überbrücken die Lücke – Login-Ereignisse geben Ihnen die Ankunftsrate, und die Zeit zwischen der ersten und letzten Anfrage pro Sitzung gibt Ihnen die Dauer.

Wie man ein Traffic-Modell aus Produktivdaten erstellt

Vier Ausgaben definieren das Modell: Ankunftsrate, Transaktionsmix, Denkzeitverteilung und geografische Aufteilung.

Schritt 1: Wählen Sie das exakte Zeitfenster, das Sie modellieren

Nicht „Spitzen-Traffic“. Eine bestimmte Stunde an einem bestimmten Datum, entnommen aus Ihren Protokollen. Nehmen Sie die Stunde mit dem höchsten Durchsatz der letzten zwölf Monate, dann wählen Sie ein zweites Fenster, das Ihr schwerstes Business-Event abdeckt – Monatsabschluss, offene Anmeldung, Black Friday, Quartalsberichte. Modellieren Sie beide. Sie haben fast nie dieselbe Form.

Schritt 2: Zählen Sie Sitzungen, nicht Anfragen

Anfragen pro Sekunde sind die einfachste Zahl zum Abrufen und die am wenigsten stabile. Veröffentlichen Sie ein Frontend-Release, das drei API-Aufrufe zu einem bündelt, reduziert sich Ihre Anfragezahl um ein Drittel, obwohl sich die Nachfrage nicht ändert. Sitzungen pro Stunde verfolgen, was Benutzer tatsächlich tun. Die Diskrepanz ist am größten bei Single-Page-Anwendungen, bei denen ein Klick sich auf ein Dutzend Hintergrund-API-Aufrufe ausweitet.

Ziehen Sie Sitzungen pro Stunde für Ihr Zeitfenster, plus den Mittelwert und das 90. Perzentil der Sitzungsdauer. Behalten Sie beide Zahlen – der Anteil der langen Sitzungen ist in Schritt drei wichtig.

Schritt 3: Sitzungen in Gleichzeitigkeit umwandeln

Little’s Law verbindet Ankunftsrate mit Gleichzeitigkeit:

Gleichzeitige Sitzungen = Sitzungen pro Stunde × (durchschnittliche Sitzungsdauer in Minuten ÷ 60)

18.000 Sitzungen/Stunde × (6 Minuten ÷ 60) = 1.800 gleichzeitige Sitzungen

Führen Sie 18.000 gleichzeitige virtuelle Benutzer gegen diese Anwendung aus, haben Sie etwas getestet, das zehnmal größer als Ihr tatsächlicher Spitzenwert ist. Sie werden einen Test nicht bestehen, den Sie ansonsten bestanden hätten, und anschließend eine Sprints lang einen Engpass jagen, den die Produktion niemals erreichen würde.

Little’s Law nutzt den Mittelwert, behandeln Sie P90 als separate Bemessungskontrolle und nicht als zweite Messung der Formel. Füttern Sie mit einem 22-minütigen P90 neben dem 6-minütigen Mittelwert, und Sie erhalten etwa 6.600 — die Gleichzeitigkeit, die Sie besitzen würden, wenn jede Sitzung so lange läuft wie Ihr langsamstes zehntel. Bewusst pessimistisch, und die Zahl, die für die Kapazitätsplanung von Bedeutung ist, wenn lange Sitzungen knappe Ressourcen halten wie Berichts-Threads oder Datenbankverbindungen.

Schritt 4: Teilen Sie den Traffic in Geschäftstransaktionen

Gruppieren Sie Endpunkte in Geschäftstransaktionen statt URLs: suchen, Detail anzeigen, zum Warenkorb hinzufügen, Anspruch einreichen, Bericht exportieren, Gehaltsabrechnung ausführen. Dann erfassen Sie zwei Mischungen – den Anteil jeder Transaktion am gesamten Traffic während des Zeitfensters und ihren Anteil in der verkehrsreichsten Minute.

Wenn sich diese beiden Mischungen bei einer Transaktion um mehr als wenige Prozentpunkte unterscheiden, bauen Sie beide in den Test ein und führen sie als separate Szenarien aus. Ein Test, der nur auf dem Stundenmix basiert, wird diejenige Transaktion, die am stärksten während der Spitze ansteigt, unterlasten.

Schritt 5: Ziehen Sie die Denkzeit aus echten Sitzungen

Raten Sie nicht bei der Denkzeit und verwenden Sie keine Konstante. Eine feste fünfsekündige Pause synchronisiert jeden virtuellen Benutzer zu einer Marschkolonne, die die Anwendung im Gleichschritt trifft und spitze Durchsatzspitzen erzeugt, die keine echte Population je erzeugt.

Ziehen Sie die Zeitspanne zwischen aufeinanderfolgenden Seitenladungen in echten Sitzungen aus RUM- oder APM-Daten und reproduzieren Sie sie als Verteilung. Enterprise-Nutzer sind oft bimodal: kurze Pausen beim Klicken durch einen ihnen bekannten Ablauf, lange Pausen beim Lesen eines Dokuments oder beim Telefonieren.

Schritt 6: Passen Sie die Anstiegskurve an die reale Kurve an

Tragen Sie die Sitzungsanzahl pro Minute über Ihr Zeitfenster auf und formen Sie die Testanlaufphase entsprechend. Drei Formen decken die meisten Enterprise-Anwendungen ab:

• Nahezu senkrecht. Produkteinführungen, Ticket-Verkaufsstarts und Börsenöffnungen. Die Spitzen-Gleichzeitigkeit erreicht das System in unter zwei Minuten.
• Treppenstufe. Interne Anwendungen, die sich um 9 Uhr in jeder Zeitzone einschalten, eine Stufe pro Region.
• Rechteckschwingung. Batch- und Integrationstrafic. Voll bei voller Auslastung an, voll bei voller Auslastung aus, kein Anstieg.

Schritt 7: Platzieren Sie die Last, wo Ihre Nutzer sind

Nehmen Sie die geografische Aufteilung aus Analytics oder CDN-Protokollen und erzeugen Sie Last aus genau diesen Regionen. Es geht hier nicht nur darum, die Latenz für entfernte Nutzer zu messen. Latenz wirkt sich auf die Gleichzeitigkeit aus: Eine Sitzung, die durch eine 280 ms Hin- und Rückreise offen gehalten wird, dauert länger als dieselbe Sitzung auf einer 20 ms Verbindung, sodass identische Ankunftsraten eine höhere Gleichzeitigkeit erzeugen. Tests aus nur einer Region verbergen das vollständig.

Wo Traffic-Modelle scheitern

Ein Datensatz für jeden virtuellen Benutzer. Gleicher Login, gleiche Produkt-ID, gleiche Kontonummer über zehntausend Nutzer hinweg und Ihre Cache-Trefferquote steigt auf nahezu 100%. Produktion verhält sich nicht so. Parametrisieren Sie mit einem Datenbestand, der realistische Kardinalitäten abbildet – ein Kontopool, eine SKU-Liste, eindeutige Bestell-IDs pro Testlauf – und vergleichen Sie vor Vertrauenswürdigkeit eines Ergebnisses die Cache-Trefferquote im Test mit der in Produktion.

Keine andere Last während des Spitzenwerts. Enterprise-Spitzenzeiten kollidieren mit geplanten Arbeiten: nächtliche ETL-Prozesse, Index-Rebuilds, Berichtserstellung, Backup-Zeiten, Nachholarbeiten bei Replikationen. Läuft der Abstimmungsjob um 2 Uhr morgens und Ihre Spitzenzeit für Batch-Integrationen ist ebenfalls um 2 Uhr, misst eine saubere Testumgebung ohne Hintergrundlast ein System, das Sie nicht betreiben.

Nur Protokolltests bei browserlastigen Anwendungen. Ein HTTP-Level-Test spielt die zur Aufnahmezeit erfassten Anfragen ab. Er wird kein JavaScript ausführen, keine Lazy-Loaded Calls feuern, keine Drittanbieter-Tags laden oder Renderings vornehmen. Für Single-Page-Anwendungen oder umfangreiche interne Portale lässt das den Großteil der tatsächlichen Arbeiten des Clients außer Acht – und alle Prozesse, die bestimmen, was der Nutzer sieht. Web-Anwendungslasttests in echten Browsern sind der einzige Weg, Client-seitige Rendering-Leistung unter Last zu messen.

Nur der Happy Path. Echter Traffic beinhaltet verwaiste Warenkörbe, Back-Button-Schleifen, fehlgeschlagene Logins, abgelaufene Tokens und ungeduldige Doppelklicks. Fehlgeschlagene Logins sind einen eigenen Szenario wert: Sie treffen den Identitätsanbieter, umgehen meist den Cache und lösen oft Sperrlogiken aus, die zusätzliche Schreibvorgänge erzeugen.

Wie echte Enterprise-Traffic-Muster aussehen

Drei immer wiederkehrende Muster und was jedes vom Modell verlangt.

Einzelhandels-Blitzverkauf oder Produkt-Release

Der Anstieg ist nahezu senkrecht und der Mix reduziert sich auf drei Transaktionen: Produktdetail, zum Warenkorb hinzufügen, Checkout. Wenn die Produktseite cachebar ist, verbessert sich die CDN-Hit-Rate sogar, weil alle dasselbe Top-Produkt anfragen, was einen naiven Test leicht aussehen lässt. Der Druck fällt auf die nicht cachebaren Aufrufe – Bestandsprüfungen, Warenkorbschreibungen, Zahlungsautorisierungen – alle gleichzeitig am Ursprung mit Zeilensperrkonflikten bei einer einzigen SKU. Modellieren Sie den Mix für die Minute der Spitze, nicht für die Stunde.

Monatsabschluss in einem internen ERP

Das Sitzungsaufkommen ist unauffällig. Die Sitzungsdauer nicht. Berichts-Exporte und Batch-Buchungen dauern mehrere Minuten, sodass die Gleichzeitigkeit steigt, auch wenn die Ankunftsrate flach erscheint – Little’s Law arbeitet gegen Sie. Außerdem liegt es auf dem Batch des Monatsabschlusses, sodass Hintergrundlast Teil des Tests ist. Teilen Sie die lang laufenden Berichts- und Buchungsnutzer in eine eigene Transaktionsklasse mit eigener Dauer, statt sie in einen einzigen Durchschnitt einzurechnen.

Versicherungs-Open-Enrollment

Wochen mit erhöhtem Traffic mit einem starken Peak in den letzten zwei Tagen. Sitzungen dauern lang, weil Menschen Planunterlagen lesen, und sie sind authentifizierungs- und downloadintensiv. Der mehrwöchige Teil ist Endurance Testing, bei dem Speicherlecks, Erschöpfung von Verbindungspools und Protokollvolumen wichtiger sind als die Spitzen-Gleichzeitigkeit. Der Spitzenpeak am Ende benötigt ein eigenes Modell.

Wie man das Modell in LoadView ausführt

Ist das Modell erstellt, folgt daran die Testkonfiguration. LoadView bietet drei Lastkurventypen, und Ihr Modell sagt Ihnen, welchen Sie wählen:

Zeichnen Sie den Sitzungsablauf mit dem EveryStep Web Recorder auf, sodass das Skript genau denselben Pfad abläuft wie ein Nutzer, in einem echten Browser, sowohl auf Desktop- als auch auf mobilen Browsern, wie Ihre Analytics zeigen. Stellen Sie die regionale Aufteilung über das geo-verteilte Lastinjektionsnetzwerk ein, um Schritt sieben Ihres Modells zu erfüllen.

Für Anwendungen, die nie das öffentliche Internet berühren, führen Inhouse-Injektoren Lasttests hinter Ihrer Firewall durch und melden an dieselbe Plattform – so wird der meiste interne ERP- und Portalttraffic überhaupt modelliert.

Wie man das Modell mit der Produktion abgleicht

Ein Traffic-Modell ist eine Hypothese, bis Sie seine Ergebnisse mit der Realität vergleichen. Erfassen Sie Backend-Daten während des Tests – Datenbank-Warteereignisse, Verbindungs-Pool-Sättigung, Warteschlangentiefe, Autoscaling-Aktivitäten, CDN-Ursprungsabrufrate, Identitätsanbieter-Drosselung. Diese Signale erklären die folgenden Zahlen.

Stellen Sie nach dem Lauf fünf Messwerte neben jene aus Produktion für dasselbe Zeitfenster:

1. Durchsatz pro Transaktion. Wenn der Testdurchsatz bei derselben Benutzerzahl deutlich unter der Produktion liegt, ist die Denkzeit zu lang oder das Skript fehlt Aufrufe.
2. Prozentuale Verteilung der Transaktionsmischung. Abweichungen hier bedeuten, dass die Verzweigungslogik des Skripts nicht mit dem Nutzerverhalten übereinstimmt.
3. Cache-Hit-Rate. Ein Test mit 95 % gegen Produktion mit 70 % bedeutet einen zu engen Datensatz.
4. Fehlerrate und -arten. Produktion weist fast immer eine Baseline-Fehlerrate auf. Ein Test mit null Fehlern überspringt meist etwas.
5. Durchschnittliche Sitzungsdauer. Dies validiert die gesamte Gleichzeitigkeitsberechnung aus Schritt drei.

Analysieren Sie danach Ihre Lasttestergebnisse basierend auf diesen fünf Punkten, passen Sie das Skript an und führen Sie den Test erneut durch. Zwei Iterationen reichen meist aus, um ein Modell zu erstellen, dem Sie vertrauen können.

Häufig gestellte Fragen

Das Fazit

Ein realistisches Traffic-Muster besteht aus vier Messgrößen, nicht einer einzigen Zahl: wie schnell Sitzungen ankommen, was diese Sitzungen tun, wie lange Nutzer zwischen Aktionen pausieren und von wo aus sie sich verbinden. Jeder einzelne dieser Werte liegt bereits in Ihren Protokollen vor.

Ziehen Sie diese vier Werte heran, wenden Sie Little’s Law an, um eine mit Daten untermauerte Gleichzeitigkeitszahl zu erhalten, und formen Sie den Anstieg zur realen Stunde statt einer geraden Linie. Validieren Sie dann den Testlauf mit der Produktion und passen Sie ihn an. Es ist mehr Arbeit als eine runde Zahl an virtuellen Nutzern auszuwählen, aber es ist die einzige Testvariante, deren Ergebnisse Sie verwerten können.

Testen Sie Ihr Traffic-Modell in echten Browsern

LoadView führt Ihre Sitzungsabläufe in echten Browsern aus über 40 AWS- und Azure-Regionen aus, mit Lastkurven, die Sie auf das gemessene Ankunftsmuster anpassen können. Enterprise-Lasttest-Pläne fügen Unterkonten, SSO und Skriptmigration von Legacy-Tools hinzu.

Vereinbaren Sie eine Demo mit einem LoadView-Performance-Ingenieur, um Ihr Traffic-Modell gemeinsam durchzugehen.