Крипто-казино
Torrent Gear
Навантажувальне тестування: профілі гравців і піки трафіку
1) Навіщо моделювати профілі, а не «середню температуру»
У iGaming-навантаження висока вибуховість: промо/турніри/стріми дають кратні сплески RPS, а розподіл дій нерівномірно (login→depozit→stavki/vyvod). Тест повинен відображати поведінку сегментів (новачки, VIP, «бонус-хантери», мобільні), інакше ви отримаєте «зелені графіки» і червоні інциденти.
Ключові SLO (приклад на 30 днів):- Логін: успішність ≥ 99. 9%, p95 ≤ 250 мс
- Депозит: успішність ≥ 99. 85%, p95 ≤ 400 мс
- Ставка (WS): p95 message RTT ≤ 120 мс, disconnect rate ≤ 0. 5%
- Запуск гри: успішність ≥ 99. 8%, p95 ≤ 800 мс
2) Профілі гравців (поведінкові сценарії)
A. Newbie (новий гравець) - 25-40% пікового трафіку
Шлях: реєстрація → логін → перегляд промо → депозит (малі суми) → запуск 1-2 слотів
Особливості: висока частка помилок UX, ретраї платежів, стрибки між сторінками
B. regular (поворотний) - 40-50%
Шлях: логін → швидкий депозит/без депозиту → 3-5 ігор → рідкісний висновок
Особливості: стабільні сесії, чутливий до p95> 200 мс на WS
C. bonus-hunter (промо) - 10-20% при акціях
Шлях: реєстрація → активація бонусу → мінімальні ставки → спроба швидкого виведення
Особливості: сплески до '/promo/claim', зловживання ретраями, часті 429 без правильних лімітів
D. high-roller/VIP - ≤ 1%, але високий чек
Шлях: логін → великий депозит → лайв-ігри/високі ставки → висновок
Особливості: чутливий до будь-якої затримки/фейлів провайдера ігор, критичний SLA платіжок
E. bettor (спорт/лайв)- Шлях: логін → підписка на котирування → часті ставки у «вузьких вікнах» (до 10-30 с)
- Особливості: пульсуюче навантаження на WS/кеш коефіцієнтів, сплески при голах/VAR
3) Моделі трафіку і таймінг
Open vs Closed model
Open (Poisson, arrivals/sec) - підходить для публічних промо і стрімів (користувачі «приходять самі»).
Closed (фікс. число віртуальних користувачів з think-time) - для стабільних сесій (VIP, лайв-ігри).
Трафік-патерни:- Ramp: лінійний розгін x1 → x5 за 10-20 хв
- Burst: «вибух» x3-x10 на 30-120 с (анонс бонусу/джекпоту/гол)
- Wave: гребені кожні 5-10 хв (стрім/турнірні раунди)
- Soak: 2-12 год стабільного навантаження (витоки, GC, дескриптори, деградації)
4) Критичні флоу і метрики
Автентифікація та профіль
RPS на '/login', '/2fa/verify', p95/p99, error-rate, lock/ratelimit-спрацювання
Платежі
Ігрові гейти
Запуск слота/лайв-столу: success-ratio, time-to-first-spin, відмова провайдера
WebSocket: з'єднань в піку, повідомлення/сек, RTT, rate-limit/429, reconnects/min
Промо/бонуси
`/promo/claim`, `/freespin/activate`: 200/4xx/5xx, частка 409/конкурентні апдейти, каскади на гаманець
Сховища та черги
Saturation: CPU, DB-connections, pool-timeouts, queue lag, GC pauses
5) Гео і реальність мережі
Георозподіл по ринках (EU/LatAm/MEA/APAC) і ASN-мікс (мобільні мережі, хостинги).
Латентність edge→origin (Anycast/CDN), mobile RTT, пакетні втрати.
A/B: з CDN і в обхід (origin) - для оцінки «чистого» бекенду.
6) Дизайн тестових даних
Псевдонімізовані акаунти, BIN-карти по регіонах, валюти, KYC-стану.
Реалістичні поведінкові таймінги: think-time 1-7 с для casual, 0. 3–1. 2 с для live-ставок.
Контроль неідемпотентних операцій (виведення/депозит): сухий режим для PSP sandbox, заглушки гаманця.
Анти-фрод/бот-фільтри: whitelist тестових ASN/IP/девайсів, інакше WAF/anti-bot «задушить» стенд.
7) План тестів (шаблон на реліз/промо)
1. Smoke-навантаження: 10-20% від піку, 30 хв
2. Capacity ramp: x1 → target → x1. 5 від цільового піку, по 10-15 хв на щабель
3. Burst-серії: 3-5 хвиль по 60-120 с на x3-x5 від поточного рівня
4. Soak: 4-8 год на 60-80% піку (витоку, деградації)
5. Failover/Chaos: відключення одного PSP/PoP, деградація провайдера ігор, падіння одного shard БД
6. WS-шторм: масові reconnect + 5-10 × повідомлень протягом 2-3 хв
7. Promo-шторм: / promo/claim + реєстрація + депозит в 60-сек «вікні»
Критерії виходу: всі SLO в зеленій зоні; headroom ≥ 30% по CPU/коннектам; PSP-квоти не перевищені; немає зростання черг і p99 після тесту.
8) Інфраструктурні патерни для витримування піків
Warm-pool/provisioned concurrency (функції/контейнери), pre-scale перед промо.
Connection pooling і ліміти на upstream (DB/PSP) + черги запитів.
Idempotency keys на депозити/вебхуки.
Backpressure: 429/503 з'Retry-After', деградація «важких» рутів (репорти/пошук).
Кеш/edge-кеш коефіцієнтів і статик-метаданих ігор.
9) Анти-регрес: що «ламається» в першу чергу
Переповнені DB-пули → ріст p99 і тайм-аути
Wallet-locking при масових апдейтах балансу- PSP-rate limits → лавина ретраїв і дублів
- WS-broadcast на тисячі підписок без батчингу
- Занадто агресивні WAF-правила → FPR на логіні/депозиті
10) Спостережуваність під час тесту
Дашборди RED/USE + бізнес-воронки (login→depozit→stavka→vyvod).
Трейси end-to-end для «повільних «/помилкових запитів (100% sample помилок).
Маркери етапів тесту (ramp/burst) в метриках/логах.
Окремі панелі PSP/провайдерів ігор, черга ретраїв, idempotency-хіти.
11) Команда і процес
War-room: перфоманс-інженер, бекенд, SRE, ризик/платежі, WAF/безпека, продукт.
Runbook: що робимо при р99> цільового, як знижуємо навантаження, кого кликати у провайдера.
Звіт: SLO, пропускна здатність, вузькі місця, вартість, рекомендації по коду/архітектурі/квотам.
12) Капасіті-план: від числа гравців до RPS
Оцінка (приклад):- Одночасні гравці в піку: 50k
- Середня частота дій: 0. 25–0. 5 req/s на гравця (мобільний нижче, live вище)
- Оціночний API RPS: 12. 5k-25k + сервісні запити (гаманець, провайдери, кеш)
- WS: 30-60k активних конектів, 3-8 msg/s на стіл/тему
- Додайте 30-50% headroom на burst і ретраї
13) Чек-лист підготовки стенду
- Дані: акаунти/гаманці/картки/валюти/країни/ігри, псевдонімізовані
- Ізоляція платіжок: sandbox + заглушки вебхуків, заборона «живих» списань
- Edge/CDN/WAF як в проді; антибот в «м'якому» режимі для тестових ASN
- Спостережуваність: дашборди, алерти, трасування включені
- Автоскейл і warm-pool налаштовані; ліміти пулів/конектів задокументовані
Канарський прапор для «важких» фіч (репорти, масові експорти)
14) Інструменти (орієнтири)
Генератори: k6, Gatling, Locust (HTTP/WS), JMeter (в т.ч. WebSocket плагін)
Фід-емулятори: кастомні скрипти котирувань/провайдерів ігор
Трафік-реплей: tcpreplay/ingress-дзеркалювання з анонімізацією та нормалізацією
15) Приклад профілю «Промо-турнір, 60 секунд до старту» (кейс)
Хвиля −5 хв → 0:- Open arrivals: 400 → 2 500 req/s (логін/refresh)
- `/promo/claim`: bursts по 1 000 rps 3 × по 20 с
- WS: + 15k connect, + 5 msg/s на тему «leaderboard»
- Передпрогрів кеша і warm-pool
- Rate-limit `/promo/claim`: 10/min IP, 2/min аккаунт, 30-сек кеш негативних відповідей
- Ідемпотентність і черга бонусних нарахувань (batch 50-100/такт)
- «М'який» 429 з'Retry-After'+ UI-прогрес
Критерії успіху: немає деградації SLO логіну/депозиту, p95 WS <150 мс, <0. 5% помилок claim, відсутність роздування черг.
Резюме
Навантажувальне тестування iGaming - це поведінкове моделювання, а не «стрільба по ендпойнту». Спочатку визначте SLO і профілі гравців, потім вибирайте модель трафіку (open/closed), будуйте реальні сценарії логіна/депозиту/ставок/промо з гео і лімітами PSP, тестуйте bursts і soak, включайте спостережуваність і готуйте автоскейл. Закріплюйте результат капасіті-планом і runbook'ами - так ви зустрінете піки трафіку без сюрпризів і втрат конверсії.