Repository navigation
Conversation
…e time (#308) Every read of a persistent rule (a query, a standing query's refresh, a proof, a guarded write) whose dependency closure holds a deployed rule now counts one rule evaluation; reads served from a view and view maintenance time get their counters too, at zero until maintained views land. All three are exported on /metrics/prometheus as inputlayer_rule_evaluations_total, inputlayer_view_reads_total and inputlayer_view_maintenance_us_total.
…yed rules (#308) perf-gate views runs the incremental-views review's Section 4 matrix: 10K/100K/1M edges, idle reads of a non-recursive and a recursive view bound and unbound, and closed-loop write phases with 0, 1 and 100 unbound subscribers, 1/10/100/1,000 keyed subscribers, keyed subscribers of the recursive view and a 200-rule catalog. Each phase reports ack, write->delta and the ad-hoc read during writes (p50/p99), server CPU per write, frames per write, RSS, and the engine's rule evaluations per read and per write from /metrics/prometheus. make bench-views and make bench-views-remote (perf-gate-remote.sh --bench views, under the benchmark host's shared lock) run it; the full suite runs it report-only as the Views benchmark job alongside the perf gate.
#308) The incremental-views review's differential-dataflow program (report Appendix A.7) as a Criterion bench: the views benchmark's graph and three rules kept as arrangements on one worker; one insert, retraction and non-hot insert propagated through every view, and a key lookup, at 10K, 100K and 1M edges (VIEW_BENCH_EDGES).
Contributor
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Intent
please leave this query batching functionliaty just refactor things so its clear and optimized for this ... auto materialize needs to be default mode of operation where rules get deployed as views and everything else is a query .. make the docs true with the correct systems design ... this is not accceptable state for production readiness (Context: implement #308 exactly as written.)
Issue #308 as written, "Baseline benches and counters for the view work (V1)", part of epic #305 (persistent rules are incrementally maintained views; everything else is a query):
Problem. No bench measures the cost of a write vs graph size, rule count and subscriber count, and no counter tells whether a read of a deployed rule evaluated it. The review's numbers (report Section 4) came from an ad-hoc harness.
Target. (a)
perf-gate views: the Section 4 matrix (10k/100k/1M edges; unbound/keyed subscribers 1/10/100/1,000; recursive and non-recursive views; 200-rule catalog) as a perf-gate scenario with p50/p99 write->delta, ack, ad-hoc read during writes, server CPU per write and RSS; (b) a criterion bench of the maintained-view micro-benchmark (report A.7) as the headroom reference; (c) countersview_reads,rule_evaluations,view_maintenance_usexported on/metrics/prometheus.Acceptance.
make bench-views-remoteruns under the shared lock and reproduces the Section 4 tables within noise;rule_evaluationsincrements once per deployed-rule read today (so V9 can assert 0); the bench is wired intofull-suite.ymlas perf-gate-only.Size M. Dependencies none. Order slot 1.
What Changed
/metrics/prometheus:inputlayer_rule_evaluations_total,inputlayer_view_reads_totalandinputlayer_view_maintenance_us_total. They live in the newsrc/execution/view_counters.rs. When a query, standing-query refresh, proof or guarded write depends on at least one persistent rule, the snapshot plan path counts one rule evaluation for that read (cached plans and dirty-session reads included). The other two counters stay at 0 until views exist. Unit, plan-cache andtests/e2e_reactive/views.rstests cover this, and the REST API and query-profiling guides document the counters.perf-gate viewsscenario (perf-gate/src/views/mod.rs). It reproduces the Section 4 matrix of the incremental-views review: 10k/100k/1M edges; recursive and non-recursive rules; no subscribers, unbound subscribers and keyed subscribers (1–1,000); and catalogs grown by 50 and 200 unrelated rules. For each write it reports p50/p99 ack, write→delta and ad-hoc read latency, plus server CPU, RSS and the counter deltas. A delta that never arrives fails the run; latency is reported but never fails it.scripts/bench-views.sh,make bench-views/make bench-views-remote(which runs on the benchmark host under the shared lock) and a report-onlyviews-benchjob infull-suite.ymlthat also runs withperf_gate_only. Also adds the Criterion benchbenches/view_maintenance_benchmarks.rs, which measures the maintained-view micro-benchmark on differential dataflow as the headroom reference.Risk Assessment
✅ Low: Most of the change is new benchmark tooling (
perf-gate views, a criterion bench, scripts and a report-only CI job), and the engine change only adds process-wide atomic counters. Every read path counts exactly one rule evaluation: the query path, the plan-cached path, a session with session facts (the previous round's uncounted provenance baseline holds, and an e2e test that would have seen 2 before the fix covers it),.why, subscriptions and guarded writes.Testing
I drove a real release server over WebSocket and scraped /metrics/prometheus around each read. The three counters are exported and start at 0. Each deployed-rule read adds exactly 1 to rule_evaluations, including dirty-session reads. Base and session-only reads add 0. With the F1 fix reverted, dirty-session reads add 2, so the check catches the regression.perf-gate views(10k and 100k edges) andscripts/bench-views.shproduced the Section 4 tables (ack, write->delta, read during writes, CPU per write, RSS, counter columns) with no late deltas. The criterion headroom bench and the e2e views tests passed. The full-suite views-bench job was only checked by parsing the workflow YAML, not run live.make bench-views-remotegot as far as the benchmark host and was correctly refused by the shared lock because another session's benchmark held it, so the tables were not reproduced on that host. Local latencies were measured on a busy dev box and are not comparable to the review's numbers.make bench-views-remote REV=HEADreached sam-dev-benchmarks, but the shared lock refused the run (exit 4) because another session's perf-gate run h…Evidence: Live counter transcript at HEAD (one evaluation per deployed-rule read, including dirty session)
Evidence: Live counter transcript with the F1 fix reverted (dirty-session reads count 2)
Evidence: Counter driver script
Evidence: perf-gate views summary (10k/100k edges)
Evidence: perf-gate views result.json
~/.no-mistakes/evidence/01M46NN53TNDNEBVR0VME6S3Y3/bench_views_script_summary.md)Evidence: Criterion view_maintenance bench output
~/.no-mistakes/evidence/01M46NN53TNDNEBVR0VME6S3Y3/e2e_views.txt)~/.no-mistakes/evidence/01M46NN53TNDNEBVR0VME6S3Y3/bench_views_remote.log)~/.no-mistakes/evidence/01M46NN53TNDNEBVR0VME6S3Y3/full_suite_jobs.txt)Pipeline
Updates from git push no-mistakes
✅ **intent** - passed
✅ No issues found.
🔧 **Rebase** - 1 issue found → auto-fixed ✅
gui/lib/docs-bundle.ts- merge conflict rebasing onto origin/main🔧 Fix applied.
✅ Re-checked - no issues remain.
🔧 **Review** - 2 issues found → auto-fixed ✅
src/storage_engine/snapshot.rs:431-rule_evaluationscounts some reads twice. Everyrun_programcall records an evaluation. A query in a session that holds session facts or rules (the slow path insrc/protocol/handler.rs:3858-3893) runs the session program throughexecute_program_with_session_facts_profiled, which records one. When there are results, it then runs the provenance baselinesnapshot.execute_program_with_rules(query), which records a second. Example: a session asserts a session fact, then reads?hop2(0,Z)with a deployedhop2and gets non-empty results; the counter goes up by 2. This breaks the intent's "rule_evaluations increments once per deployed-rule read today" and the docs' "A read counts once" (docs/content/docs/guides/query-profiling.mdx:176,src/execution/view_counters.rs:575-578). The same class appears atsrc/protocol/handler.rs:3862and:3891(one read, two counted runs). The e2e case labelled "session rule over base facts" (tests/e2e_reactive/views.rs:983,?edge(X, Y), X > 2) uses no session state, so it never reaches the slow path and doesn't cover this. Fix: run the provenance baseline through a non-counting variant, or record the evaluation once at the read boundary instead of perrun_program. Then add an e2e case that uses a dirty session.scripts/bench-views.sh:410- Simplification: the before/after comparison mode (--baseline-revinscripts/bench-views.sh:410-427, plus--compare/--compare-labeland the baseline/candidate arms inperf-gate/src/views/mod.rs:97-101,316-328) builds and measures a second server from git archive. Issue Baseline benches and counters for the view work (V1) #308 asks for the Section 4 matrix as a perf-gate scenario,make bench-views-remoteunder the lock, the criterion bench and the counters. Nothing in it requires comparing two binaries in one run. Recommend removing the comparison mode unless you want to keep it, for parity with bench-sessions.🔧 Fix applied.
1 warning still open:
scripts/bench-views.sh:410- Simplification: the before/after comparison mode (--baseline-revinscripts/bench-views.sh:410-427, plus--compare/--compare-labeland the baseline/candidate arms inperf-gate/src/views/mod.rs:97-101,316-328) builds and measures a second server from git archive. Issue Baseline benches and counters for the view work (V1) #308 asks for the Section 4 matrix as a perf-gate scenario,make bench-views-remoteunder the lock, the criterion bench and the counters. Nothing in it requires comparing two binaries in one run. Recommend removing the comparison mode unless you want to keep it, for parity with bench-sessions.✅ No issues found.
✅ **Test** - passed
✅ No issues found.
scripts/bench-views.sh --edges 10000,100000 --writes 10 --reads 5 --keyed 1,10,100 --recursive-keyed 1,10 --filler-rules 50,200(real release server, exit 0)scripts/bench-views.sh --baseline-rev bcbd9d3c --edges 10000 --writes 5 --reads 3 --keyed 1,10 --recursive-keyed 1 --filler-rules 50(compare mode, exit 0)Manual: started target/release/inputlayer-server on a disposable config/data dir (port 18731), drove IQL steps with inputlayer-client and scraped /metrics/prometheus with curl before and after each stepcargo test --test e2e_reactive views::(3 counter e2e tests, incl. dirty-session read counts once)VIEW_BENCH_EDGES=10000,100000 cargo bench --bench view_maintenance_benchmarks -- --warm-up-time 1 --measurement-time 3 --noplotParsed .github/workflows/full-suite.yml with PyYAML: checked the views-bench job's needs/if relative to the gate and the other jobs✅ No issues found.
make bench-views-remote REV=HEADreached sam-dev-benchmarks, but the shared lock refused the run (exit 4) because another session's perf-gate run h…Live driverdrive_counters.mjs(Node WebSocket client) against a disposable releaseinputlayer-server(temporary data dir, port 18731): scraped /metrics/prometheus before and after reads of base relations, deployed non-recursive and recursive rules, two deployed rules in one read, ad-hoc queries over base facts, and session-fact and session-rule readsAdversarial F1: rebuilt the server withexecute_program_with_rules_uncountedreverted toexecute_program_with_rulesin src/protocol/handler.rs (restored afterwards), then drove the same reads on port 18732perf-gate views --edges 10000,100000 --writes 10 --reads 3 --keyed 1,10,100 --recursive-keyed 1,10 --filler-rules 50,200(exit 0, 0 late)scripts/bench-views.sh --edges 10000 --writes 5 --reads 2 --keyed 1,10 --recursive-keyed 1 --filler-rules 50 --server-cpus 8-31(CI entry point, exit 0)VIEW_BENCH_EDGES=10000,100000 cargo bench --bench view_maintenance_benchmarks -- --warm-up-time 1 --measurement-time 3 --noplotcargo test --release --all-features --test e2e_reactive views::(3 tests drive the real server binary)make bench-views-remote REV=HEAD(reached sam-dev-benchmarks; refused at the shared lock, exit 4)Parsed .github/workflows/full-suite.yml with PyYAML to check the views-bench job's needs/if and its run step✅ **Document** - passed
✅ No issues found.
✅ No issues found.
✅ **Lint** - passed
✅ No issues found.
✅ No issues found.
✅ **Push** - passed
✅ No issues found.
✅ No issues found.