Capacidad del servidor

Actualizado el 2026-05-30 · tras desplegar las correcciones 6.61–6.64.

Lo principal: preproducción, sin legado

En el servidor de producción todavía no hay usuarios reales. Todas las instalaciones son de prueba. De ahí que:

Estimaciones por franja de carga

Audiencia, MAUWS simultáneos (pico)Estado de un único VPSCuello de botella principal
≤ 30k ≤ 3k Diez veces de margen, en reposo Nada en nuestra pila
30k — 100k 3k — 10k La franja objetivo, cómoda La CPU de Workerman lleva sin esfuerzo los pongs y los eventos. La base de datos trabaja por clave primaria. 500 MB–1 GB de RAM para los sockets.
100k — 200k 10k — 20k Trabajo al límite El único proceso de Workerman se recalienta en el pico. Basta con que aparezca un fallo con WebSockets caídos para que empiece la degradación.
> 200k > 20k Chocamos con el techo Hace falta la fase C (Workerman count=4 más Redis pub/sub para un $hosts/$guests).

Qué se corrigió en 6.61–6.64

MetricAntes de las correccionesDespués de la 6.64Dónde se hizo
ble_token_renew en cola mientras el propietario está desconectado 1300 en 4 h 1 (deduplicación por UNIQUE INDEX) Server — funciona con cualquier cliente
Reintentos HTTP ante un fallo de red 5 claves × 1/min = 7200 al día ~50 al día (espera de 30 minutos) Cliente 6.64 — hace falta un APK nuevo
Reconexiones de WebSocket con una red inestable ~10/min (reintento a 1 s) ~1/min (espera de 60 s) Cliente 6.62+ — hace falta un APK nuevo
Consultas a la base en el hello con WebSocket inestable ~50/s con 10 mil clientes ~5/s Server — el límite de 5 segundos protege frente a cualquier cliente
Eventos fire fallidos en las preferencias del invitado más de 60 al día por invitado con el token caducado 0 Cliente 6.63
Oleadas de recomposición en guest_ok en cada numbers_update solo ante un cambio real Cliente 6.64

Qué funciona de inmediato para todos los clientes (correcciones del servidor)

Las protecciones del servidor viven en el tratamiento de los mensajes entrantes — se aplican sea cual sea la versión del cliente.

Qué solo funciona tras actualizar el cliente

Decisión: se sube $MIN = '6.66'. Cualquier cliente antiguo, en su primer versionCheck recibe un diálogo bloqueante Actualiza la aplicación (la interfaz ya existe, véase App.kt:checkVersionAsync).

Escalar Workerman: cuándo hará falta

Ahora mismo count=1 — un único proceso PHP mantiene TODOS los WebSockets en los arreglos $hosts/$guests/$calls in-memory.

Los umbrales concretos:

Qué hacer al acercarse a las 15 mil:

  1. Instalar Redis en el VPS (apt install redis-server).
  2. Workerman count=4 (según el número de núcleos del VPS).
  3. Move $hosts/$guests/$calls a un HASH de Redis con TTL.
  4. Pub/sub entre trabajadores: si un mensaje llega a W1 pero el destinatario está en W2, se retransmite por el canal.

Effect: escalado lineal hasta 4×, con el techo subiendo a unas 40–60 mil simultáneas.

Mudarse a una CDN: cuándo hará falta

Hoy el APK de 22 MB se sirve a cada usuario desde nuestro propio VPS. Con cien mil, eso son 2,2 TB de tráfico saliente por versión: puede que nuestro enlace no dé abasto o resulte caro.

Preparado en la 6.64:

Cuando la mudanza haga falta:

  1. Un bucket de Cloudflare R2 → subir entrixy.apk.
  2. Dominio propio apk.entrixy.com a través de la CDN de Cloudflare.
  3. In _config.php: $GLOBALS['apk_url'] = 'https://apk.entrixy.com/entrixy.apk';
  4. En el script de despliegue, tras assembleRelease add r2 cp app-release.apk apk-bucket/entrixy.apk.

A la escala actual —decenas de instalaciones de prueba— no hace falta mudarse.

La lista de acciones: qué hay ahora en el servidor y en la aplicación

Para que funcionen todas las correcciones:
  1. En el servidor: sudo supervisorctl restart dialer-ws.
  2. Cualquier versión por debajo de la 6.66 recibirá un diálogo de actualización obligatorio en el siguiente arranque.
  3. Tras desplegar la 6.66, la carga de las tormentas de reconexión y los reintentos cae en un orden de magnitud.