V1 Performance Targets

This page defines the first explicit performance budget loop for a NOOSChain v1 release candidate. The numbers below are release targets, not consensus rules. They should be adjusted only after measuring the expected production workload on production-like hardware.

Workload Envelope

Use these assumptions when running the v1 benchmark matrix unless the deployment owner signs off different values:

• 3 validator nodes and at least 1 observer.
• HashiCorp-Go Raft for production consensus; Noosraft remains covered for deterministic development and compatibility.
• Normal committed-block cadence target: 2 seconds.
• Peak-but-normal block size profiles:
  • medium: 50 transactions per block, 4 public indexes per record.
  • large-block: 200 transactions per block, 4 public indexes per record.
  • many-indexes: 100 transactions per block, 16 public indexes per record.
• Snapshot budget is projected to 1,000,000 record_indexes rows.
• Payload backfill budget assumes authorized ciphertext fetch from a healthy peer.
• Recovery budgets are separate from steady-state block commit latency.

Draft Budgets

The machine-readable source of these numbers is test/benchmarks/v1-readiness/v1-performance-budgets.json.

Area	Budget
Block commit p95	<= 2,000 ms
Block commit p99	<= 5,000 ms
Execution state apply p95	<= 500 ms
State-root net apply p95	<= 500 ms
Replay benchmark duration	<= 600,000 ms
Snapshot export, projected 1M rows	<= 600,000 ms
Snapshot verify, projected 1M rows	<= 600,000 ms
Snapshot import, projected 1M rows	<= 1,200,000 ms
Sync/catch-up total duration	<= 600,000 ms
Sync/catch-up throughput	>= 4 blocks/sec
Payload backfill throughput	>= 250 fetched payloads/sec
Sidecar restart recovery	<= 30,000 ms
Sidecar checkpoint load	<= 30,000 ms
Sidecar checkpoint export	<= 30,000 ms

How To Run

Run the fast local smoke first:

$env:NOOS_V1_READINESS_FAST="true"
npm run benchmark:v1-readiness
npm run benchmark:v1-readiness:check
Remove-Item Env:\NOOS_V1_READINESS_FAST

Run the full matrix on production-like hardware:

npm run benchmark:v1-readiness
npm run benchmark:v1-readiness:check

The benchmark writes:

• benchmark-results/v1-readiness/v1-readiness-benchmark-*.json
• benchmark-results/v1-readiness/v1-readiness-budget-check-*.json
• raw child benchmark reports under benchmark-results/v1-readiness/raw/

In NOOS_V1_READINESS_FAST=true mode, the checker treats snapshot timings as small-file smoke measurements instead of projecting them to 1M rows, and relaxes the sync throughput floor so fixed startup/server overhead does not fail the smoke. Snapshot-bootstrap sync is judged by total duration rather than raw blocks/sec, because the benchmark intentionally includes snapshot export/import work. Use the default full matrix for actual release budget sign-off.

To check a specific report:

$env:NOOS_V1_READINESS_REPORT="C:\path\to\v1-readiness-benchmark.json"
npm run benchmark:v1-readiness:check
Remove-Item Env:\NOOS_V1_READINESS_REPORT

Interpreting Results

Passing the budget check means the measured matrix fits the current draft v1 budgets on the machine where it ran. It does not replace soak or hardness tests.

Failure means one of three things:

• the budget is too strict for the intended v1 workload;
• the benchmark machine is not representative;
• the implementation needs optimization before v1.

Do not loosen budgets to make a release pass without recording why. The usual workflow is:

1. Inspect the failed raw benchmark report.
2. Decide whether the workload profile or budget was wrong.
3. If the budget is still desired, optimize the failing path.
4. Rerun benchmark:v1-readiness and benchmark:v1-readiness:check.

Soak And Hardness

The budget matrix is the measurement gate. Confidence still requires:

npm run test-e2e:hardness-multiple-producers-noosraft
npm run test-e2e:hardness-multiple-producers-hashicorp-go
npm run soak:multiple-producers-noosraft
npm run soak:multiple-producers-hashicorp-go

For release candidates, run soak long enough to include leader failover, observer catch-up, payload backfill, sidecar restart, snapshot export/import, and governance/runtime membership workflows. Overnight soak remains a separate release-candidate activity.