Performance

This page presents benchmark results from convergence-loadgen against convergence-server. Numbers are updated as new scenarios are tested.

Test environment

Component	Detail
Machine	Apple M1 Pro, 16 GB unified memory
OS	macOS (ARM64)
Setup	Server and loadgen collocated on the same machine

All benchmarks use release builds (--release).

Write throughput (no subscribers)

Pure write workload with no active subscribers. Measures the server’s ingress and convergence engine throughput in isolation from fanout costs.

Configuration:

Parameter	Value
Workers	9 (each a separate source)
Entity pool	10,000 (Player schema)
Operation mix	70% ASSERT / 20% PATCH / 10% RETRACT
Rate limit	None (unlimited)
Subscribers	0

Results:

Metric	Value
Aggregate throughput	3.7M ops/sec
Per-worker average	~411K ops/sec
Per-worker range	364K — 477K ops/sec
Total operations	70.7M
Errors	0

The design target is 200,000 ASSERT operations per second per partition on a single core. This benchmark exceeds that target per-worker, with a mixed operation workload rather than pure ASSERTs.

Caveats: Server and loadgen share CPU and memory. No subscribers means no fanout overhead. No concurrent read workload.

cargo run --release -p convergence-loadgen -- \
  --server 127.0.0.1:3727 \
  --workers 9 \
  --entities 10000 \
  --schema player

Write throughput with subscribers

Not yet measured.

Adds active subscribers to measure the impact of fanout on write throughput and to capture notification latency.

Parameter	Planned
Write workload	Same as above
Subscribers	1, 10, 100
Metrics	Write throughput degradation, notification rate

Design target: notification latency within one coalescing window of the last ASSERT.

# 9 writers + 10 subscribers
cargo run --release -p convergence-loadgen -- \
  --server 127.0.0.1:3727 \
  --workers 9 \
  --subscribers 10 \
  --entities 10000 \
  --schema player

# 9 writers + 100 subscribers
cargo run --release -p convergence-loadgen -- \
  --server 127.0.0.1:3727 \
  --workers 9 \
  --subscribers 100 \
  --entities 10000 \
  --schema player

Point read latency

Not yet measured.

Measures QUERY response time under varying write load.

Parameter	Planned
Background write rate	0, 100K, 200K ops/sec
Reader	Dedicated client issuing point QUERYs
Metrics	p50, p99, p999 latency

Design target: 5 microseconds at p50, 20 microseconds at p99.

Subscriber bootstrap

Not yet measured.

Measures time for a new subscriber to receive the full initial state of a large entity set.

Parameter	Planned
Entity count	100,000 pre-populated
Metrics	Time to receive complete bootstrap

Design target: under 2 seconds for 100,000 entities.

# Step 1: populate 100K entities
cargo run --release -p convergence-loadgen -- \
  --server 127.0.0.1:3727 \
  --workers 4 \
  --entities 100000 \
  --schema player \
  --mix 100/0/0 \
  --duration 10s \
  --quiet

# Step 2: subscribe with bootstrap and measure
cargo run --release -p convergence-loadgen -- \
  --server 127.0.0.1:3727 \
  --subscribers 1 \
  --bootstrap \
  --schema player \
  --duration 30s \
  --quiet

Coalescing efficiency

Not yet measured.

Measures the ratio of incoming writes to WAL flush writes under hot-entity workloads.

Parameter	Planned
Write pattern	Small hot set (10% of entities receiving 90% of writes)
Metrics	Incoming ASSERTs per WAL flush write

Design target: 10:1 or better for entities updating more than 10 times per coalescing window.

Reproducing these benchmarks

# Start the server
cargo run --release -p convergence-server

# Run the write throughput benchmark (scenario 1)
cargo run --release -p convergence-loadgen -- \
  --server 127.0.0.1:3727 \
  --workers 9 \
  --entities 10000 \
  --schema player

# Run with subscribers (scenario 2)
cargo run --release -p convergence-loadgen -- \
  --server 127.0.0.1:3727 \
  --workers 9 \
  --subscribers 10 \
  --entities 10000 \
  --schema player

Run cargo run -p convergence-loadgen -- --help for all options including --rate, --mix, --hot-pct, --duration, --quiet, --subscribers, --bootstrap, and --include-prev.