更新于 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 的 CPU 轻松应付 pong 与事件。数据库走主键查询。套接字占用 500 MB–1 GB 内存。 |
| 100k — 200k | 10k — 20k | 处在极限运行 | 单个 Workerman 进程在峰值时过热。一旦冒出 WebSocket 掉线的缺陷，性能就开始劣化。 |
| > 200k | > 20k | 触到天花板 | 需要进入 C 阶段（Workerman count=4，加上用于共享 $hosts/$guests). |
| Metric | 修复之前 | 6.64 之后 | 改在哪里 |
|---|---|---|---|
ble_token_renew 主人离线期间排队 |
4 小时 1300 次 | 1（靠 UNIQUE INDEX 去重） | Server ——对任何客户端都有效 |
| 网络故障时的 HTTP 重试 | 5 个密钥 × 每分钟 1 次 = 每天 7200 次 | 每天约 50 次（30 分钟退避） | 客户端 6.64 ——需要新的 APK |
| 网络抖动时的 WebSocket 重连 | 每分钟约 10 次（1 秒重试） | 每分钟约 1 次（60 秒退避） | 客户端 6.62+ ——需要新的 APK |
| WebSocket 抖动期间 hello 的数据库查询 | 1 万客户端下每秒约 50 次 | ~5/s | Server ——5 秒的频率限制可防住任何客户端 |
| 访客本地设置中的失败 fire 事件 | 每位持过期令牌的访客每天 60 次以上 | 0 | 客户端 6.63 |
| guest_ok 引发的重组浪潮 | 每次 numbers_update 都触发 | 仅在真正变化时 | 客户端 6.64 |
enqueueHostMsg ——即便 6.55 的客户端发来 1300 条相同的续期，队列里也只留一条。$GLOBALS['apk_url'] in _config.php ——迁到 R2 或 CDN 只需改一行，无需发布应用。决定：提高 $MIN = '6.66'。任何旧客户端在第一次 versionCheck 时收到阻断式的“请更新应用”对话框（界面已经存在，见 App.kt:checkVersionAsync).
就目前而言 count=1 ——单个 PHP 进程把全部 WebSocket 都放在数组里 $hosts/$guests/$calls in-memory.
具体阈值：
接近 1.5 万时该做什么：
apt install redis-server).count=4 （与 VPS 核心数一致）。$hosts/$guests/$calls 放进带 TTL 的 Redis HASH。Effect: 线性扩展至 4 倍，天花板抬到大约 4 万–6 万并发。
目前 22 MB 的 APK 由我们自己的 VPS 分发给每一位用户。到十万量级，每次发布就是 2.2 TB 出网流量——自家线路可能撑不住，或者代价高昂。
6.64 中已铺好的准备：
$GLOBALS['apk_url'] in _config.php ——地址的唯一真相来源。download.php 与 version_check.php 从那里读取。当确有必要迁移时：
entrixy.apk.apk.entrixy.com ，走 Cloudflare CDN。_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.