Analyse der Serverlast

Dokumentversion 29.05.2026 · Kontext: 1300 ble_token_renew von einem einzigen Gast in 4 Stunden Offline-Zeit des Besitzers — das gab den Anstoß, weitere Quellen überflüssigen HTTP- und WebSocket-Verkehrs zu suchen.

Bereits in 6.61–6.63 behoben

#1 — HTTP-Wiederholungen ohne Backoff 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 nimmt ALLE ausstehenden Host-Schlüssel und ruft Api.keyCreatefür jeden. Scheitert der HTTP-Aufruf, bleibt der Schlüssel ausstehend, und 60 s später wiederholt sich der Zyklus.

Das Ausreißer-Szenario

• Ein Nutzer hat 5 Schlüssel in der Warteschlange — offline erstellt oder der Server gab einen Fehler zurück.
• Das Netz ist instabil.
• 5 HTTP-POSTs pro Minute = 7200 pro Tag für einen einzigen Nutzer.
• 50 Nutzer in diesem Zustand bedeuten 360 000 Anfragen pro Tag, jede davon eine Apache-Verbindung, ein JWT und eine Datenbanktransaktion.

Behebung: exponentieller Backoff je Schlüssel

В Prefs je localId speichern:

• attempt_at_<localId> — der Zeitstempel des letzten Versuchs
• attempt_count_<localId> — der Versuchszähler

Bei jedem Durchlauf von 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 (Deckel). Bei dauerhaftem Fehler ist das eine Anfrage alle 30 Minuten statt einer pro Minute. Eine dreißigfache Senkung.

Dasselbe gilt für Vault.retryPendingBundles() — dasselbe Muster.

#2 — Kamera-Schnappschüsse sind NICHT unsere Last SKIP

snap_url ist die externe Adresse einer Kamera, eines NVR oder einer HTTP-Quelle. Der Client geht direkt über Coil oder ExoPlayer dorthin; unser Server reicht nur den verschlüsselten data_cipher , der die Adresse im Bundle enthält, weiter. Keine Bilder laufen über uns.

Setzt ein Besitzer snap_int=1 für 10 Gäste, sieht sein NVR 10 Anfragen pro Sekunde. Das ist Last auf seinem NVR, nicht auf unserem Server.

Optional: den Schieberegler in der Oberfläche nach unten auf drei Sekunden begrenzen. Das ist eine Frage der Oberfläche, nicht der Infrastruktur.

#3 — der ble_renew-Scheduler SKIP

Bereits durch die Korrekturen von 6.61 gezügelt:

• Der Stunden-Scheduler schickt einmal pro Stunde ein Bündel Verlängerungen.
• Die Drosselung (60 s je bleId) schneidet Duplikate weg.
• INSERT IGNORE schneidet den Rest auf dem Server weg.

Bei zehn BLE-Objekten schickt ein Nutzer zehn WebSocket-Nachrichten nacheinander, und der Server durchläuft zehn case 'ble_token_renew' -Zweige nacheinander. Eine Kleinigkeit.

#4 — das Hochzählen von overridesVersion FIX

File: GuestConn.kt — 7+ Stellen.

AppState.overridesVersion = MutableState<Int>, ein Compose-Signal mit der Bedeutung „die Daten haben sich geändert, lies remember“. Verwendet wird es in 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

Jedes Hochzählen zwingt jede Karte, Override, Avatar, Schnappschuss und Vorlage neu zu lesen aus SharedPreferences. Ein Nutzer mit 20 Karten bedeutet 80 SharedPreferences-Lesevorgänge je Hochzählen.

Wo die Hochzählungen sitzen

Wo das den Server indirekt belastet

Bei flatterndem WebSocket führt jedes guest_ok → der Handler parst die Nummern neu → zählt overridesVersion hoch → 80 SharedPreferences-Lesevorgänge × 20 Karten × die guest_ok-Rate.

Das ist lokale CPU und I/O, keine direkte Last auf dem Server, aber:

• Es zehrt am Akku → Doze greift härter → der WebSocket stirbt öfter → mehr Neuverbindungen treffen den Server.
• Es belastet die CPU bei jeder Neuzeichenwelle → der Hauptthread stockt → Pings und Pongs verspäten sich → der Server läuft in sein 20-Sekunden-Timeout → schließt → Neuverbindung → frische Last.

Behebung: vor dem Hochzählen vergleichen

Vor dem Hochzählen die neue JSON-Liste der numbers mit der vorherigen vergleichen — per Hash oder durch Vergleich der Liste von GuestNumberInfo). Identisch → nicht hochzählen.

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 kommt regelmäßig, ändert sich aber selten — ein Besitzer bearbeitet Objekte nicht jede Minute. Die Optimierung entfernt rund 90 % der überflüssigen Neuzeichenwellen.

Fazit: was zu beheben ist