Tests de charge : profils de joueurs et pics de trafic

1) Pourquoi simuler les profils plutôt que la « température moyenne »

La charge de travail iGaming est très explosive : les promotions/tournois/strim donnent des multiples des surtensions RPS, et la répartition des actions est inégale (login→depozit→stavki/vyvod). Le test doit refléter le comportement des segments (débutants, VIP, « bonus-hunters », mobiles), sinon vous recevrez des « graphiques verts » et des incidents rouges.

SLO clés (exemple de 30 jours) :

Login : succès ≥ 99. 9 %, p95 ≤ 250 ms
Dépôt : succès ≥ 99. 85 %, p95 ≤ 400 ms
Taux (WS) : p95 message RTT ≤ 120 ms, taux disconnect ≤ 0. 5%
Lancement du jeu : succès ≥ 99. 8 %, p95 ≤ 800 ms

2) Profils des joueurs (scénarios comportementaux)

A. Newbie (nouveau joueur) - 25-40 % du trafic de pointe

Chemin : S'inscrire → login → voir promo → dépôt (petits montants) → lancer 1-2 slots

Caractéristiques : forte proportion d'erreurs UX, retraits de paiement, sauts entre les pages

B. Regular (remboursable) - 40-50 %

Chemin : login → dépôt rapide/pas de dépôt → 3-5 jeux → retrait rare

Caractéristiques : sessions stables, sensible à p95> 200 ms sur WS

C. Bonus-hunter (promo) - 10-20 % dans les actions

Chemin : inscription → activation du bonus → des paris minimaux → tentative de sortie rapide

Caractéristiques : surtensions vers '/promo/claim ', abus de retraits, fréquents 429 sans limites appropriées

D. High-roller/VIP - ≤ 1 %, mais un chèque élevé

Chemin : login → dépôt important → jeux de vie/paris élevés → retrait

Caractéristiques : Sensible à tout retard/faux fournisseur de jeux, critique de paiement SLA

E. Bettor (sport/vie)

Chemin : login → abonnement aux devis → taux fréquents dans les « fenêtres étroites » (jusqu'à 10-30 s)
Caractéristiques : charge pulsative sur WS/cache de coefficients, surtensions aux buts/VAR

3) Modèles de trafic et de temporisation

Open vs Closed model

Open (Poisson, arrivals/sec) - convient pour les promos publiques et les strims (les utilisateurs « viennent d'eux-mêmes »).

Closed (fix. nombre d'utilisateurs virtuels avec think-time) - pour les sessions stables (VIP, jeux lives).

Traffic-patterns :

Ramp : accélération linéaire x1 → x5 en 10-20 min
Burst : « explosion » x3-x10 à 30-120 s (annonce de bonus/jackpot/but)
Wave : peignes toutes les 5-10 min (stream/tournois)
Soak : 2-12 h de charge stable (fuites, GC, descripteurs, dégradations)

4) Flocons et métriques critiques

Authentification et profil

RPS sur '/login ', '/2fa/verify', p95/p99, error-rate, lock/ratelimit-bass

Paiements

`/payments/deposit	withdraw 'par fournisseurs : success-ratio, p95/p99, saucisses, idempotence
Limites PSP (per-merchant RPS/transactions par minute), file de retraits

Jeux Gates

Lancement de la fente/de la table live : success-ratio, time-to-first-spin, défaillance du fournisseur

WebSocket : connexions en pic, messages/sec, RTT, rate-limit/429, reconnects/min

Promotions/bonus

'/promo/claim ', '/freespin/activate' : 200/4xx/5xx, part 409/updates compétitives, cascades par portefeuille

Stockage et files d'attente

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

5) Géo et la réalité du réseau

Géo-distribution par marché (EU/LatAm/MEA/APAC) et mélange ASN (réseaux mobiles, hébergements).

Latence edge→origin (Anycast/CDN), RTT mobile, pertes par lots.

A/B : avec CDN et contournement (origin) - pour évaluer le backend « propre ».

6) Conception des données de test

Comptes pseudonymes, cartes BIN par région, devises, états KYC.

Temps de comportement réaliste : think-time 1-7 avec pour casual, 0. 3–1. 2 s pour les paris en direct.

Contrôle des opérations non-ponctuelles (retrait/dépôt) : mode sec pour la sandbox PSP, bouchons porte-monnaie.

Filtres anti-frod/bot : whitelist test ASN/IP/devis, sinon WAF/anti-bot « étouffera » le stand.

7) Plan de test (modèle de sortie/promo)

1. Charge de smoke : 10-20 % du pic, 30 min

2. Capacity ramp: x1 → target → x1. 5 du pic cible, 10-15 min par marche

3. Série Burst : 3-5 vagues de 60-120 s par x3-x5 du niveau actuel

4. Soak : 4-8 h pour un pic de 60-80 % (fuites, dégradations)

5. Failover/Chaos : Désactivation d'une seule PSP/PoP, dégradation du fournisseur de jeux, chute d'une seule base de données shard

6. Tempête WS : reconnaissance massive + 5-10 messages × pendant 2-3 min

7. Promo-tempête : /promo/claim + enregistrement + dépôt dans la « fenêtre » de 60 secondes

Critères de sortie : tous les SLO dans la zone verte ; headroom ≥ 30 % pour les CPU/connexions ; les quotas PSP ne sont pas dépassés ; pas de croissance des files d'attente et p99 après le test.

8) Modèles d'infrastructure pour résister aux pics

Compétition Warm-pool/provisioned (fonctions/conteneurs), pré-scale avant promo.

Connection pooling et limites sur upstream (DB/PSP) + queues d'interrogation.

Clés idempotentielles pour les dépôts/webhooks.

Backpressure : 429/503 avec « Retry-After », dégradation des ruches « lourdes » (retour/recherche).

Cache/edge-cache des coefficients et des métadonnées statiques des jeux.

9) Anti-régression : ce qui « casse » avant tout

Pools DB surpeuplés → croissance p99 et temporisation

Wallet-locking en cas de surtensions massives

Limites de taux PSP → avalanche de retraits et de prises
WS-broadcast pour des milliers d'abonnements sans batching
Règles WAF trop agressives → FPR sur login/dépôt

10) Observabilité pendant le test

Dashboards RED/USE + entonnoir d'affaires (login→depozit→stavka→vyvod).

Traces end-to-end pour les requêtes « lentes « /erronées (100 % d'erreurs sample).

Marqueurs d'étapes de test (ramp/burst) en métriques/logs.

Panneaux individuels PSP/fournisseurs de jeux, file de retraits, hits d'idempotency.

11) Équipe et processus

Salle de guerre : ingénieur de performance, backend, SRE, risque/paiement, WAF/sécurité, produit.

Runbook : ce que nous faisons avec p99> cible, comment réduire la charge de travail, qui appeler chez le fournisseur.

Rapport : SLO, bande passante, goulets d'étranglement, coût, recommandations de code/architecture/quotas.

12) Plan capacitif : du nombre de joueurs au RPS

Évaluation (exemple) :

Joueurs simultanés au sommet : 50k
Taux moyen d'action : 0. 25–0. 5 req/s par joueur (mobile ci-dessous, live ci-dessus)
Évaluation de l'API RPS : 12. 5k-25k + demandes de service (portefeuille, fournisseurs, cache)
WS : 30-60k connexions actives, 3-8 msg/s par table/thème
Ajouter 30-50 % headroom sur burst et retrai

13) Chèque de préparation du stand

Données : comptes/portefeuilles/cartes/devises/pays/jeux, pseudonymes
Isolement des paiements : sandbox + bouchons de webhooks, interdiction des prélèvements « en direct »
Edge/CDN/WAF comme dans la vente ; antibot en mode « soft » pour les tests ASN
Observabilité : Dashboards, alertes, tracing inclus
Auto Skale et warm-pool configurés ; limites des pools/connexions documentées
Drapeau canarien pour les fiches « lourdes » (reports, exportations massives)

14) Outils (repères)

Générateurs : k6, Gatling, Locust (HTTP/WS), JMeter (y compris le plugin WebSocket)

Feed-emulators : scripts personnalisés de citations/fournisseurs de jeux

Traffic-replay : tcpreplay/ingress-miroirs avec anonymisation et normalisation

15) Exemple de profil « Tournoi promotionnel, 60 secondes avant le début » (case)

Vague − 5 min → 0 :

Open arrivals : 400 → 2 500 req/s (login/refresh)
'/promo/claim' : bursts de 1 000 rps 3 × de 20 s
WS : + 15k connect, + 5 msg/s sur le thème « leadership »

Préparation :

Préchauffer le cache et warm-pool
Rate-limit '/promo/claim ': 10/min IP, compte 2/min, cache de réponses négatives de 30 secondes
Idempotentialité et queue de bonus (batch 50-100/tact)
« Soft » 429 avec « Retry-After » + UI-Progress

Critères de succès : pas de dégradation SLO login/dépôt, p95 WS <150 ms, <0. 5 % d'erreurs de claim, pas de gonflement des files d'attente.

Résumé

Les tests de charge iGaming sont des simulations comportementales, pas des « tirs d'endpoint ». Tout d'abord, identifiez les SLO et les profils des joueurs, puis choisissez le modèle de trafic (ouvert/fermé), construisez des scripts login/dépôt/paris/promo réels avec les limites geo et PSP, testez bursts et soak, incluez l'observabilité et préparez le skate automatique. Fixez le résultat avec le plan capasiti et runbook 'ami - de sorte que vous rencontrerez des pics de trafic sans surprises et pertes de conversion.