Benchmarks
Separate measurements for latency, ingress throughput and the money path. Read the load, date and boundary before comparing a number.
Committed matching latency · 2026-07-25
At 50,000 offered orders/s, the three-node cluster acknowledged 999,869 orders. The same tool recorded two different boundaries:
| Measurement | p50 | p99 |
|---|---|---|
| Successful offer → first committed status back | 307.97 µs | 615.42 µs |
| Enqueue → local ingress publication accepted | 0.35 µs | 0.83 µs |
The committed measurement covers replication, matching and the return status after the successful offer. It excludes HTTP/API ingress and the Assets Engine hold. Ingress publication is a local handoff; it is not exchange latency. The roughly 880× difference explains the measurement boundary, not a speedup.
Source: matching load-generator measurement and method, PR #161. This is a closed measurement window, not evidence for latency at 800k offers/s. The published run does not establish a coordinated-omission-safe service latency distribution.
Ingress throughput · 2026-07-02
| Driver setup | Offered rate | Ingress acceptance |
|---|---|---|
| Tuned OS, prod drivers | 800,000 ingress offers/s | 100.00% in this run |
| Dev drivers, backoff | ~148,000 ingress offers/s | 100.00% in this run |
Environment: Intel i7-13700K, 32 GB RAM, Linux 6.17, Java 21, Aeron 1.51.0. Three cluster nodes used loopback UDP, external media drivers, pinned cores and tmpfs archives. There was no network between physical hosts.
“Acceptance” means AeronCluster.offer accepted the ingress publication; it does not itself count durably acknowledged or settled orders. The source also contains backpressure in lower-rate runs. Those short windows do not determine a stable maximum or a guaranteed operating envelope.
Source: July 2 baseline, environment, limitations and reproduction method. Its later “500k–600k clean envelope” statement conflicts with its own 800k row; no such capacity boundary is claimed here.
Money path · v0.5.0-beta, July 2026
The Assets release reports an improvement from about 4,400 to 120,000 orders/s with the fund-hold gate before matching. Its benchmark driver has no OMS in the loop. This is a separate result from matching ingress throughput, and is not a REST throughput figure.
Source: Assets Engine v0.5.0-beta release. The release does not supply a complete percentile table and matching run manifest for this claim, so those values are left unspecified here.
Failure testing
The OMS failover E2E starts a real three-node matching cluster, a single-node Assets Engine, a settlement bridge, OMS and PostgreSQL. It kills the matching leader during load, checks that a different node takes leadership, continues placing orders, then checks fills, balances, positions and ledger conservation.
This tests matching-node loss and recovery on one machine. It does not prove tolerance to host loss, a replicated Assets deployment, every network partition, or a numerical recovery-time guarantee.
Reproduce and compare
- Start with the working local Quickstart to verify build and correctness. Its small buffers and shared threads are for evaluation.
- For a performance run, use a dedicated test environment and the baseline’s linked harness. Record source SHAs, CPU, memory, disk, JVM, transport, driver profile, topology and offered load.
- Warm up the JVM, retain histogram/sample counts, and report offered, accepted, acknowledged and settled work separately. Keep the same metric boundary in before/after comparisons.
- Repeat steady-state windows and run an endurance test with disk-backed archives before choosing an operating limit. Publish overload and failure behavior alongside latency and throughput.