Server capacity

Updated 2026-05-30 · after the 6.61–6.64 fixes were rolled out.

The main point: pre-production, no legacy

There are no real users on the production server yet. Every installation is a test one. Hence:

$MIN in version_check.php now equals $CURRENT (=6.66). Any older version is forced up to the current one.
"Natural migration through the update dialog" is a strategy for production. For now a rollout simply means raising $MIN.
Backward compatibility layers "in case of an old client" are unnecessary — there is no such client.

Estimates by load band

Audience, MAU	Concurrent WS (peak)	State of a single VPS	Main bottleneck
≤ 30k	≤ 3k	10× headroom, idle	Nothing in our stack
30k — 100k	3k — 10k	The target band, comfortable	Workerman's CPU handles pongs and events easily. The database works on primary-key lookups. 500 MB–1 GB of RAM for the sockets.
100k — 200k	10k — 20k	Running at the limit	The single Workerman process overheats at peak. Let a bug with dropped WebSockets surface and degradation begins.
> 200k	> 20k	We hit the ceiling	Phase C is needed (Workerman count=4 plus Redis pub/sub for shared `$hosts`/`$guests`).

What was fixed in 6.61–6.64

Metric	Before the fixes	After 6.64	Where it was done
`ble_token_renew` queued while the owner is offline	1300 per 4 h	1 (UNIQUE INDEX dedup)	Server — works with any client
HTTP retries on a network failure	5 keys × 1/min = 7200 a day	~50 a day (30-minute backoff)	Client 6.64 — a new APK is required
WebSocket reconnects on a flapping network	~10/min (1 s retry)	~1/min (60 s backoff)	Client 6.62+ — a new APK is required
Database hello lookups during WebSocket flapping	~50/s across 10k clients	~5/s	Server — the 5-second rate limit protects against any client
Failed fire events in a guest's Prefs	60+ a day per guest with an expired token	0	Client 6.63
Recompose waves on guest_ok	on every numbers_update	only on a real change	Client 6.64

What works immediately for every client (server-side fixes)

The server-side protections live in the handling of incoming messages — they apply regardless of the client version.

INSERT IGNORE dedup in enqueueHostMsg — even if a 6.55 client sends 1300 identical renews, only one lands in the queue.
A 5-second rate limit on host_hello and guest_hello — even if a 6.55 client reconnects every second, the second hello in a row is closed without touching the database.
Cap pending_host_msgs = 500 per host_id — insurance against the queue growing, whatever the source.
CDN-ready: $GLOBALS['apk_url'] in _config.php — moving to R2 or a CDN is a one-line change, with no app release.

What only works after the client updates

The 60-second WebSocket backoff for stability (6.62) cuts the client's reconnect storm tenfold.
Exponential HTTP retry backoff, 30 s → 30 min (6.64), cuts retry load thirtyfold.
Compare-before-bump for overridesVersion (6.64) saves local CPU and battery, and indirectly reduces Doze reconnects.
The guest interface shows an expired token as offline (6.63), so failed events no longer occur.

Decision: raised $MIN = '6.66'. Any old client, on its first versionCheck gets a blocking "Update the app" dialog (the UI already exists, see App.kt:checkVersionAsync).

Scaling Workerman out — when it becomes necessary

Right now count=1 — a single PHP process holds ALL the WebSockets in the arrays $hosts/$guests/$calls in-memory.

The concrete thresholds:

10 thousand concurrent connections — comfortable, with headroom.
15k concurrent — stable, but timeouts can be caught at peak.
20k concurrent — the critical point. One Doze exit by 20k clients means an event queue about 500 seconds long: timeouts and a storm.

What to do as 15k approaches:

Install Redis on the VPS (apt install redis-server).
Workerman count=4 (matching the VPS core count).
Move $hosts/$guests/$calls into a Redis HASH with a TTL.
Pub/sub between workers: when a message arrives at W1 but the recipient sits on W2, relay it through the channel.

Effect: linear scaling up to 4×, raising the ceiling to roughly 40–60k concurrent.

Moving to a CDN — when it becomes necessary

Today the 22 MB APK is served from our own VPS to every user. At 100 thousand that is 2.2 TB of outbound traffic per release — our own link may not cope, or may prove expensive.

Prepared in 6.64:

$GLOBALS['apk_url'] in _config.php — a single source of truth for the URL.
download.php and version_check.php read it from there.
Android verifies the APK signature itself, so substitution at the CDN will not pass.

When the move becomes necessary:

A Cloudflare R2 bucket → upload entrixy.apk.
Custom domain apk.entrixy.com through the Cloudflare CDN.
In _config.php: $GLOBALS['apk_url'] = 'https://apk.entrixy.com/entrixy.apk';
In the deploy script, after assembleRelease add r2 cp app-release.apk apk-bucket/entrixy.apk.

At the present scale — dozens of test installations — no move is needed.

The action list: what is on the server and in the app now

To get every fix working:

On the server: sudo supervisorctl restart dialer-ws.
Any version below 6.66 gets a mandatory update dialog on its next launch.
Once 6.66 is rolled out, load from reconnect storms and retries drops by an order of magnitude.