-
Multi-Hoster-Upload v3.3.98 Stable
Administrator released this
2026-06-21 17:56:49 +02:00 | 11 commits to master since this releasev3.3.98 — 1MB read-ahead to absorb read-bursts + config-persist/load instrumentation
v3.3.97 (
UV_THREADPOOL_SIZE64→8) was a decisive win: mean event-loop-delay at ~70 simultaneous uploads dropped 200 ms → ~11 ms (18×) and rss fell from 577 MB to ~287 MB, with the renderer healthy in 14 of 15 sampled windows. This release chases the residual roughness with a single behavioral change plus measurement.Localized residual (two separate, measured spike sources):
- Read-bursts. In the tail windows the file-read histogram inverts — file reads in flight climb to 66–70 against the 8-slot threadpool while socket writes collapse, and mean delay rises to 30–42 ms. GC is ruled out (max GC pause ≤27 ms in every window).
- A suspected synchronous config-persist stall — instrumented this build rather than asserted, because it rests on a single confounded sample.
Changes:
highWaterMark256 KB → 1 MB in all five streaming upload read loops (the 16 MB clouddrop chunked protocol size is untouched).UV_THREADPOOL_SIZEstays 8. This deepens each stream's read-ahead cushion from ~0.43 s to ~1.7 s, so a stream tolerates the threadpool queue without starving its socket write, and cuts read-completion callbacks and per-chunk buffer allocations ~4×. Upload byte-correctness is unaffected (Content-Length and multipart boundaries are independent of chunk size). Fully reversible.- Config-store instrumentation: the synchronous config load (full reparse) and serialize paths now log their wall-time, byte size, history length and queue length when they exceed 20 ms, to confirm or rule out a periodic persist stall in the next real-load measurement.
No upload behavior changed beyond the read-ahead size.
Downloads
-
Multi-Hoster-Upload v3.3.97 Stable
2026-06-21 17:12:29 +02:00 | 12 commits to master since this releasev3.3.97 — Decisive high-concurrency lag build: threadpool 64→8 + GC/heap instrumentation
The v3.3.96 event-loop-delay logs from a real 70-connection run localized the lag to the file-read path, not crypto, not the renderer. At a constant active-job count the process flips between two clean regimes:
- Healthy (ELD ~11ms, rss 268–308MB): socket writes dominate the in-flight resources, file reads ≈ 0.
- Blocked (ELD 49–217ms, rss 540–610MB): 62–71 file reads in flight, socket writes ≈ 0.
Both the event-loop-delay spike and the rss balloon track the in-flight file-read count exactly.
This release is both a candidate fix and a discriminator:
UV_THREADPOOL_SIZE64 → 8. One reversible line, not an upload cap — all uploads still run. 8 concurrent 256 KB reads sustain ~100 MB/s, far above the ~41 MB/s aggregate, so it cannot bottleneck throughput. Strong suspicion that the previous value of 64 made things worse: it removed the natural read-serialization (default 4 threads) and let all ~70 streams' reads fire at once, flooding the event loop with completion callbacks in lock-step bursts.- GC/heap instrumentation added to the
eventloop-delaylog line:heap=(heapUsed),ext=(external),ab=(arrayBuffers), andgc=/gcTotal=/gcMax=ms via a GC PerformanceObserver, reset per window. The ~18 MB of in-flight read buffers cannot account for the ~300 MB rss swing, so garbage-collection pressure is now measured directly.
No upload behavior changed.
Downloads
-
Multi-Hoster-Upload v3.3.96 Stable
2026-06-21 16:48:50 +02:00 | 13 commits to master since this releaseDiagnostics fix: the high-concurrency measurement was only logging '[INFO ] perf' without the actual numbers (a logging-helper arg bug) — the full eventloop-delay line (CPU%, per-hoster connections, transient errors, event-loop delay) now reaches upload-debug.log. Also fixes the tray icon failing to load on startup (assets were not packaged into the app), which caused an unhandled-rejection on every launch.
Downloads
-
Multi-Hoster-Upload v3.3.95 Stable
2026-06-21 16:33:51 +02:00 | 15 commits to master since this releaseFix: installing an update while many uploads were running got stuck at 'Update wird heruntergeladen...' forever (manual restart required). The update now stops the active uploads before downloading (the app restarts for the update anyway, and the queue is saved so it resumes), so the installer download no longer competes with 70 uploads for CPU/network. Also added a 45s download stall-timeout so a stalled download fails with a clear message and a working retry instead of hanging.
Downloads
-
Multi-Hoster-Upload v3.3.94 Stable
2026-06-21 16:24:24 +02:00 | 17 commits to master since this releaseMeasurement build for high-concurrency lag diagnosis. Adds detailed performance logging while uploading (no change to upload behavior): the main process now logs CPU usage, per-hoster live connection distribution and transient (ECONNRESET-class) error counts alongside the event-loop delay; the renderer logs real frame rate, janked frames and long-task counts. Run a high-concurrency batch and the log lines (eventloop-delay / renderer-perf) pinpoint whether the lag is the renderer, the main thread (CPU-bound) or IO/oversubscription. Tip: Settings > Uploads > 'Globale parallele Uploads' caps total simultaneous uploads — lowering it (e.g. 20) reduces load and ECONNRESET.
Downloads
-
Multi-Hoster-Upload v3.3.93 Stable
2026-06-21 05:05:38 +02:00 | 20 commits to master since this releaseFix UI lag / scroll stutter with many simultaneous uploads (50+ connections). The renderer was running an expensive locale date-format on every single progress event — 10x the number of active uploads per second — and discarding the result except when an upload actually finished. At 50-61 concurrent uploads this added a ~5ms synchronous main-thread block every 100ms on top of rendering, blowing the frame budget and stuttering scrolling (worst when the uploading rows were scrolled out of view). The timestamp is now computed only when a completed upload is actually recorded. Measured: per-batch cost at 61 concurrent dropped from ~4ms to 0ms, frame P95 from 7.3ms to 4.2ms.
Downloads
-
Multi-Hoster-Upload v3.3.92 Stable
2026-06-21 04:21:01 +02:00 | 23 commits to master since this releaseDiagnostics: the high-concurrency event-loop-delay log now includes a histogram of active I/O resources (sockets, file reads, DNS lookups), so a single upload run pinpoints whether lag at many concurrent connections is CPU-bound (main thread blocked) or IO-bound (work queued behind the libuv threadpool/sockets). No behavior change to uploads.
Downloads
-
Multi-Hoster-Upload v3.3.91 Stable
2026-06-21 04:11:21 +02:00 | 27 commits to master since this releaseHigh-concurrency uploads: raise the libuv threadpool size (UV_THREADPOOL_SIZE=64) so file reads and DNS lookups for many simultaneous uploads no longer serialize through the default 4 threads — this targets lag that appears from a certain number of concurrent connections onward. Also adds an event-loop-delay metric (perf_hooks) that is logged while uploading, to pinpoint whether high-concurrency lag is CPU-bound (needs workers/cap) or IO-bound (needs threadpool/socket tuning).
Downloads
-
Multi-Hoster-Upload v3.3.90 Stable
2026-06-21 03:45:30 +02:00 | 30 commits to master since this releasePerformance: clouddrop chunked uploads now read file chunks asynchronously (fs.promises fh.read) instead of synchronously on the main thread — this eliminates event-loop stalls during large clouddrop uploads that grew with the number of concurrent uploads and caused UI lag at modest CPU. Rotation and suspect-account upload paths now throttle progress emits to ~4/sec (matching the primary path) instead of emitting on every stream chunk.
Downloads
-
Multi-Hoster-Upload v3.3.89 Stable
2026-06-21 03:06:44 +02:00 | 34 commits to master since this releaseHardening (opt-in remote/diagnostics server only): cap the WebSocket maxPayload at 256 KiB to close an unbounded pre-auth JSON.parse freeze/DoS sink, and guard sendToClient with a readyState check + try/catch so a send on a closing socket cannot escape as an uncaughtException. No change to normal upload behavior.
Downloads