a6ff2dd587
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.
33 lines
1.6 KiB
Markdown
33 lines
1.6 KiB
Markdown
# 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)
|