Пропускная способность сервера

Обновление от 2026-05-30 · После раскатки фиксов 6.61-6.64.

Главное: pre-production, легаси нет

Реальных юзеров в проде ещё нет. Все установки — наши тестовые. Соответственно:

$MIN в version_check.php теперь равен $CURRENT (=6.66). Любая старая версия форсится на свежую.
«Естественная миграция через update prompt» как стратегия раскатки — для прода. Сейчас раскатка = бамп $MIN.
Никаких backwards-compat слоёв «на случай если у юзера старый клиент» — такого юзера нет.

Оценка по зонам нагрузки

Аудитория MAU	Concurrent WS (пик)	Состояние одного VPS	Главное узкое место
≤ 30k	≤ 3k	Запас 10×, idle	Ничто из нашего стека
30k — 100k	3k — 10k	Целевая зона, работает комфортно	Workerman CPU держит pong+events легко. БД на PK-lookup'ах. RAM 500MB-1GB на сокеты.
100k — 200k	10k — 20k	Работает с напрягом	Workerman single-process греется в час-пик. Если повылазит баг с WS-флапом — деградация.
> 200k	> 20k	Упрёмся	Нужна фаза C (Workerman count=4 + Redis pub/sub для shared `$hosts`/`$guests`).

Что починили в 6.61-6.64

Метрика	До фиксов	После 6.64	Где сделано
`ble_token_renew` в очереди при оффлайне хозяина	1300/4ч	1 (UNIQUE INDEX dedup)	Сервер — работает для любого клиента
HTTP retry при сетевом сбое	5 keys × 1/мин = 7200/день	~50/день (backoff 30мин)	Клиент 6.64 — нужен новый APK
WS-реконнект при флапе сети	~10/мин (1с retry)	~1/мин (60с backoff)	Клиент 6.62+ — нужен новый APK
DB hello-lookups при WS-флапе	~50/сек на 10k клиентов	~5/сек	Сервер — rate-limit 5с защищает от любых клиентов
Failed fire-events в Prefs гостя	60+/день на гостя с истёкшим токеном	0	Клиент 6.63
Recompose-волны при guest_ok	каждый numbers_update	только при реальном изменении	Клиент 6.64

Что работает СРАЗУ для всех клиентов (серверные фиксы)

Серверные защиты опираются на онмессадж-логику — отрабатывают независимо от того, какая версия клиента шлёт данные.

INSERT IGNORE dedup в enqueueHostMsg — даже если клиент 6.55 шлёт 1300 одинаковых renew, в очередь попадёт 1.
Rate-limit 5с на host_hello/guest_hello — даже если клиент 6.55 пытается реконнектиться каждую секунду, второй hello подряд закроется без БД-запроса.
Cap pending_host_msgs = 500 на host_id — страховка от роста очереди при любом источнике.
CDN-ready: $GLOBALS['apk_url'] в _config.php — миграция на R2/CDN меняется одной строкой, никаких релизов приложения.

Что работает только после апдейта клиента

WS-backoff 60с-стабильность (6.62) — снижает реконнект-шторм с клиента в 10×.
HTTP retry exponential backoff 30с→30мин (6.64) — снижает retry-нагрузку в 30×.
compare-before-bump для overridesVersion (6.64) — экономит локальный CPU/батарею, косвенно снижает Doze-реконнекты.
Гостевой UI «токен истёк = offline» (6.63) — выпиливает failed-events.

Решение: поднял $MIN = '6.66'. Любой старый клиент при первом versionCheck получит блокирующий диалог «Обновите приложение» (UI уже есть, см. App.kt:checkVersionAsync).

Workerman scale-out — когда понадобится

Сейчас count=1 — один PHP-процесс держит ВСЕ WS в массивах $hosts/$guests/$calls in-memory.

Конкретные пороги:

10k concurrent — comfortable, headroom есть.
15k concurrent — стабильно, но в час-пик можно зацепить таймауты.
20k concurrent — критическая точка. Один Doze-выход 20k клиентов = очередь evенов на ~500 секунд = таймауты, шторм.

Что делать при приближении к 15k:

Поставить Redis на VPS (apt install redis-server).
Workerman count=4 (по числу ядер VPS).
Вынести $hosts/$guests/$calls в Redis HASH с TTL.
Pub/sub между воркерами: когда сообщение пришло на W1, а получатель сидит на W2 — пересылаем через канал.

Эффект: линейный scale до 4×, потолок поднимается до ~40-60k concurrent.

CDN-миграция — когда понадобится

Сейчас APK 22 МБ × N юзеров идёт с твоего VPS. На 100k юзеров при релизе = 2.2 ТБ outbound. Своего канала может не хватить или будет дорого.

Подготовлено в 6.64:

$GLOBALS['apk_url'] в _config.php — один источник правды для URL.
download.php и version_check.php читают оттуда.
Подпись APK уже валидируется Android'ом — CDN-MITM не пройдёт.

Когда понадобится переезд:

Cloudflare R2 bucket → залить entrixy.apk.
Custom domain apk.entrixy.com через Cloudflare CDN.
В _config.php: $GLOBALS['apk_url'] = 'https://apk.entrixy.com/entrixy.apk';
В deploy-скрипте после assembleRelease добавить r2 cp app-release.apk apk-bucket/entrixy.apk.

На текущем масштабе (десятки тестеров) — не надо.

Стек действий: что сейчас на сервере и в приложении

Чтобы все фиксы заработали:

На сервере: sudo supervisorctl restart dialer-ws (от твоего sudo).
Юзеры с любой версией ниже 6.66 при следующем запуске получат force-update диалог и пойдут качать.
После раскатки клиентов 6.66 — нагрузка от штормов реконнектов и retry'ев упадёт на порядок.