Test di carico: profili dei giocatori e picchi di traffico

1) Perché modellare i profili anziché «temperatura media»

Il carico iGaming è altamente esplosivo: promo/tornei/striam dà picchi RPS multipli e la distribuzione delle azioni è ineguagliabile (login→depozit→stavki/vyvod). Il test deve riflettere il comportamento dei segmenti (principianti, VIP, bonus-hunter, mobile), altrimenti si otterranno grafici verdi e incidenti rossi.

SLO chiave (esempio di 30 giorni):

Login, successo del 99. 9%, p95 ≤ 250 ms
Deposito, successo del 99. 85%, p95 ≤ 400 ms
Puntata (WS): p95 messaggi RTT da 120 ms, disonnect rate da 0. 5%
Avvia il gioco con successo 99. 8%, p95 ≤ 800 ms

2) Profili dei giocatori (scenari comportamentali)

A. Newbie (nuovo giocatore) - 25-40% di picco di traffico

Percorso: registrazione login, visualizzazione promo deposito (piccole somme), avvio 1-2 slot

Caratteristiche: alta percentuale di errori UX, ritrai di pagamento, corse tra le pagine

B. Regolare (ritorno) - 40-50%

Percorso: login di deposito rapido/senza deposito di 3-5 partite di output raro

Caratteristiche: sessioni stabili, sensibili a p95> 200 ms su WS

C. Bonus-hunter (promo) - 10-20% in azioni

Percorso: registrazione, attivazione del bonus, punteggi minimi, tentativo di output rapido

Caratteristiche: picchi dì/promo/claim ", abuso di retrai, frequenti 429 senza limiti corretti

D. High-roller/VIP - 1% ma assegno elevato

Percorso: login di un grande deposito di giochi /tassi elevati

Caratteristiche: sensibile a qualsiasi ritardo/feeling del provider di giochi, critico SLA dei pagamenti

E. Bettor (sport/live)

Percorso: login di abbonamento alla quotazione, scommesse frequenti in finestre strette (fino a 10-30 s)
Caratteristiche: carico di pulsazione WS/cache dei coefficienti, picchi a testa/VAR

3) Modelli di traffico e timing

Open vs Closed model

Open (Poisson, arrivals/sec) - Adatto per promo e striam pubblici (gli utenti vengono da soli).

Closed (fix. Numero di utenti virtuali con think-time) - per sessioni stabili (VIP, lieve).

Cartoni di traffico:

Ramp: accelerazione lineare x1 → x5 in 10-20 minuti
Burst: «esplosione» x3-x10 per 30-120 s (annuncio bonus/jackpot/gol)
Wave: creste ogni 5-10 min (stream/tornei)
Soak: 2-12 ore di carico stabile (perdite, GC, descrittori, degrado)

4) Flow critici e metriche

Autenticazione e profilo

RPS in'/login ', '/2fa/verify', p95/p99, errò-rate, lock/ratelimit-performance

Pagamenti

`/payments/deposit	withdraw 'per provider: success-ratio, p95/p99, salsiccia, idampotenza
Vincoli PSP (per-merchant RPS/transazione al minuto), coda di retrai

Gate di gioco

Esegui slot/live desktop: success-ratio, time-to-first-spin, provider guasto

WebSocket: connessioni a picco, messaggi/secondi, RTT, rate-limit/429, riavnetts/min

Promo/bonus

'/promo/claim ', '/freespin/activate': 200/4xx/5xx, quota 409/update competitivi, cascate per portafoglio

Archivi e code

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

5) Geo e realtà della rete

Distribuzione geografica dei mercati (EU/LatAm/MEA/APAC) e mix ASN (reti mobili, hosting).

Latenza edge→origin (Anycast/CDN), mobile RTT, perdita batch.

A/B: con CDN e a scapito (origin) - per valutare il backend «puro».

6) Progettazione dei dati di prova

Account alias, carta BIN per regione, valuta, stato KYC.

Timing comportamentali realistici: think-time 1-7 c per casual, 0. 3–1. 2 c per le scommesse live.

Controllo operazioni non idonee (output/deposito): modalità secca per PSP sandbox, stub portafoglio.

Filtri anti-frod/bot: whitelist test ASN/IP/device, altrimenti WAF/anti-bot «strangolerà» lo stand.

7) Piano di prova (modello di rilascio/promo)

1. Carico Smoke: 10-20% del picco, 30 min

2. Capacity ramp: x1 → target → x1. 5 dal picco di destinazione, a 10-15 minuti per stadio

3. Serie Burst: 3-5 onde a 60-120 s per x3-x5 dal livello attuale

4. Soak: 4-8 ore per 60-80% picco (perdita, degrado)

5. Failover/Chaos: disattivazione di un PSP/PoP, degrado del provider di giochi, caduta di un database

6. Tempesta WS: reconnect di massa + 5-10 x messaggi per 2-3 minuti

7. Promo-tempesta : /promo/claim + registrazione + deposito in 60 secondi «finestra»

Criteri di uscita: tutte le SLO nella zona verde; headroom 30% per CPU/connettori; Quote PSP non superate Nessuna fila e p99 dopo il test.

8) Pattern di infrastruttura per resistere ai picchi

Warm-pool/probioned concertency (funzioni/contenitori), pre-scale prima del promo.

Connection pooling e limiti upstream (DB/PSP) + code di query.

Idempotency keys per depositi/webhook.

Backpressure: 429/503 con'Retry-After ', degrado delle rotaie «pesanti» (reperti/ricerca).

Cache/edge-cache di coefficienti e metadati statici dei giochi.

9) Anti-regress: cosa si rompe prima di tutto

Pool DB sovraccarichi di p99 e timeout

Wallet-locking per gli update di massa dell'equilibrio

PSP-rate limits valanga di retrai e riprese
WS-broadcast per migliaia di iscrizioni senza batching
Regole WAF troppo aggressive su FPR su login/deposito

10) Osservazione durante il test

Dashboard RED/USE + vortici aziendali (login→depozit→stavka→vyvod).

Trailer end-to-end per query lente/errate (100% sample errori).

Marcatori di fase di prova (ramp/burst) in metriche/logi.

Singoli pannelli PSP/provider di giochi, coda di retrai, hit idempotency.

11) Comando e processo

War-room: ingegnere perfomance, backend, SRE, rischio/pagamento, WAF/sicurezza, prodotto.

Runbook: cosa facciamo a p99> target, come abbassare il carico di lavoro, chi chiamare dal provider.

Rapporto SLO, larghezza di banda, colli di bottiglia, costo, linee guida codice/architettura/quote.

12) Piano Capasiti: da numero di giocatori a RPS

Valutazione (esempio):

Giocatori simultanei a picco: 50k
Frequenza media delle azioni: 0. 25–0. 5 req/s per giocatore (cellulare sotto, live sopra)
API RPS di valutazione: 12. 5k-25k + richieste di assistenza (portafogli, provider, cache)
WS: 30-60k connettori attivi, 3-8 msg/s sul tavolo/tema
Aggiungi 30-50% headroom su burst e retrai

13) Assegno-foglia di preparazione dello stand

Dati: account/portafogli/carte/valute/paesi/giochi, alias
Isolamento dei pagamenti: sandbox + blocchi di webhoop, divieto di cancellazioni «live»
Edge/CDN/WAF come in vendita; antibot in modalità «morbida» per i test ASN
Osservabilità: dashboard, alert, traccia inclusa
Scale automatico e warm-pool configurati limiti dei pool/connettori documentati
Bandiera canaria per i «pesi pesanti» (reperti, esportazioni di massa)

14) Strumenti (punti di riferimento)

Generatori: k6, Gatling, Locust (HTTP/WS), JMeter (incluso plugin)

Gli emulatori FID sono gli script a casta delle quote/provider di giochi

Mirroring tcpreplay/ingress con anonimizzazione e normalizzazione

15) Esempio di profilo «Torneo promozionale, 60 secondi prima dell'inizio» (valigetta)

Onda - 5 min 0:

Open arrivals: 400 → 2.500 req/s (login/refresh)
'/promo/claim ': bursts da 1.000 rps 3 x a 20 c
WS: + 15k connect, + 5 msg/s su «leader»

Pronto:

Preimpostazione cache e warm-pool
Rate-limit '/promo/claim ': 10/min IP, 2/min account, 30 secondi cache di risposte negative
Idampotenza e coda bonus (batch 50-100/tac)
«Soft» 429 con'Retry-After' + progresso UI

Criteri di successo: nessun degrado SLO login/deposito, p95 WS <150 ms, <0. 5% di errori claim, nessun gonfiore delle code.

Curriculum

Il test di carico del iGaming è una simulazione comportamentale, non un tiro all'endpoint. Prima definisci SLO e i profili dei giocatori, poi scegli un modello di traffico (open/closed), costruisci scenari reali di login/deposito/scommesse/promo con geo e limiti PSP, prova bursts e soak, abilita l'osservazione e prepara un autoscale. Fissare il risultato con un piano di capasiti e runbook - in modo da incontrare picchi di traffico senza sorprese o perdite di conversione.