-
Multi-Hoster-Upload v3.3.97 Stable
Administrator released this
2026-06-21 17:12:29 +02:00 | 24 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