ben/Bambu-Run
1
0
Fork 0
mirror of https://github.com/RunLit/Bambu-Run.git synced 2026-08-22 06:44:19 +01:00
Code Issues Packages Projects Releases Wiki Activity

perf(printer): halve dashboard load by capping chart series at 1440 points

Browse Source 
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
This commit is contained in:
RNL
2026-08-06 22:43:51 +10:00
parent 1e35c48be1
commit 61cfd3f5a9
1 changed files with 7 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
bambu_run/views.py
View File

@@ -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)