Версия документа: 2026-05-29 · Цель: текущий single-VPS должен держать до 100k MAU без падений, плюс приложение должно бесшовно переехать на CDN когда понадобится.
| Метрика | Значение | Откуда |
|---|---|---|
| MAU | 100,000 | цель |
| DAU | 30,000 | 30% от MAU (нормально для утилитарного приложения) |
| Concurrent WS | 10,000 (пик 15k) | ~10% MAU днём, 15% в час-пик |
| Действий/день | 90,000 | 3 открытия/звонка на DAU |
| HTTP API req/сек (среднее) | 3-5 | в основном key_create, host_sync, crash_report |
| HTTP API req/сек (пик) | 30-50 | после массового релиза с обновлением номеров |
count=1 — один PHP-процесс держит ВСЕ WS-коннекты в массивах $hosts, $guests, $calls in-memory.Файл: HostService.kt:1424-1432. Сейчас syncPendingHostKeys() зовётся каждые 60с и дёргает Api.keyCreate для каждого pending ключа без backoff.
Хранить в Prefs per-localId: attempt_at_id и attempt_count_id. Backoff: 30с → 60с → 2м → 5м → 15м → 30м (cap). Сброс при success.
Файл: Vault.kt:213. Аналогичная логика.
Файл: GuestConn.kt (5+ мест). Сравнить новый parseNumbers с предыдущим (по hash или прямое сравнение). Если идентично — не бампать AppState.overridesVersion. Снижает recompose-волны (80 SP-чтений × 20 карточек) с каждой WS-инициализации.
В server.php case 'host_hello' / 'guest_hello': если тот же device_id / user_key дёргал hello менее N секунд назад — закрыть соединение без DB-запросов. N=5с.
Защита от того, что клиент с битой логикой шлёт hello 100/сек.
В enqueueHostMsg: если для данного host_id уже > 200 строк — дропнуть старейшую через DELETE FROM pending_host_msgs WHERE host_id=? ORDER BY id ASC LIMIT 1. Защита от бесконечного роста при злонамеренной активности.
В _config.php:
$GLOBALS['apk_url'] = 'https://entrixy.com/entrixy.apk';
$GLOBALS['download_page_url'] = 'https://entrixy.com/download';В api/version_check.php: 'download_url' => $GLOBALS['apk_url'].
В момент миграции на CDN — меняешь ровно одну строку в _config.php на https://apk.entrixy.com/entrixy.apk (Cloudflare R2 + custom domain). Никаких релизов приложения.
Клиент при загрузке APK уже верифицирует подпись APK (debug keystore, см. build.gradle.kts:23-29). Этого достаточно для CDN — даже если CDN-узел подменит файл, подпись не совпадёт и Android откажет в установке. Доп.работа на клиенте не нужна.
count=1 Workerman держит ~10k concurrent WS без проблем (proof: server.php line 40 уже стартует с этим). Узким горлом сначала станет PHP CPU при пиковом обмене сообщений (10k pong/сек + действия).
Сейчас $hosts, $guests, $calls — in-memory массивы в одном процессе. Чтобы запустить несколько процессов, надо вынести в Redis:
Когда message приходит на воркер W1, а получатель сидит на W2 — пересылаем через Redis pub/sub.
Эффект: линейный scale-out до количества ядер VPS. На 4-ядерном = до ~40k concurrent.
Менее гибкий вариант, не требует Redis. Каждый юзер всегда попадает в один и тот же воркер. Но не работает если получатель и отправитель оказались на разных воркерах.
entrixy.apk.apk.entrixy.com → подключить через Cloudflare CDN._config.php поменять $apk_url на новый.assembleRelease добавить r2 cp app-release.apk apk-bucket/entrixy.apk.