Belastungstests: Spielerprofile und Verkehrsspitzen

1) Warum Profile modellieren und nicht „Durchschnittstemperatur“

Die iGaming-Last hat eine hohe Sprengkraft: Promo/Turniere/Streams geben mehrere RPS-Spitzen und die Verteilung der Aktionen ist ungleichmäßig (login→depozit→stavki/vyvod). Der Test sollte das Verhalten der Segmente (Anfänger, VIP, „Bonusjäger“, Mobile) widerspiegeln, sonst erhalten Sie „grüne Charts“ und rote Vorfälle.

Wichtige SLOs (Beispiel für 30 Tage):

Login: Erfolg ≥ 99. 9%, p95 ≤ 250 ms
Einzahlung: Erfolg ≥ 99. 85%, p95 ≤ 400 ms
Einsatz (WS): p95 message RTT ≤ 120 ms, Diskontrate ≤ 0. 5%
Spielstart: Erfolg ≥ 99. 8%, p95 ≤ 800 ms

2) Spielerprofile (Verhaltensszenarien)

A. Newbie (neuer Spieler) - 25-40% des Spitzenverkehrs

Pfad: Registrierung → Login → Anzeigen → Promo-Einzahlung (kleine Beträge) → Starten von 1-2 Slots

Features: hoher Anteil an UX-Fehlern, Payment Retrays, Sprünge zwischen den Seiten

B. Regular (rückzahlbar) - 40-50%

Pfad: Login → schnelle Einzahlung/keine Einzahlung → 3-5 Spiele → seltene Auszahlung

Eigenschaften: stabile Sitzungen, empfindlich auf p95> 200ms auf WS

C. Bonus-hunter (promo) - 10-20% bei Aktionen

Pfad: Registrierung → Aktivierung des Bonus → Mindesteinsätze → Versuch einer schnellen Auszahlung

Features: Ausbrüche von '/promo/claim', Missbrauch von Retrays, häufige 429 ohne richtige Grenzen

D. High-Roller/VIP - ≤ 1%, aber ein hoher Scheck

Pfad: Login → große Einzahlung → Live-Spiele/hohe Einsätze → Auszahlung

Features: empfindlich auf jede Verzögerung/Fälschungen des Spieleanbieters, kritisch auf SLA-Zahlungen

E. Bettor (Sport/Live)

Pfad: Login → Abonnement von Zitaten → häufige Gebote in „engen Fenstern“ (bis zu 10-30 s)
Besonderheiten: pulsierende Belastung auf WS/Koeffizientencache, Spitzen bei Toren/VAR

3) Verkehrsmuster und Timing

Open vs Closed model

Offen (Poisson, Ankunft/sec) - geeignet für öffentliche Promos und Streams (Benutzer „kommen selbst“).

Geschlossen (fix. Anzahl der virtuellen Benutzer mit think-time) - für stabile Sitzungen (VIP, Live-Spiele).

Verkehrsmuster:

Rampe: lineare Beschleunigung x1 → x5 in 10-20 Minuten
Burst: „Explosion“ x3-x10 bei 30-120 s (Bonus/Jackpot/Ziel Ankündigung)
Welle: Wappen alle 5-10 Minuten (Stream/Turnierrunden)
Soak: 2-12 h stabile Belastung (Leckagen, GC, Deskriptoren, Degradationen)

4) Kritische Flows und Metriken

Authentifizierung und Profil

RPS auf '/login', '/2fa/verify', p95/p99, error-rate, lock/ratelimit-run

Zahlungen

`/payments/deposit	withdraw 'nach Anbietern: success-ratio, p95/p99, Sticheleien, Idempotenz
PSP-Einschränkungen (per-merchant RPS/Transaktionen pro Minute), Retraywarteschlange

Spieltore

Slot/Live Table Start: Success-Ratio, Time-to-First-Spin, Anbieterausfall

WebSocket: Verbindungen in der Spitze, Nachrichten/sec, RTT, rate-limit/429, reconnects/min

Promo/Boni

„/promo/claim “, „/freespin/activate“: 200/4xx/5xx, Anteil 409/wettbewerbsfähige Upgrades, Kaskaden pro Wallet

Speicher und Warteschlangen

Saturation: CPU, DB-connections, pool-timeouts, queue lag, GC pauses

5) Geo und die Realität des Netzwerks

Geo-Distribution nach Märkten (EU/LatAm/MEA/APAC) und ASN-Mix (Mobilfunknetze, Hosting).

Latenz edge→origin (Anycast/CDN), mobile RTT, Paketverluste.

A/B: mit CDN und Bypass (Herkunft) - um das „saubere“ Backend zu bewerten.

6) Design der Testdaten

Pseudonymisierte Konten, BIN-Karten nach Region, Währung, KYC-Status.

Realistische Verhaltenszeiten: think-time 1-7 s für casual, 0. 3–1. 2 s für Live-Wetten.

Kontrolle von nicht-identischen Transaktionen (Ausgabe/Einzahlung): Trockenmodus für PSP-Sandbox, Wallet-Stecker.

Anti-Betrug/Bot-Filter: Whitelist von ASN/IP/Device-Tests, sonst wird WAF/Anti-Bot den Stand „ersticken“.

7) Testplan (Vorlage für Release/Promo)

1. Rauchbelastung: 10-20% des Peaks, 30 min

2. Capacity ramp: x1 → target → x1. 5 vom Zielpeak, 10-15 min pro Stufe

3. Burst-Serie: 3-5 Wellen von 60-120 s auf x3-x5 vom aktuellen Niveau

4. Soak: 4-8 h bei 60-80% Peak (Leckagen, Degradation)

5. Failover/Chaos: Deaktivierung einer einzelnen PSP/PoP, Degradierung des Spieleanbieters, Fall einer einzelnen Shard-DB

6. WS-Sturm: Massenreconnect + 5-10 × Nachrichten innerhalb von 2-3 Minuten

7. Promo-Sturm : /promo/claim + Registrierung + Einzahlung in 60-sec „Fenster“

Ausstiegskriterien: alle SLOs im grünen Bereich; headroom ≥ 30% auf CPU/Anschlüsse; die PSP-Quoten werden nicht überschritten; kein Anstieg der Warteschlangen und p99 nach dem Test.

8) Infrastrukturmuster, um Spitzen zu widerstehen

Warm-pool/provisioned concurrency (Funktionen/Container), pre-scale vor promo.

Verbindungspooling und Upstream-Limits (DB/PSP) + Anforderungswarteschlangen.

Idempotency Keys für Einzahlungen/Webhooks.

Backpressure: 429/503 mit „Retry-After“, Abbau von „schweren“ Roots (Berichte/Suche).

Cache/Edge-Cache von Koeffizienten und statischen Metadaten von Spielen.

9) Anti-Regression: Was zuerst „bricht“

Überfüllte DB-Pools → p99-Wachstum und Timeouts

Wallet-Locking bei Massenupdates der Bilanz

PSP-Rate Limits → Lawine von Retraits und Takes
WS-Übertragung für Tausende von Abonnements ohne Batching
Zu aggressive WAF-Regeln → FPR auf Login/Einzahlung

10) Beobachtbarkeit während des Tests

Dashboards RED/USE + Business-Trichter (login→depozit→stavka→vyvod).

Ende-zu-Ende-Traces für „langsame „/fehlerhafte Anfragen (100% Fehlerprobe).

Prüfphasen-Marker (ramp/burst) in Metriken/Protokollen.

Einzelne Panels von PSP/Spieleanbietern, Warteschlange von Retrays, Idempotency-Hits.

11) Team und Prozess

Kriegsraum: Performance Engineer, Backend, SRE, Risiko/Zahlungen, WAF/Sicherheit, Produkt.

Runbook: Was machen wir bei p99> target, wie senken wir die Belastung, wen rufen wir beim Anbieter an.

Bericht: SLO, Bandbreite, Engpässe, Kosten, Code/Architektur/Quota-Empfehlungen.

12) Capacity-Plan: Von der Anzahl der Spieler zum RPS

Bewertung (Beispiel):

Gleichzeitige Spieler in der Spitze: 50k
Durchschnittliche Häufigkeit der Aktionen: 0. 25–0. 5 req/s pro Spieler (Handy unten, live oben)
Bewertung RPS API: 12. 5k-25k + Serviceanfragen (Wallet, Provider, Cache)
WS: 30-60k aktive Anschlüsse, 3-8 msg/s pro Tisch/Thema
Fügen Sie 30-50% Kopfraum auf Burst und Retrays hinzu

13) Checkliste Standvorbereitung

Daten: Konten/Wallets/Karten/Währungen/Länder/Spiele, pseudonymisiert
Zahlungsisolierung: Sandbox + Webhook-Stecker, Verbot von „Live“ -Abschreibungen
Edge/CDN/WAF wie in der Produktion; Anti-Bots im „weichen“ Modus für Test-ASNs
Beobachtbarkeit: Dashboards, Alerts, Tracing inklusive
Autoscale und Warmpool konfiguriert; Pool-/Connectlimits dokumentiert
Kanarische Flagge für „schwere“ Fitch (Berichte, Massenexporte)

14) Instrumente (Benchmarks)

Generatoren: k6, Gatling, Locust (HTTP/WS), JMeter (inkl. WebSocket Plugin)

Feed-Emulatoren: benutzerdefinierte Skripte von Zitaten/Spieleanbietern

Replay-Verkehr: tcpreplay/ingress-Spiegelung mit Anonymisierung und Normalisierung

15) Beispielprofil „Promo-Turnier, 60 Sekunden vor dem Start“ (Fall)

Die Welle − 5 min → 0:

Offene Ankunftszeiten: 400 → 2.500 req/s (login/refresh)
„/promo/claim “: bursts von 1 000 rps 3 × von 20 s
WS: + 15k connect, + 5 msg/s zum Thema „leaderboard“

Bereitschaft:

Cache- und Warmpool-Vorwärmen
Rate-limit '/promo/claim': 10/min IP, 2/min Konto, 30-sec negative Antworten Cache
Idempotenz und Bonus Charge Warteschlange (Batch 50-100/Takt)
„Soft“ 429 mit 'Retry-After' + UI-Fortschritt

Erfolgskriterien: keine SLO-Degradation Login/Einzahlung, p95 WS <150 ms, <0. 5% Claim-Fehler, kein Aufblasen von Warteschlangen.

Zusammenfassung

iGaming Load Testing ist eine Verhaltensmodellierung und kein „Endpoint Shooting“. Definieren Sie zuerst SLOs und Spielerprofile, wählen Sie dann ein Verkehrsmodell (offen/geschlossen), erstellen Sie echte Login/Einzahlung/Wetten/Promo-Szenarien mit Geo- und PSP-Limits, testen Sie Bursts und Soak, aktivieren Sie die Beobachtbarkeit und bereiten Sie den Autoscale vor. Sichern Sie das Ergebnis mit einem Capacity-Plan und einem Runbook 'ami - so begegnen Sie Verkehrsspitzen ohne Überraschungen und Conversion-Verluste.