PERF: Photos rule 8 — keep counts and background work off the first usable path (#663) #683

Open
opened 2026-10-02 05:36:32 +00:00 by kayg · 1 comment
Owner

Context: #663 matrix and DESIGN §58 rule 8. Scope: Photos must keep counts and background work off the first usable path. Shared client machinery belongs only to #665–#668.

Evidence at c4a61e8cf0:

  • Endpoint: GET /api/v1/photos/timeline/buckets.
  • Source: crates/plugins/photos/src/routes.rs:629. All day counts are fetched before first timeline use. Ingest batches 32/200 (index.rs:430/:519) and uses workers, but foreground counts remain part of startup.
  • Representative endpoint numbers, server/client revisions, fixture size, lock/HDD qualification and limits are in the #663 production/HDD table. Those numbers do not prove this rule passes; the structural gap above is separate evidence.

Expected and regression tests:
Compare first-row/first-card paint with counts/stats deliberately delayed. Interactive input and usable rows must not await counts, thumbnail jobs or non-selected sidebars. Under a held writer and indexing/backfill batches, reads use a separate read-only pool and return a complete committed answer. Bound batches, yield between them and record CPU/RSS plus per-phase latency. Keep all visible totals correct; do not remove counts or replace them with fake values. Record accepted and durable timings via #667, without content or credentials.

Performance test:
Extend the existing bench profile for this hot path and the #549/#641 harness. Use production builds on root@10.69.69.63, bench/hdd-emu.sh and flock -w 14400 /root/perf.lock. Record load inside the lock; ≥5 samples, median/p95/max, average CPU/RSS and one realistic large-data/burst case. Separate warm, cold, accepted and durable boundaries. First usable 10k view ≤1.5 s; cached open/warm return ≤100 ms and accepted action ≤150 ms where applicable. Compare only a matching baseline in docs/perf/baseline.json; missing profiles require a new recorded baseline, not a made-up comparison.

Reuse/ownership:

Reuse #555 userStorage, #549 route caches, Files signed keysets/change feed and the existing Db reader_pool. #641 owns blaze measurements; #642 owns Settings opening; #640 owns Mail layouts; #639 owns linked Note opening. Integrate their active/completed branches before changing related code.

Acceptance:
Existing tests and status expectations stay intact. Run the per-crate gates (and calternal-server for route/contract changes), web gates if changed, and one time-boxed real-server regression/adversarial round for any new API contract. Preserve calternal-fs as the only filesystem interface and the server as the only writer. UI changes need pointer/touch/keyboard/screen-reader coverage and real-production captures at 390/820/1440 in both themes. Do not change shared motion for keyboard input.

Representative measurement from the audit (not a full-view budget result):
/api/v1/photos/timeline?days=30&tiles_per_day=48, five serial requests after fixture readiness, all HTTP 200. Median/p95/max 46.0/48.2/48.2 ms; five-request burst median/p95/max 62.2/62.7/62.7 ms. Serial window server CPU 10 ms, RSS 443625472 bytes; no ETag on these sampled responses. Load inside lock 3.45/2.03/0.9.
Shared release server source cc25c441b7a974185622a1dee853cf38686d2b67, binary SHA-256 2f3567d91c34839851247bc0acbc25a56aaacd14dca269b8f0342ddf83447ed9; embedded production SPA; Chromium browser on the build host through SSH/HTTPS. Server/Home/Index on perf VM HDD emulator: direct-I/O loop, 8 ms read/write dm-delay, 200 IOPS and 150 MiB/s caps. Every measured phase held flock -w 14400 /root/perf.lock. Qualification QD1 115.3 IOPS/8.028 ms median, QD16 200.7 IOPS/96.993 ms. Fixture: 366 Daily notes, 10,980 Logs, 100 Files/Photos, 20 Notes/Tasks, three Budgets and 100 transactions; Mail empty, Admin one User.
Structural source evidence above is the newer audit base, not the measured binary revision. No claim that these revisions are equivalent. The baseline in docs/perf/baseline.json uses another fixture/build/transport; no regression ratio is valid here. See #663 for matching baseline endpoint values and coverage gaps.

Context: #663 matrix and DESIGN §58 rule 8. Scope: Photos must keep counts and background work off the first usable path. Shared client machinery belongs only to #665–#668. Evidence at c4a61e8cf090170f35b1bed3350d9de20c83ecd5: - Endpoint: `GET /api/v1/photos/timeline/buckets`. - Source: `crates/plugins/photos/src/routes.rs:629`. All day counts are fetched before first timeline use. Ingest batches 32/200 (index.rs:430/:519) and uses workers, but foreground counts remain part of startup. - Representative endpoint numbers, server/client revisions, fixture size, lock/HDD qualification and limits are in the #663 production/HDD table. Those numbers do not prove this rule passes; the structural gap above is separate evidence. Expected and regression tests: Compare first-row/first-card paint with counts/stats deliberately delayed. Interactive input and usable rows must not await counts, thumbnail jobs or non-selected sidebars. Under a held writer and indexing/backfill batches, reads use a separate read-only pool and return a complete committed answer. Bound batches, yield between them and record CPU/RSS plus per-phase latency. Keep all visible totals correct; do not remove counts or replace them with fake values. Record accepted and durable timings via #667, without content or credentials. Performance test: Extend the existing bench profile for this hot path and the #549/#641 harness. Use production builds on root@10.69.69.63, bench/hdd-emu.sh and flock -w 14400 /root/perf.lock. Record load inside the lock; ≥5 samples, median/p95/max, average CPU/RSS and one realistic large-data/burst case. Separate warm, cold, accepted and durable boundaries. First usable 10k view ≤1.5 s; cached open/warm return ≤100 ms and accepted action ≤150 ms where applicable. Compare only a matching baseline in docs/perf/baseline.json; missing profiles require a new recorded baseline, not a made-up comparison. Reuse/ownership: Reuse #555 userStorage, #549 route caches, Files signed keysets/change feed and the existing Db reader_pool. #641 owns blaze measurements; #642 owns Settings opening; #640 owns Mail layouts; #639 owns linked Note opening. Integrate their active/completed branches before changing related code. Acceptance: Existing tests and status expectations stay intact. Run the per-crate gates (and calternal-server for route/contract changes), web gates if changed, and one time-boxed real-server regression/adversarial round for any new API contract. Preserve calternal-fs as the only filesystem interface and the server as the only writer. UI changes need pointer/touch/keyboard/screen-reader coverage and real-production captures at 390/820/1440 in both themes. Do not change shared motion for keyboard input. Representative measurement from the audit (not a full-view budget result): `/api/v1/photos/timeline?days=30&tiles_per_day=48`, five serial requests after fixture readiness, all HTTP 200. Median/p95/max 46.0/48.2/48.2 ms; five-request burst median/p95/max 62.2/62.7/62.7 ms. Serial window server CPU 10 ms, RSS 443625472 bytes; no ETag on these sampled responses. Load inside lock 3.45/2.03/0.9. Shared release server source `cc25c441b7a974185622a1dee853cf38686d2b67`, binary SHA-256 `2f3567d91c34839851247bc0acbc25a56aaacd14dca269b8f0342ddf83447ed9`; embedded production SPA; Chromium browser on the build host through SSH/HTTPS. Server/Home/Index on perf VM HDD emulator: direct-I/O loop, 8 ms read/write dm-delay, 200 IOPS and 150 MiB/s caps. Every measured phase held `flock -w 14400 /root/perf.lock`. Qualification QD1 115.3 IOPS/8.028 ms median, QD16 200.7 IOPS/96.993 ms. Fixture: 366 Daily notes, 10,980 Logs, 100 Files/Photos, 20 Notes/Tasks, three Budgets and 100 transactions; Mail empty, Admin one User. Structural source evidence above is the newer audit base, not the measured binary revision. No claim that these revisions are equivalent. The baseline in docs/perf/baseline.json uses another fixture/build/transport; no regression ratio is valid here. See #663 for matching baseline endpoint values and coverage gaps.
Author
Owner

Additional disk IO / writer occupancy evidence from perf-arch-io (#663) for #683. Source origin/dev c4a61e8cf090170f35b1bed3350d9de20c83ecd5; merge-round-7a does not change Photos index.rs.

crates/plugins/photos/src/index.rs:264 refreshes all viewers on the Files reconciliation completion event. refresh_user:345 forces a rebuild (true). refresh_user_if_changed:778 holds a shared refresh lock across the whole library; :825 streams library rows while changed media can await parse_media on a blocking thread (:1161). It then acquires the ONE shared Index writer at :874 and, before :970 commit, upserts every media item, deletes/recreates all group memberships and day counts and upserts all groups. This full-refresh transaction has no row/byte/time cap, even when the library did not change, because force_rebuild bypasses the unchanged return at :854.

The incremental path already uses bounded affected-row batches and should be reused. That does not bound the full startup/lag/root-change path.

Reasoned impact: a large startup or event-lag refresh occupies the single writer for a whole library, so unrelated foreground mutations and queue heartbeats wait. Existing WAL readers can still see the prior committed generation; do not claim all reads are SQLite-blocked. Changed-media parsing can retain a reader connection during file work. No duration is measured by this audit.

Concrete fix in #683: bound full-refresh writes through a staged generation or bounded upserts and a short atomic publication step. Keep a complete old timeline available until publication; do not expose partial counts/groups. Release reader connections before media parsing; retain fingerprint-based EXIF/Sidecar reuse. Skip unchanged full refreshes without losing deleted-row detection or #470's Files-before-Photos completion order.

Tests: a 50k library refresh yields writer access to another User's mutation between batches; timeline reads see a complete old or new generation, never mixed groups/counts; an unchanged restart skips whole-library rewrites; lost events and offline restores still reconcile. Compare startup, lag refresh and concurrent small-write latency on the locked HDD emulator. Search for #683 before assigning another Photos background job.

Additional disk IO / writer occupancy evidence from perf-arch-io (#663) for #683. Source origin/dev `c4a61e8cf090170f35b1bed3350d9de20c83ecd5`; merge-round-7a does not change Photos index.rs. `crates/plugins/photos/src/index.rs:264` refreshes all viewers on the Files reconciliation completion event. `refresh_user:345` forces a rebuild (`true`). `refresh_user_if_changed:778` holds a shared refresh lock across the whole library; :825 streams library rows while changed media can await parse_media on a blocking thread (:1161). It then acquires the ONE shared Index writer at :874 and, before :970 commit, upserts every media item, deletes/recreates all group memberships and day counts and upserts all groups. This full-refresh transaction has no row/byte/time cap, even when the library did not change, because force_rebuild bypasses the unchanged return at :854. The incremental path already uses bounded affected-row batches and should be reused. That does not bound the full startup/lag/root-change path. Reasoned impact: a large startup or event-lag refresh occupies the single writer for a whole library, so unrelated foreground mutations and queue heartbeats wait. Existing WAL readers can still see the prior committed generation; do not claim all reads are SQLite-blocked. Changed-media parsing can retain a reader connection during file work. No duration is measured by this audit. Concrete fix in #683: bound full-refresh writes through a staged generation or bounded upserts and a short atomic publication step. Keep a complete old timeline available until publication; do not expose partial counts/groups. Release reader connections before media parsing; retain fingerprint-based EXIF/Sidecar reuse. Skip unchanged full refreshes without losing deleted-row detection or #470's Files-before-Photos completion order. Tests: a 50k library refresh yields writer access to another User's mutation between batches; timeline reads see a complete old or new generation, never mixed groups/counts; an unchanged restart skips whole-library rewrites; lost events and offline restores still reconcile. Compare startup, lag refresh and concurrent small-write latency on the locked HDD emulator. Search for #683 before assigning another Photos background job.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
kayg/calternal#683
No description provided.