Análisis de la carga del servidor

Versión del documento 2026-05-29 · Contexto: 1300 ble_token_renew de un solo invitado durante 4 horas con el propietario desconectado, lo que impulsó la búsqueda de otras fuentes de tráfico HTTP y WebSocket sobrante.

Ya corregido en la 6.61–6.63

n.º 1: reintentos HTTP sin espera FIX

Files: HostService.kt:1424-1432, Vault.kt:213

private val pendingKeysRunnable = object : Runnable {
    override fun run() {
        if (Prefs.isHostRegistered && Prefs.getPendingHostKeys().isNotEmpty()) {
            Thread { syncPendingHostKeys() }.start()
        }
        pendingKeysHandler.postDelayed(this, 60_000L)
    }
}

syncPendingHostKeys toma TODAS las claves de anfitrión pendientes y llama a Api.keyCreatepor cada una. Si la llamada HTTP falla, la clave sigue pendiente y 60 s después el ciclo se repite.

El escenario desbocado

• Un usuario tiene 5 claves en cola: creadas sin conexión o el servidor devolvió un error.
• La red es inestable.
• 5 POST HTTP cada minuto = 7200 al día para un solo usuario.
• 50 usuarios en ese estado son 360 mil peticiones al día, cada una con su conexión de Apache, su JWT y su transacción en la base.

Corrección: espera exponencial por clave

В Prefs guardar por localId:

• attempt_at_<localId> — la marca de tiempo del último intento
• attempt_count_<localId> — el contador de intentos

En cada pasada de syncPendingHostKeys:

val waitMs = (30_000L * (1L shl attemptCount)).coerceAtMost(30 * 60_000L)
if (now - attemptAt < waitMs) return@forEach  // skip
// otherwise try
val ok = try { Api.keyCreate(...); true } catch (e) { false }
if (ok) { clear attempt_at/count } else { attempt_count++; attempt_at = now }

Progression: 30 s → 1 min → 2 min → 4 min → 8 min → 16 min → 30 min (tope). Con un fallo permanente eso es una petición cada 30 minutos en vez de una por minuto. Una reducción de treinta veces.

Lo mismo vale para Vault.retryPendingBundles() — el mismo patrón.

n.º 2: las capturas del vídeo NO son carga nuestra SKIP

snap_url es la dirección externa de una cámara, un NVR o una fuente HTTP. El cliente va a esa URL directamente con Coil o ExoPlayer; nuestro servidor solo pasa el data_cipher cifrado que contiene la dirección dentro del paquete. Por nosotros no pasa ni un fotograma.

Si un propietario pone snap_int=1 para 10 invitados, su NVR recibe 10 peticiones por segundo. Esa es carga de su NVR, no de nuestro servidor.

Opcional: limitar por abajo el deslizador de la interfaz a tres segundos. Es cuestión de interfaz, no de infraestructura.

n.º 3: el planificador ble_renew SKIP

Ya está domado por las correcciones de la 6.61:

• El planificador horario envía un lote de renovaciones una vez por hora.
• La limitación (60 s por bleId) recorta los duplicados.
• INSERT IGNORE recorta el resto en el servidor.

Con diez objetos BLE, un usuario envía diez mensajes WebSocket seguidos y el servidor ejecuta diez ramas case 'ble_token_renew' seguidas. Una nadería.

n.º 4: incrementar overridesVersion FIX

File: GuestConn.kt — 7+ lugares.

AppState.overridesVersion = MutableState<Int>, una señal de Compose que significa los datos cambiaron, vuelve a leer remember. Se usa en ActionCard:

val ovrVersion = AppState.overridesVersion.value
val (overrideLabel, avatarPath) = remember(action.key, ovrVersion) {
    Prefs.getOverride(action.key)   // SharedPreferences IO
}
val snapCfg = remember(action.key, ovrVersion) {
    if (action.source == ActionSource.HOST_OWN) Prefs.getSnapshot(action.numberId)
    else Prefs.getIncomingSnapshot(...)
}
val tpl = remember(action.key, ovrVersion) { loadTpl() }  // more IO

Cada incremento hace que cada tarjeta relea la anulación, el avatar, la captura y la plantilla de SharedPreferences. Un usuario con 20 tarjetas significa 80 lecturas de SharedPreferences por incremento.

Dónde están los incrementos

Dónde carga esto al servidor de forma indirecta

Con un WebSocket inestable, cada guest_ok → el manejador vuelve a analizar los números → incrementa overridesVersion → 80 lecturas de SharedPreferences × 20 tarjetas × la frecuencia de guest_ok.

Eso es CPU local y E/S, no carga directa del servidor, pero:

• Consume batería → el Doze aprieta más → el WebSocket muere más a menudo → llegan más reconexiones al servidor.
• Carga la CPU en cada oleada de redibujado → el hilo principal se atasca → los pings y pongs llegan tarde → el servidor agota su tiempo de espera de 20 segundos → cierra → reconexión → carga nueva.

Corrección: comparar antes de incrementar

Antes de incrementar, comparar la nueva lista JSON de numbers con la anterior, por hash o comparando la lista de GuestNumberInfo). Idénticos → no incrementar.

private var lastNumbersHash: Int = 0

private fun maybeUpdateNumbers(arr: JSONArray?) {
    val parsed = parseNumbers(arr)
    val newHash = parsed.hashCode()  // or a hash of the JSON serialisation
    if (newHash == lastNumbersHash) return  // nothing changed
    lastNumbersHash = newHash
    numbers = parsed
    publish()
    AppState.overridesVersion.value = AppState.overridesVersion.value + 1
}

numbers_update llega con regularidad pero rara vez cambia de verdad: un propietario no edita objetos cada minuto. La optimización elimina cerca del 90 % de las oleadas de redibujado sobrantes.

Conclusión: qué corregir