mirror of
https://github.com/MarekWo/mc-webui.git
synced 2026-08-03 23:42:31 +02:00
MarekWo
ab64ef72f2
/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>