From 0fe1674753ab92ba5b20de2d03ef5e76208b39f1 Mon Sep 17 00:00:00 2001 From: Bryan Van Deusen Date: Wed, 1 Jul 2026 11:51:09 -0400 Subject: [PATCH] perf(web): stream files in 4 MiB chunks + 4 hypercorn workers (fix 40s downloads) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The image library is on a CIFS/SMB share (mounted rsize=4 MiB, actimeo=1), and Quart's FileBody streams in 8 KiB chunks — so serving one large original was ~19k network round-trips to the storage server, i.e. 30–58s per download (operator-flagged). That's what starved the GPU agent (constant "curator unreachable" backoff) AND slowed the browser: every byte is read off CIFS and streamed through the Python app (no reverse-proxy sendfile), and only 2 hypercorn workers meant the agent + the browser's thumbnail grid queued behind each other. In-container fix, no new service: - Raise FileBody.buffer_size 8 KiB → 4 MiB in create_app, matching the mount's read size: one round-trip per read, ~500× fewer. buffer_size is the MAX read so small thumbnails still read in one gulp, and Range/mime/ETag/conditional handling lives on Response — all preserved. Guarded so a Quart-internal change can't break boot. - HYPERCORN_WORKERS default 2 → 4 so concurrent /images requests stop queuing. Expected: large-file transfers drop from ~40s toward link speed (a few seconds) for the agent and the browser. See issue #1223. Co-Authored-By: Claude Opus 4.8 Claude-Session: https://claude.ai/code/session_01Ttrj5P7upUTueSfoJcxEqa --- backend/app/__init__.py | 17 +++++++++++++++++ entrypoint.sh | 6 +++++- 2 files changed, 22 insertions(+), 1 deletion(-) diff --git a/backend/app/__init__.py b/backend/app/__init__.py index 75ace0d..ccb084c 100644 --- a/backend/app/__init__.py +++ b/backend/app/__init__.py @@ -34,6 +34,23 @@ def create_app() -> Quart: app = Quart(__name__) app.secret_key = cfg.secret_key + # Stream files in 4 MiB chunks instead of Quart's 8 KiB default. The image + # library lives on a CIFS/SMB share (mounted rsize=4 MiB), so 8 KiB reads + # meant ~19k network round-trips for one large original — 30–58s downloads + # that starved both the GPU agent and the browser (operator-flagged + # 2026-07-01). 4 MiB matches the mount's read size → one round-trip per read, + # ~500× fewer. buffer_size is the MAX read, so small thumbnails still read in + # a single gulp, and Range/mime/ETag/conditional handling lives on Response, + # so this keeps all of it. Guarded so a future Quart-internal change can't + # break boot — worst case we fall back to the slow default. + try: + from quart.wrappers.response import FileBody + FileBody.buffer_size = 4 * 1024 * 1024 + except Exception: + logging.getLogger(__name__).warning( + "could not raise FileBody.buffer_size — file serving stays on 8 KiB chunks" + ) + for bp in all_blueprints(): app.register_blueprint(bp) # Registered last so /api/* routes win over the SPA catch-all. diff --git a/entrypoint.sh b/entrypoint.sh index fc9e8b7..9231cce 100755 --- a/entrypoint.sh +++ b/entrypoint.sh @@ -12,9 +12,13 @@ case "$ROLE" in # create_app is a factory — the `()` tells hypercorn to call it once # and serve the returned Quart (ASGI) app, rather than treating the # function itself as the application (which it then mis-invokes as WSGI). + # Default 4 workers (was 2): each worker is one asyncio loop, and a large + # file download occupies its worker for the transfer — 2 was too few once the + # GPU agent + the browser's thumbnail grid hit /images concurrently (they + # queued behind each other). Env-tunable via HYPERCORN_WORKERS. exec hypercorn \ --bind 0.0.0.0:8080 \ - --workers "${HYPERCORN_WORKERS:-2}" \ + --workers "${HYPERCORN_WORKERS:-4}" \ --access-logfile - \ "backend.app:create_app()" ;;