Ёмкость сервера

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

Главное: предпродакшен, никакого наследия

На боевом сервере пока нет настоящих пользователей. Все установки — тестовые. Отсюда:

$MIN in version_check.php теперь равен $CURRENT (=6.66). Любая версия старше принудительно поднимается до текущей.
Естественная миграция через диалог обновления — стратегия для продакшена. Пока раскатка означает просто поднять $MIN.
Слои обратной совместимости на случай старого клиента не нужны — такого клиента нет.

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

Аудитория, MAU	Одновременных WS (пик)	Состояние одного VPS	Главное узкое место
≤ 30k	≤ 3k	Десятикратный запас, простой	В нашем стеке ничего
30k — 100k	3k — 10k	Целевой диапазон, комфортно	Процессор Workerman легко справляется с понгами и событиями. База работает по первичным ключам. На сокеты уходит 500 МБ–1 ГБ памяти.
100k — 200k	10k — 20k	Работа на пределе	Единственный процесс Workerman перегревается на пике. Стоит вылезти багу с обрывами WebSocket — начинается деградация.
> 200k	> 20k	Упираемся в потолок	Нужна фаза C (Workerman count=4 плюс Redis pub/sub для общего `$hosts`/`$guests`).

Что исправлено в 6.61–6.64

Metric	До исправлений	После 6.64	Где сделано
`ble_token_renew` в очереди, пока владелец офлайн	1300 за 4 ч	1 (дедуп по UNIQUE INDEX)	Server — работает с любым клиентом
Повторы HTTP при сбое сети	5 ключей × 1/мин = 7200 в сутки	~50 в сутки (откат 30 минут)	Клиент 6.64 — нужен новый APK
Переподключения WebSocket при нестабильной сети	~10/мин (повтор через 1 с)	~1/мин (откат 60 с)	Клиент 6.62+ — нужен новый APK
Обращения к базе на hello при нестабильном WebSocket	~50/с на 10 тысячах клиентов	~5/s	Server — ограничение в 5 секунд защищает от любого клиента
Неудачные события fire в настройках гостя	60+ в сутки на гостя с просроченным токеном	0	Клиент 6.63
Волны перерисовки на guest_ok	на каждом numbers_update	только при реальном изменении	Клиент 6.64

Что работает сразу для всех клиентов (серверные исправления)

Серверные защиты живут в обработке входящих сообщений — они действуют независимо от версии клиента.

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

Что заработает только после обновления клиента

Откат WebSocket в 60 секунд ради устойчивости (6.62) сокращает шторм переподключений клиента вдесятеро.
Экспоненциальный откат повторов HTTP, 30 с → 30 мин (6.64), снижает нагрузку от повторов втридцатеро.
Сверка перед инкрементом overridesVersion (6.64) бережёт локальный процессор и батарею, а косвенно — сокращает переподключения после Doze.
Гостевой интерфейс показывает просроченный токен как офлайн (6.63), поэтому неудачных событий больше не возникает.

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

Масштабирование Workerman — когда понадобится

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

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

10 тысяч одновременных соединений — комфортно, с запасом.
15 тысяч одновременно — стабильно, но на пике можно словить тайм-ауты.
20 тысяч одновременно — критическая точка. Один выход из Doze у 20 тысяч клиентов даёт очередь событий примерно на 500 секунд: тайм-ауты и шторм.

Что делать по мере приближения к 15 тысячам:

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

Effect: линейное масштабирование до 4×, потолок поднимается примерно до 40–60 тысяч одновременно.

Переезд на CDN — когда понадобится

Сегодня APK на 22 МБ раздаётся каждому пользователю с нашего же VPS. На ста тысячах это 2,2 ТБ исходящего трафика за выпуск — свой канал может не потянуть или выйти дорого.

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

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

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

Бакет Cloudflare R2 → загрузить entrixy.apk.
Свой домен apk.entrixy.com через CDN Cloudflare.
In _config.php: $GLOBALS['apk_url'] = 'https://apk.entrixy.com/entrixy.apk';
В скрипте выкладки, после assembleRelease add r2 cp app-release.apk apk-bucket/entrixy.apk.

На нынешнем масштабе — десятки тестовых установок — переезд не нужен.

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

Чтобы заработали все исправления:

На сервере: sudo supervisorctl restart dialer-ws.
Любая версия ниже 6.66 получит обязательный диалог обновления при следующем запуске.
После раскатки 6.66 нагрузка от штормов переподключения и повторов падает на порядок.