Multi-Hoster-Upload/tasks/todo.md
Administrator a6ff2dd587 chore(main): drop JSON.stringify of files/hosters in start-upload log
At 500+ queued jobs these lines bloated upload-debug.log with
megabyte-sized entries per batch-start and added visible latency to
the IPC handler. Log sizes only.
2026-04-21 19:31:07 +02:00

1.6 KiB

Perf/Stabilität Audit (nach 3.1.5)

Ziel: bekannte Schwachstellen aus der Review abarbeiten, jeweils mit eigenem Release.

Schritt 1 — Log-Geschwätz reduzieren (main.js:1066)

  • JSON.stringify(files/hosters) durch count-only ersetzen
  • Bei 500 Jobs spart's MB-große debugLog-Einträge pro start-upload
  • Release als 3.1.6

Schritt 2 — persistQueueState-Write vermessen + drosseln

  • Verstehen: wie groß ist das JSON bei 500 Jobs? Wie oft schreibt's während eines Batches?
  • Ggf. maximale Write-Größe / Frequenz während Upload erhöhen (derzeit 10s bei uploading, 500ms sonst)
  • Ggf. nur bei Status-Änderung, nicht bei Progress-Byte-Change
  • Release als 3.1.7 (nur wenn echter Bottleneck gefunden)

Schritt 3 — Progress-Event-Flood drosseln (app.js:1862-1871)

  • Status-Change-Events rufen sync updateQueueActionButtons + updateStatusBar + updateStatsPanel
  • Bei 50+ parallelen Uploads → 100+ sync Callbacks/Sek
  • Coalesce via rAF (wie scheduleQueueRender für uploading-events)
  • Tests für den neuen Pfad
  • Release als 3.1.8

Schritt 4 — Byse-Poller-Review (lib/hosters.js:440+)

  • Verstehen warum der Poller existiert (zuverlässigkeitsproblem mit direkter Response?)
  • Edge-Cases prüfen: was wenn Poll 0 neue Files findet aber Upload durch war?
  • Dokumentieren was funktioniert und was nicht
  • Kein Release außer echter Bug gefunden

Offen nach diesen Schritten

  • Memory-Wachstum bei langen Sessions (bräuchte Instrumentierung)
  • Throughput-Skaling bei 20+ parallelen Uploads (bräuchte Lasttest)
  • Netz-Ausfall-Recovery (bräuchte Netz-Interrupt-Test)