perf(web): 4 MiB file streaming + 4 hypercorn workers (fix 40s downloads) #179
Reference in New Issue
Block a user
Delete Branch "dev"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Pins down and fixes the slow image/media serving (operator: 30–58s downloads on a gigabit LAN).
Root cause: curator serves
/imagesthrough the Quart app off a CIFS/SMB share (rsize=4 MiB, actimeo=1). Quart'sFileBodystreams in 8 KiB chunks → ~19k network round-trips per large original → 30–58s. Compounded by only 2 hypercorn workers (agent + browser thumbnail grid queue behind each other) and no reverse-proxy sendfile.Fix (in-process, no new container — operator is already "wide"):
FileBody.buffer_size8 KiB → 4 MiB increate_app, matching the mount's read size: one round-trip per read, ~500× fewer. It's the MAX read, so thumbnails still read in one gulp; Range/mime/ETag/conditional handling lives onResponse, so all preserved. Guarded so a Quart-internal change can't break boot.HYPERCORN_WORKERSdefault 2 → 4 so concurrent/imagesrequests stop queuing (env-tunable; the chunk fix is the real lever since transfers now free a worker ~20× faster).Expected: large-file transfers drop from ~40s toward link speed (a few seconds) for the agent and the browser. Requires a curator redeploy. See issue #1223. CI green on dev (run 1827).
🤖 Generated with Claude Code