Capacidade do servidor

Atualizado a 2026-05-30 · após a implantação das correções 6.61–6.64.

O principal: pré-produção, sem legado

No servidor de produção ainda não há utilizadores reais. Todas as instalações são de teste. Daí que:

$MIN in version_check.php é agora igual a $CURRENT (=6.66). Qualquer versão anterior é forçada para a atual.
A migração natural pelo diálogo de atualização é uma estratégia para produção. Por agora implantar significa apenas subir $MIN.
As camadas de retrocompatibilidade para o caso de um cliente antigo são desnecessárias — esse cliente não existe.

Estimativas por faixa de carga

Audiência, MAU	WS simultâneos (pico)	Estado de um único VPS	Principal estrangulamento
≤ 30k	≤ 3k	Dez vezes de margem, em repouso	Nada na nossa pilha
30k — 100k	3k — 10k	A faixa alvo, confortável	O processador do Workerman aguenta pongs e eventos sem esforço. A base trabalha por chave primária. 500 MB–1 GB de RAM para os sockets.
100k — 200k	10k — 20k	Trabalho no limite	O único processo do Workerman sobreaquece no pico. Basta surgir um erro com WebSockets caídos para começar a degradação.
> 200k	> 20k	Batemos no teto	É preciso a fase C (Workerman count=4 mais Redis pub/sub para um `$hosts`/`$guests`).

O que foi corrigido em 6.61–6.64

Metric	Antes das correções	Depois da 6.64	Onde foi feito
`ble_token_renew` em fila enquanto o proprietário está offline	1300 em 4 h	1 (deduplicação por UNIQUE INDEX)	Server — funciona com qualquer cliente
Repetições HTTP numa falha de rede	5 chaves × 1/min = 7200 por dia	~50 por dia (recuo de 30 minutos)	Cliente 6.64 — é preciso um APK novo
Reconexões de WebSocket numa rede instável	~10/min (repetição a 1 s)	~1/min (recuo de 60 s)	Cliente 6.62+ — é preciso um APK novo
Consultas à base no hello com WebSocket instável	~50/s em 10 mil clientes	~5/s	Server — o limite de 5 segundos protege de qualquer cliente
Eventos fire falhados nas preferências do convidado	mais de 60 por dia por convidado com token expirado	0	Cliente 6.63
Ondas de recomposição em guest_ok	em cada numbers_update	apenas numa alteração real	Cliente 6.64

O que funciona de imediato para todos os clientes (correções do servidor)

As proteções do servidor vivem no tratamento das mensagens recebidas — aplicam-se seja qual for a versão do cliente.

Deduplicação com INSERT IGNORE in enqueueHostMsg — mesmo que um cliente 6.55 envie 1300 renovações idênticas, só uma entra na fila.
Um limite de 5 segundos em host_hello e guest_hello — mesmo que um cliente 6.55 se reconecte a cada segundo, o segundo hello seguido é fechado sem tocar na base.
Limite pending_host_msgs = 500 por host_id — seguro contra o crescimento da fila, venha de onde vier.
CDN-ready: $GLOBALS['apk_url'] in _config.php — mudar para R2 ou para uma CDN é uma linha, sem lançar a aplicação.

O que só funciona depois de o cliente atualizar

O recuo de 60 segundos do WebSocket em prol da estabilidade (6.62) reduz dez vezes a tempestade de reconexões do cliente.
O recuo exponencial das repetições HTTP, 30 s → 30 min (6.64), reduz trinta vezes a carga de repetições.
Comparar antes de incrementar overridesVersion (6.64) poupa CPU local e bateria e, indiretamente, reduz as reconexões após o Doze.
A interface de convidado mostra um token expirado como offline (6.63), pelo que já não ocorrem eventos falhados.

Decisão: subido $MIN = '6.66'. Qualquer cliente antigo, no seu primeiro versionCheck recebe um diálogo bloqueante Atualize a aplicação (a interface já existe, ver App.kt:checkVersionAsync).

Escalar o Workerman — quando for preciso

Neste momento count=1 — um único processo PHP mantém TODOS os WebSockets nos vetores $hosts/$guests/$calls in-memory.

Os limiares concretos:

10 mil ligações simultâneas — confortável, com margem.
15 mil em simultâneo — estável, mas no pico podem surgir tempos-limite.
20 mil em simultâneo — o ponto crítico. Uma só saída do Doze em 20 mil clientes dá uma fila de eventos de cerca de 500 segundos: tempos-limite e tempestade.

O que fazer à medida que se aproximam 15 mil:

Instalar o Redis no VPS (apt install redis-server).
Workerman count=4 (conforme o número de núcleos do VPS).
Move $hosts/$guests/$calls para um HASH do Redis com TTL.
Pub/sub entre trabalhadores: se uma mensagem chega a W1 mas o destinatário está em W2, encaminha-se pelo canal.

Effect: escalonamento linear até 4×, subindo o teto para cerca de 40–60 mil em simultâneo.

Mudar para uma CDN — quando for preciso

Hoje o APK de 22 MB é servido a cada utilizador a partir do nosso próprio VPS. Com cem mil, isso são 2,2 TB de tráfego de saída por versão — a nossa ligação pode não aguentar ou sair cara.

Preparado na 6.64:

$GLOBALS['apk_url'] in _config.php — uma única fonte de verdade para o endereço.
download.php e version_check.php leem-no de lá.
O Android verifica por si a assinatura do APK, por isso uma substituição na CDN não passa.

Quando a mudança for precisa:

Um bucket Cloudflare R2 → carregar entrixy.apk.
Domínio próprio apk.entrixy.com através da CDN da Cloudflare.
In _config.php: $GLOBALS['apk_url'] = 'https://apk.entrixy.com/entrixy.apk';
No script de implantação, depois de assembleRelease add r2 cp app-release.apk apk-bucket/entrixy.apk.

Na escala atual — dezenas de instalações de teste — não é preciso mudar.

A lista de ações: o que está agora no servidor e na aplicação

Para que todas as correções funcionem:

No servidor: sudo supervisorctl restart dialer-ws.
Qualquer versão abaixo da 6.66 receberá um diálogo de atualização obrigatório no arranque seguinte.
Depois de implantada a 6.66, a carga das tempestades de reconexão e das repetições cai uma ordem de grandeza.