Crypto Casino
Bieg torrent
Testowanie obciążenia: profile graczy i szczyty ruchu
1) Dlaczego profile modelu zamiast „średniej temperatury”
Ładunki iGaming mają wysokie materiały wybuchowe: promocje/turnieje/strumienie dają wiele wybuchów RPS, a rozkład działań jest nierówny (login → depozit → stavki/vyvod). Test musi odzwierciedlać zachowanie segmentów (początkujących, VIP, „łowców bonusów”, mobilnych), w przeciwnym razie otrzymasz „zielone wykresy” i czerwone incydenty.
Kluczowe SLO (przykład 30-dniowy):- Logowanie: sukces ≥ 99. 9%, p95 ≤ 250 ms
- Depozyt: sukces ≥ 99. 85%, p95 ≤ 400 ms
- WS: komunikat p95 RTT ≤ 120 ms, szybkość odłączenia ≤ 0. 5%
- Start gry: sukces ≥ 99. 8%, p95 ≤ 800 ms
2) Profile gracza (scenariusze behawioralne)
A. Newbie (nowy gracz) - 25-40% ruchu szczytowego
Ścieżka: rejestracja → login → zobacz promo → depozyt (małe kwoty) → uruchomienie 1-2 slotów
Cechy: wysoki odsetek błędów UX, płatności retrasy, skoki między stronami
B. Regularne - 40-50%
Ścieżka: login → szybki depozyt/bez depozytu → 3-5 gier → rzadkie wycofanie
Cechy: stabilne sesje, wrażliwe na p95> 200ms na WS
C. Bonus-hunter (promo) - 10-20% w promocjach
Ścieżka: Zarejestruj → Aktywuj bonus → Minimalne oferty → Szybka próba wypłaty
Cechy: wybuchy do '/promo/claim ', przekaźnik nadużycia, częste 429 bez poprawnych ograniczeń
D. Wysoki wałek/VIP - ≤ 1%, ale wysoka kontrola
Ścieżka: login → duży depozyt → gry na żywo/wysokie stawki → wycofanie
Funkcje: wrażliwe na wszelkie opóźnienia/pliki dostawcy gier, krytyczne płatności SLA
E. Bettor (sport/na żywo)- Ścieżka: login → subskrypcja cytatów → częste zakłady w „wąskich oknach” (do 10-30 s)
- Cechy: pulsujące WS obciążenie/współczynnik pamięci podręcznej, wybuchy bramkowe/VAR
3) Modele ruchu i harmonogram
Open vs Model zamknięty
Open (Poisson, przyloty/sek) - nadaje się do publicznych promocji i strumieni (użytkownicy „przyjdą sami”).
Zamknięte (poprawka. liczba wirtualnych użytkowników z myślami) - dla sesji stabilnych (VIP, gry na żywo).
Wzory ruchu:- Rampa: przyspieszenie liniowe x1 → x5 w 10-20 minut
- Burst: x3-x10 „bang” dla 30-120s (bonus/jackpot/cel ogłoszenia)
- Fala: Grzbiety co 5-10 min (runda strumieniowa/turniejowa)
- Moczenie: 2-12 h stabilne obciążenie (wycieki, GC, deskryptory, degradacja)
4) Przepływ krytyczny i mierniki
Uwierzytelnianie i profil
RPS na '/login ', '/2fa/verify', p95/p99, wskaźnik błędów, blokada/ratelimit-trips
Płatności
Bramki do gier
Start slot/live table: success-ratio, time-to-first-spin, provider failure
WebSocket: połączenia w piku, wiadomości/sec, RTT, rate-limit/429, reconnects/min
Promocje/premie
'/promo/claim ', '/freespin/activate': 200/4xx/5xx, share 409/competitive updates, cascades to wallet
Sklepienia i kolejki
Nasycenie: procesor, połączenia DB, timeouts puli, opóźnienie kolejki, pauzy GC
5) Sieć geo i rzeczywistość
Dystrybucja geograficzna według rynku (EU/LatAm/MEA/APAC) i ASN mix (sieci mobilne, hosting).
krawędź → opóźnienie pochodzenia (Anycast/CDN), mobilny RTT, utrata pakietu.
A/B: z CDN i omijaniem (pochodzenie) - do oceny „czystego” backendu.
6) Projekt danych testowych
Pseudonimizowane konta, karty BIN według regionu, waluty, stany KYC.
Realistyczne czasy behawioralne: czas myślenia 1-7 s dla dorywczych, 0. 3–1. 2 s dla zakładów na żywo.
Kontrola operacji nieidempotentnych (wypłata/depozyt): tryb suchy dla piaskownicy PSP, wtyczki portfelowe.
Filtry przeciw oszustwom/bot: biała lista testów ASN/IP/urządzeń, inaczej WAF/anty-bot „udusi” stoisko.
7) Plan testów (szablon wydania/promocji)
1. Obciążenie dymem: 10-20% piku, 30 min
2. Rampa pojemności: x1 → cel → x1. 5 od szczytu docelowego, 10-15 min na krok
3. Seria Burst: 3-5 fal 60-120 s na x3-x5 z obecnego poziomu
4. Moczenie: 4-8 h przy 60-80% szczycie (wyciek, degradacja)
5. Awaria/chaos: wyłączenie jednego PSP/PoP, poniżenie dostawcy gry, zrzucenie jednej bazy danych odłamków
6. WS-storm: masa ponownie połączyć + 5-10 × wiadomości w ciągu 2-3 min
7. Promo-storm : /promo/roszczenie + rejestracja + depozyt w 60 sekund „okno”
Kryteria wyjścia: wszystkie SLO w zielonej strefie; zagłówek ≥ 30% nad procesorem/połączeniami; Kwoty PSP nie są przekroczone; brak wzrostu kolejki i p99 po teście.
8) Wzory infrastruktury do wytrzymania szczytów
Ciepła pula/rezerwa współistnienie (funkcje/kontenery), przed skala przed promo.
Pooling połączeń i górne granice (DB/PSP) + kolejki żądań.
Klucze idempotencji na depozytach/hakach webowych.
Backpressure: 429/503 z 'Retry-After', degradacja „ciężkich” korzeni (raporty/wyszukiwanie).
Pamięć podręczna/krawędź współczynników i statycznych metadanych gier.
9) Anty-regresja: co „łamie” w pierwszej kolejności
Przepełnione baseny DB → p99 wzrost i terminy
Blokada portfela do aktualizacji bilansu masowego- Limity PSP → lawina retras i przyjmuje
- Transmisja WS dla tysięcy subskrypcji nierzeźniczych
- Zbyt agresywne zasady WAF → FPR dotyczące logowania/depozytu
10) Obserwowalność podczas badania
Deski rozdzielcze RED/USE + lejki biznesowe (login → depozit → stavka → vyvod).
Ślady od końca do końca dla zapytań o błąd/powolny (100% błędów próbki).
Markery etapu badania (rampa/wybuch) w metrykach/dziennikach.
Oddzielne panele dostawcy PSP/gry, kolejka retray, hity idempotencji.
11) Zespół i proces
Pokój wojenny: inżynier wydajności, backend, SRE, ryzyko/płatności, WAF/bezpieczeństwo, produkt.
Runbook: co robimy z p99> cel, jak zmniejszyć obciążenie, kto dzwonić od dostawcy.
Raport: SLO, przepustowość, wąskie gardła, koszty, kod/architektura/zalecenia kwot.
12) Plan Kapasiti: od liczby graczy do RPS
Ocena (przykład):- Współistniejący gracze na szczycie: 50k
- Średnia częstotliwość działań: 0. 25–0. 5 req/s na gracza (telefon poniżej, na żywo powyżej)
- Ocena RPS API: 12. 5k-25k + żądania serwisowe (portfel, dostawcy, pamięć podręczna)
- WS: 30-60k aktywne połączenia, 3-8 msg/s na stół/motyw
- Dodaj 30-50% zagłówek do pęknięcia i retrai
13) Lista kontrolna przygotowania ławki
- Dane: konta/portfele/karty/waluty/kraje/gry, pseudonimizowane
- Odizolowanie płatności: piaskownica + wtyczki haków internetowych, zakaz „żywych” odpisów
- Krawędź/CDN/WAF jako prod; anty-boty w trybie „miękkim” do badania ASN
- Obserwowalność: deski rozdzielcze, alerty, włączone śledzenie
- Konfiguracja autoskali i ciepłej puli; udokumentowane limity puli/połączenia
- Flaga kanaryjska dla „ciężkich” cech (raporty, masowy eksport)
14) Narzędzia (punkty orientacyjne)
Generatory: k6, Gatling, szarańcza (HTTP/WS), JMeter (w tym wtyczka WebSocket)
Emulatory paszy: niestandardowe skrypty cytatów/dostawców gier
Powtórny ruch: tcpreplay/ingress lustro z anonimizacji i normalizacji
15) Przykład profilu „Turniej promo, 60 sekund przed rozpoczęciem” (przypadek)
Fala − 5 min → 0:- Otwarte przyjazdy: 400 → 2500 req/s (login/refresh)
- „/promo/claim ”: wybuchy 1000 rps 3 × 20 s
- WS: + 15k connect, + 5 msg/s na „liderboard”
- Pamięć podręczna przed ciepłym i ciepłym basenem
- Limit stawki '/promo/claim ': 10/min IP, 2/min account, 30-sekundowy negatywny bufor odpowiedzi
- Idempotencja i bonusowa kolejka memoriałowa (partia 50-100/cykl)
- „Miękkie” 429 z 'Retry-After' + Postęp interfejsu użytkownika
Kryteria sukcesu: brak degradacji login/deposit SLO, p95 WS <150 ms, <0. 5% błędów roszczeń, brak inflacji kolejki.
Wznów streszczenie
Testowanie obciążenia iGaming to modelowanie behawioralne, a nie "strzelanie do punktów końcowych. "Najpierw zdefiniuj SLO i profile graczy, a następnie wybierz model ruchu (otwarty/zamknięty), zbuduj prawdziwe scenariusze logowania/depozytu/zakładów/promocji z limitami geo i PSP, wybuchów testowych i moczenia, umożliwienie obserwacji i przygotowanie autoskali. Fix wynik z planu kapitałowego i runbooks - w ten sposób można spotkać szczyty ruchu bez niespodzianek i strat konwersji.