MarekWo ab64ef72f2 perf: answer /api/status with one targeted query ...

/api/status is polled by every open page (on load, every 60s, and on
visibility resume) and cost ~266-450ms in-container while doing no device
I/O at all — check_connection() is just an attribute read, and /health
returns in ~1ms, so all of it was SQLite.

Two calls were over-fetching:

- get_stats() ran COUNT(*) over 11 tables to answer a question about 2.
  COUNT(*) FROM echoes alone was ~200ms over 19k rows and the result was
  discarded. That table only grows, so the endpoint kept getting slower.
- get_channel_messages(limit=1) was a SELECT * fetching every column,
  raw_packet included, to read one timestamp. ORDER BY timestamp has no
  usable index (idx_cm_channel_ts leads with channel_idx), so the plan
  was a full SCAN through two temp B-trees. MAX(timestamp) is served off
  that index as a covering scan instead.

Replaced with Database.get_status_summary(): three scalar subqueries on
one connection. ~371ms -> ~46ms for the DB work; endpoint median ~57ms
in-container, ~78ms from the page. Response verified byte-identical.

This does not address the multi-tab congestion — at one poll per tab per
60s /api/status was never that cause — but it removes a recurring cost
and re-baselines the probe those measurements are taken with.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-07-31 08:35:53 +02:00

..

__init__.py

Phase 1: Backend basics - Complete Flask application with REST API

2025-12-21 14:02:46 +01:00

api.py

perf: answer /api/status with one targeted query

2026-07-31 08:35:53 +02:00

views.py

feat(pathanalyzer): Path Analyzer panel skeleton (stage 2)

2026-07-19 17:14:20 +02:00