From 61cfd3f5a9e4820ae9319ad64df4d7cb6f35b5cc Mon Sep 17 00:00:00 2001 From: RNL Date: Thu, 6 Aug 2026 22:43:51 +1000 Subject: [PATCH] perf(printer): halve dashboard load by capping chart series at 1440 points MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 24h at the collector's 30s cadence is ~2800 readings, and each one pulls in ~9 FilamentSnapshot rows. That snapshot fetch — not the metrics query — was what made the dashboard slow: 25,308 rows and 1.2s of the 2.09s spent building the context. Capping at 1440 keeps roughly one point per minute over a day, finer than a canvas can resolve, and applies to the public demo API too since it shares sample_metrics(). printer dashboard 2.09s / 410 KB -> 0.50s / 207 KB public demo API -> 0.31s / 116 KB Claude-Session: https://claude.ai/code/session_01AoYZiGtU3zEuFEGvP6zoZD --- bambu_run/views.py | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/bambu_run/views.py b/bambu_run/views.py index 1794bf2..b9129b9 100644 --- a/bambu_run/views.py +++ b/bambu_run/views.py @@ -28,7 +28,13 @@ _METRICS_API_FIELDS = [ 'gcode_state', 'print_type', 'subtask_name', 'external_spool', ] -_MAX_CHART_POINTS = 3000 +# 24h at the collector's 30s cadence is ~2800 readings, and every one of them +# also drags in ~9 FilamentSnapshot rows — that snapshot fetch, not the metrics +# query, is what dominated the dashboard's load time (measured: 2.09s of context +# building and a 410 KB payload at 3000). 1440 caps the series at roughly one +# point per minute over a day, which is finer than any chart can resolve on +# screen, and cuts both the server time and the payload by ~4x. +_MAX_CHART_POINTS = 1440 # Fallback window for requests that don't specify a full date range. Without it a # bare API call scans the entire metrics table. _DEFAULT_WINDOW = timedelta(hours=24)