Wie man Lasttests dimensioniert: Drei praktische Methoden

Der größte Fehler, den Teams bei Lasttests machen, passiert oft bevor auch nur ein einziges Script geschrieben wurde: Sie wählen die falsche Testgröße. Ein zu kleiner Lasttest vermittelt falsche Sicherheit. In Ihren Dashboards sieht alles grün aus, aber wenn der Traffic in der Produktion ansteigt, treten die Risse zu Tage. Ein zu großer Lasttest ist ebenso schlecht. Sie verschwenden Zeit, Geld und Infrastruktur, indem Sie ein Szenario testen, das niemals eintritt, und jagen am Ende phantomhaften Engpässen hinterher.

Es gibt zahlreiche Mahnbeispiele. Einem Unternehmen etwa reichte es, vor dem Black Friday nur mit 500 gleichzeitigen Nutzern zu testen, weil das „sicher erschien“. Minütlich nach dem Livegang schoss der Traffic auf 2.500 Nutzer und die Checkout-Pipeline brach zusammen. Am anderen Ende des Spektrums bestand eine Universität darauf, ihr neues Portal mit 1.000 Nutzern zu testen, obwohl der historische Spitzenverkehr niemals über 5.000 lag. Ergebnis: aufgeblähte Cloud-Kosten und ein verlorener Monat, in dem Engpässe verfolgt wurden, die in der Realität nie ausgelöst worden wären.

Die Größenbestimmung ist der Punkt, an dem sich die Kunst und die Wissenschaft des Lasttestens treffen. Sie brauchen eine Zahl, die groß genug ist, um aussagekräftig zu sein, aber zugleich solide genug, um die Realität abzubilden. Das Problem ist, dass die meisten Teams keine saubere „gleichzeitigen Nutzer“-Zahl in ihren Projektdokumenten haben. Viele greifen zu runden Zahlen wie 500, 1.000 oder 10.000, weil diese auf einer Folie autoritär wirken — das reicht nicht aus.

In diesem Artikel führen wir Sie durch drei erprobte Methoden zur Dimensionierung Ihrer Lasttests: 1) anforderungsgetrieben, 2) transaktionsbasiert und 3) analytikbasiert. Jede Methode liefert ein Framework, um unordentliche oder unvollständige Daten in eine verteidigungsfähige Testgröße zu verwandeln — eine, die dem Produktionsverkehr entspricht, statt auf Vermutungen zu beruhen.

Methode 1: Anforderungsgetriebenes Dimensionieren

Wenn Sie Glück haben, enthalten Ihre Anforderungen die Antwort bereits — Sie müssen nur zwischen den Zeilen lesen.

Manche Szenarien machen es offensichtlich. Plant Ihr Unternehmen ein Live-Town-Hall-Event mit obligatorischer Teilnahme, dann entspricht die Gleichzeitigkeit der Anzahl der Anwesenden. Bei 1.000 Mitarbeitenden sollten Sie für 1.100 gleichzeitige Nutzer testen (Teilnehmerzahl plus 10% Sicherheitszuschlag). So einfach kann es sein.

Andere Ereignisse sind komplizierter, aber dennoch vorhersehbar. Nehmen Sie ein System zur Kursanmeldung an einer Universität. Die meiste Zeit im Jahr ist der Traffic stabil und moderat. Am Einschreibe-Tag wird das System jedoch stark belastet. Studierende drängen, um Plätze in beliebten Kursen zu ergattern, und der Traffic schnellt weit über die normale Basis hinaus. Wenn Sie wissen, dass es 10.000 Studierende gibt und die Erfahrung zeigt, dass 90 % von ihnen während der Einschreibung das System nutzen werden, sind das 9.000 gleichzeitige Nutzer. Wenn Studierende Freunde oder Familienmitglieder mobilisieren, die sich von mehreren Geräten einloggen, kann die reale Gleichzeitigkeit 100 % der Studentenpopulation übersteigen. Ein sicherer Test könnte den Traffic auf 200 % der Studierenden dimensionieren.

Das gilt auch in anderen Branchen. Betrachten Sie etwa ein staatliches Steuerportal im April. Das System kann das ganze Jahr über gering ausgelastet sein, aber am Abgabetag steigt die Gleichzeitigkeit dramatisch an. Oder denken Sie an eine Konzert-Ticketing-Plattform. Bei den meisten Events verteilt sich der Traffic, aber wenn Tickets für einen großen Künstler punktgenau um 10:00 Uhr freigegeben werden, drücken Tausende Fans gleichzeitig auf „Aktualisieren“ (ganz zu schweigen von Bots, die Tickets kaufen wollen — das ist ein gesonderter Punkt). Das sind anforderungsgetriebene Momente, und Ihr Lasttest muss entsprechend dimensioniert sein.

Fallstricke: Anforderungen werden häufig unterschätzt. Stakeholder können die Teilnahme niedrig ansetzen, um im Budget konservativ zu wirken, oder sie berücksichtigen nicht die „Lurker“, die sich früh einloggen, oder Bots. Hinterfragen Sie stets die Zahl, modellieren Sie Surge-Verhalten und fügen Sie Puffer hinzu.

Faustregel: Anforderungsgetriebenes Dimensionieren funktioniert am besten, wenn das Ereignis zeitlich begrenzt und vorhersehbar ist und klare Teilnehmerzahlen vorliegen. In diesen Fällen liefern die Anforderungen die verteidigungsfähigste Basis.

Methode 2: Transaktionsbasiertes Dimensionieren

Wenn die Anforderungen keine Zahl liefern, tun es Ihre Geschäftstransaktionen. Statt in abstrakten Nutzern zu denken, denken Sie in Aktionen: Bestellungen, Registrierungen, Zahlungen, Uploads, Gebote.

Die Rechnung funktioniert so:

1. Identifizieren Sie das Spitzen-Transaktionsvolumen. Angenommen, Ihre E-Commerce-Plattform verarbeitet an einem typischen Tag 1.000 Bestellungen, steigt das Volumen während der Feiertage um 50 % auf 1.500 Bestellungen.
2. Finden Sie das aktive Zeitfenster. Wenn die meisten Bestellungen zwischen 10:00 und 22:00 Uhr erfolgen, ist das ein 12-Stunden-Fenster, also ~125 Bestellungen pro Stunde.
3. Berücksichtigen Sie ungleichmäßige Verteilung. Traffic ist selten gleichmäßig. Sind die Spitzenstunden 25 % höher, sind das ~160 Bestellungen in der geschäftigsten Stunde.
4. Übersetzen Sie das in Gleichzeitigkeit. Dauert ein Bestellvorgang fünf Minuten, dann entsprechen 160 Bestellungen/Stunde 2,67 Bestellungen/Minute. Multipliziert mit fünf Minuten ergibt das ~14 gleichzeitige Nutzer, die tatsächlich Bestellungen abschließen.
5. Fügen Sie Browsing-Traffic hinzu. Käufer sind nicht die ganze Geschichte. Zeigen Ihre Analysen zehn Browser pro Käufer, sind das weitere 140 gleichzeitige Nutzer.
6. Fügen Sie einen Puffer hinzu. Mit einer Sicherheitsmarge von 25 % sind Sie jetzt bei ~190 Nutzern. Je nach Variabilität können Sie 50 % oder 100 % oder mehr hinzufügen.

Das ist in diesem Beispiel die Testgröße: 190 gleichzeitige Nutzer, die die geschäftsrelevanten Spitzen-Transaktionsmuster Ihres Systems nachbilden.

Diese Methode funktioniert gut, weil sie die Last direkt an Geschäftsergebnisse knüpft. Sie testen nicht nur „190 Nutzer“, Sie validieren die Fähigkeit, „160 Spitzenbestellungen/Stunde plus Browsing“ zu verarbeiten — eine Zahl, die Stakeholdern verständlich und wichtig ist.

Zweites Beispiel: Auktionsplattformen. Angenommen, Sie sehen im Schnitt 10.000 Gebote pro Tag, davon 40 % in den letzten zwei Stunden hochkarätiger Auktionen. Das sind 4.000 Gebote in zwei Stunden oder ~2.000/Stunde. Dauert ein Gebot im Schnitt 30 Sekunden, sind das ~16 gleichzeitige Bieter. Ist das Verhältnis von Browsing zu Bieten 30:1 (bei Auktionsseiten üblich), müssen Sie fast 500 Nutzer simulieren, um die reale Last abzubilden. Diese Testgröße zeigt, ob Ihr System nicht nur den Biet-Spike, sondern auch die Flut an Browsing-Traffic verträgt.

Saisonalität spielt ebenfalls eine Rolle. Nicht nur der Einzelhandel hat Spitzen. Reiseplattformen erleben Nachfrageanstiege während Frühlingsferien und Feiertagen. Steuerportale sind im April stark belastet. SaaS-Onboarding schießt bei Vertragsabschlüssen in die Höhe. Transaktionsbasiertes Dimensionieren passt sich all dem an, indem es Gleichzeitigkeit an geschäftsspezifische Ereignisse bindet.

Faustregel: Verwenden Sie transaktionsbasiertes Dimensionieren, wenn Anforderungen vage sind, die Geschäftsdaten aber klar. Es ist genau, stakeholderfreundlich und lässt sich direkt in geschäftsrelevante Ergebnisse übersetzen.

Methode 3: Analytikbasiertes Dimensionieren

Fehlen Anforderungen und Transaktionsdaten, können Analyse-Tools die Lücke füllen. Google Analytics, Adobe Analytics oder ähnliche Plattformen liefern Traffic-Daten, die sich mit ein wenig Mathematik in Gleichzeitigkeit umrechnen lassen.

So gehen Sie vor:

1. Starten Sie mit dem Spitzen-Traffic. Nehmen wir an, Ihre Seite hatte am stärksten Tag 50.000 Besucher.
2. Wandeln Sie das in stündlichen Traffic um. Durch 24 geteilt = ~2.100 Besucher/Stunde.
3. Korrigieren Sie für Spitzen. Traffic ist nicht gleichmäßig. Fügen Sie 50 % hinzu, um ungleichmäßige Verteilung zu berücksichtigen → ~3.150 Besucher/Stunde.
4. Nutzen Sie die durchschnittliche Sitzungsdauer. Verweilen Nutzer im Schnitt zwei Minuten, dann ergibt 3.150 / 60 × 2 ≈ 105 gleichzeitige Nutzer.
5. Fügen Sie einen Puffer hinzu. Mit 25 % Marge sind Sie bei ~130 gleichzeitigen Nutzern.

Das ist Ihre Testgröße: 130 Nutzer, die den stärksten Traffic widerspiegeln, den Ihre Analytik gemessen hat.

Beispiel: Ein SaaS-Unternehmen mit 500.000 monatlich aktiven Nutzern. Sind die täglichen aktiven Nutzer ~10 % davon (50.000) und 20 % loggen sich in Spitzenstunden ein, haben Sie 10.000 Nutzer im geschäftigsten Fenster. Bei einer durchschnittlichen Sitzungsdauer von 15 Minuten entspricht das ~2.500 gleichzeitigen Nutzern, die getestet werden sollten.

Genauigkeits-Vorbehalte: Analytik ist besser als nichts, aber nicht perfekt. Bedenken Sie:

• Ad-Blocker können Besuche verschleiern.
• Cookie-Consent-Banner können zu Unterzählungen führen, wenn Nutzer das Tracking ablehnen.
• Bot-Traffic kann die Zahlen aufblähen, wenn er nicht herausgefiltert wird.

Trotz dieser Einschränkungen sind Analytikdaten ein praktikabler Rückgriff. Sie spiegeln reale Nutzersitzungen wider, sind über Geräte und Standorte normalisiert und lassen sich nach Geografie oder Gerätetyp segmentieren, falls Ihr Traffic regional oder mobillastig ist.

Faustregel: Nutzen Sie analytikbasiertes Dimensionieren, wenn Geschäftsdaten nicht vorhanden sind, Sie aber konsistente Traffic-Daten haben. Es ist der praktischste Weg, Tests an der Realität auszurichten.

Sonderfall: Brandneue Anwendungen

Was ist, wenn Sie völlig neu mit einer Anwendung starten? Sie haben weder Anforderungen, die Gleichzeitigkeit definieren, noch Transaktionshistorie oder Analytikdaten — das ist eine ganz andere Herausforderung.

Ein häufiger Fehler ist, eine runde Zahl wie „2.000 gleichzeitige Nutzer“ zu wählen, weil sie sich sicher anfühlt. Diese Zahl ist jedoch bedeutungslos, wenn sie nicht an erwartetes Nutzerverhalten gebunden ist.

Ein besserer Ansatz ist, den Traffic in Transaktionen oder Sitzungen zu projizieren. Erwarten Sie 200 Uploads pro Stunde, dimensionieren Sie den Test, um das zu validieren. Erwarten Sie 10.000 Registrierungen am Launch-Tag, wandeln Sie das in Stundenverkehr und Sitzungsdauer um. Auch grobe Schätzungen, so sie in dieser Form formuliert sind, liefern Ergebnisse, die sich geschäftlich interpretieren lassen — es ist Mathematik, die Sie modellieren oder berechnen können.

Beispiel: Das Marketing projiziert 5.000 Registrierungen in der Launch-Woche, angetrieben von einer großen Pressemitteilung. Fallen 60 % davon auf den ersten Tag, sind das 3.000 Registrierungen. Verteilt sich das ungleich mit 40 % in den ersten drei Stunden, sind das ~1.200 Registrierungen. Dauert die Kontoerstellung drei Minuten, ergibt das ~60 gleichzeitige Registrierungen. Addieren Sie Browsing und Wiederholungsverkehr, und ein plausibler Testbereich läge bei 200–300 gleichzeitigen Nutzern. Diese Zahl beruht auf Annahmen, aber sie sind zumindest explizit und lassen sich mit echten Daten verfeinern.

Vorsicht vor Wunschzahlen von Managern: Stakeholder könnten große runde Zahlen fordern („Lasst uns 50.000 Nutzer testen, um Investoren zu beeindrucken“). Widerstehen Sie dem. Überdimensionierte Tests schaffen kein Vertrauen — sie erzeugen Rauschen und Verschwendung. Basieren Sie Ihre Dimensionierung auf projizierten Transaktionen, auch wenn es Schätzungen sind.

Zusammenfassungstabelle: Die richtige Methode wählen

Methode	Wann verwenden	Stärken	Risiken/Nachteile
Anforderungsgetrieben	Vorhersehbare, zeitlich begrenzte Ereignisse	Klar, verteidigungsfähig, leicht zu berechnen	Unterschätzung durch Stakeholder, Interessenkonflikte
Transaktionsbasiert	Bestehende Apps mit klaren Geschäftsdaten	Direkter Bezug zu Geschäftsergebnissen, genaue Verhältnisse	Benötigt gute Metriken, saisonale Effekte
Analytikbasiert	Sites mit konstantem Traffic-Verlauf	Leicht berechenbar, basiert auf realen Sitzungen	Ad-Blocker, Bots, ungleichmäßige Genauigkeit
Neue Anwendungen	Kein Verlauf oder Daten vorhanden	Zwingt zu expliziten Annahmen, zukunftsgerichtet	Risiko von Schätzungen

Schlussbemerkungen zur richtigen Dimensionierung von Lasttests

Der Zweck eines Lasttests ist nicht, eine Zahl zu erreichen — er soll eine Frage beantworten. Kann Ihr System die spezifischen Verhaltensweisen und Ereignisse bewältigen, die für Ihr Geschäft wichtig sind?

• Geben die Anforderungen direkte Zahlen vor, verwenden Sie diese.
• Wenn nicht, bieten Transaktionen den genauesten, geschäftsnahen Anker.
• Sind diese nicht verfügbar, bietet die Analytik eine verlässliche Alternative.
• Bei völlig neuen Systemen sind Projektionen besser als willkürliche Schätzungen.

Und egal welche Methode Sie wählen, fügen Sie stets einen Puffer hinzu. Echtwelt-Traffic ist sprunghaft, unvorhersehbar und selten passend zu idealen Durchschnittswerten.

LoadView hilft dabei, jede dieser Dimensionierungsstrategien praktisch anwendbar zu machen. Mit LoadView können Sie nicht nur Benutzerzahlen modellieren, sondern realistische Muster nachbilden — Burst-Traffic während Einschreibungen, gemischtes Browsing und Bestellen oder eine globale Verteilung, die Ihren Analytikdaten entspricht. Das bedeutet, Ihr Test ist nicht nur eine Zahl, sondern eine Generalprobe für die Produktionsrealität.

Die Größenbestimmung ist die erste Entscheidung bei jedem Lasttest. Treffen Sie sie richtig, und alle nachfolgenden Ergebnisse haben Bedeutung. Treffen Sie sie falsch, und kein Script oder Bericht wird Sie retten. Mit den drei hier beschriebenen Methoden können Sie Ihre Tests selbstbewusst dimensionieren und sicherstellen, dass Ihre Performance-Ergebnisse tatsächlich dem Traffic und der Aktivität auf Ihrer Website oder Anwendung entsprechen.