Files
meshcore-analyzer/cmd
Alex BandClaude Opus 5.5 8a3b923e81 perf(scope-stats): keep the per-region count on the first_seen index (#2166)
## Summary

`/api/scope-stats` averaged **2.6 s on one production instance (max 17.7
s)**, whatever the window. Four of its five queries take 10-100 ms on
that database. The fifth, the per-region count, took **2.5-2.9 s for
every window, 1h included**: SQLite chose `idx_tx_scope_name`
(`scope_name > ''`) and walked every scoped transmission ever stored (45
days of them), filtering by `first_seen` afterwards.

```
SEARCH transmissions USING INDEX idx_tx_scope_name (scope_name>?) | USE TEMP B-TREE FOR ORDER BY
```

A unary `+` on every `scope_name` reference in that query (`WHERE …
+scope_name …`, `GROUP BY +scope_name`) stops the planner using that
index. The query then searches the window on
`idx_transmissions_first_seen` and groups in a temp b-tree, the same
idiom the `advertsByRole` query in the same function already uses for
`payload_type`. Putting `+` in the `WHERE` alone is not enough: the
planner then walks `idx_tx_scope_name` to avoid sorting for the `GROUP
BY`, which is just as slow; the `GROUP BY +scope_name` is what fixes it.

```
SEARCH transmissions USING INDEX idx_transmissions_first_seen (first_seen>?) | USE TEMP B-TREE FOR GROUP BY | USE TEMP B-TREE FOR ORDER BY
```

Related to #2146, which lists `/api/scope-stats` (2.3 s average on one
instance) and records the 24 h summary as 7 ms warm there. On the
instance measured here the per-region query planned onto
`idx_tx_scope_name` and took 2.5-2.9 s for every window; this PR fixes
that plan. Not marked as a fix: #2146 is about pool and lock waits.

## Results are identical

On a copy of the production database, the old and new query run inside
**one read transaction** (same snapshot) return exactly the same rows
for 1h, 24h, 7d and 45d (5, 10, 12 and 18 regions; 73, 2,024, 13,822 and
76,083 transmissions). `TestScopeStatsByRegion_CountsMatchWindow` also
checks the per-region counts against a direct count of the window.

## Performance

### The query alone, on a copy of the production database

311k transmissions, 76k of them region-scoped over 45 days; best of
three:

| window | before | after |
|---|---|---|
| 1h | 2,530 ms | 0.1 ms |
| 24h | 2,570 ms | 11.6 ms |
| 7d | 2,876 ms | 124 ms |

### The endpoint, on staging

Cold `GET /api/scope-stats` (the response cache is 30 s, so each sample
is a full compute) on a staging host with a copy of a production
database and its live feed; two samples each, 32 s apart:

| window | master | this PR |
|---|---|---|
| 1h | 3.08 s, 2.83 s | **16 ms, 12 ms** |
| 24h | 2.69 s, 2.79 s | **131 ms, 101 ms** |
| 7d | 3.35 s, 4.53 s | **626 ms, 663 ms** |

### Go benchmark

`BenchmarkGetScopeStats24h`: all five scope-stats queries for 24h, on
300k transmissions spread over 45 days (a quarter region-scoped), with
production's tables and both competing indexes and `ANALYZE` run as
production does (#2072). 10 runs:

```
cpu: AMD Ryzen 5 3600XT 6-Core Processor
                    │   master    │             this PR              │
GetScopeStats24h-12   33.186m ± 3%   8.058m ± 6%  -75.72% (p=0.000 n=10)
```

The fixture is smaller and better cached than production, which is why
the absolute times are lower than above; the plan change is the same.

## Tests

- Red commit `a7dcf98f`: moves the query into `scopeStatsByRegionQuery`
(unchanged), adds the fixture, the benchmark,
`TestScopeStatsByRegion_UsesFirstSeenIndex` (`EXPLAIN QUERY PLAN` must
use `idx_transmissions_first_seen` and not `idx_tx_scope_name`; fails on
`master` with exactly the production plan shown above) and
`TestScopeStatsByRegion_CountsMatchWindow` (passes on both commits;
guards correctness).
- Green commit `f9ba986b`: the `+` hints and a comment explaining them.
- All existing scope-stats tests pass; `make test`: 16 of 16 modules
pass.

## Review notes

- Only the per-region query changes; the summary, non-transport,
time-series and adverts-by-role queries already search by `first_seen`.
- If `idx_transmissions_first_seen` were ever missing, the query would
still run correctly (full scan); `+` only removes `idx_tx_scope_name`
from consideration, unlike `INDEXED BY`, which would make the query
fail.
- `/api/scope-stats` still has no singleflight around its 30 s cache
(unlike stats, channels and the scope audit). With the query now well
under a second it matters much less; left for a separate change.

## SonarLint

SonarQube Community rules (the SonarLint engine) were run on the files
this PR touches, and only issues on lines it adds are listed.

- No issues on the added lines.

## Checked against the repo rules

- Rebased onto `master` (`673442cc`). Each red commit was re-run and
still fails on its assertions; each green commit passes (TDD.md).
- `make test`: all 16 modules pass. Frontend suites: all pass except
`test-issue-1956-release-routing.js`, which needs CI's `GITHUB_REF_NAME`
and fails the same way on `master` locally (#2160 addresses it).
- No private data: test fixtures and examples use the codes the existing
tests use (SJC/SFO/LAX, `#be`-style scopes).
- No new `map[string]interface{}`, no hard-coded colours. `git add` was
explicit, and there is one logical change per commit.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_01KaR4xu8gVykQBkH8yG8m6H

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-10 21:22:02 +02:00
..