Skip to content

Performance

Archived benchmark results. They were produced by benchmarks/egernia-performance, a cluster benchmark harness this repository used to carry, which measured the service, PostgreSQL as the data grows, replica scaling and autoscaling behaviour separately — because they fail separately.

That harness has been removed in favour of the timing guards in the integration suite and the CPU microbenchmarks (see Performance testing). The measurements below stand as records; the make benchmark-* targets and egernia_bench commands the pages reference no longer exist, and the harness itself is in the git history.

Each cluster run below is published in full: the graphs, per-measurement CSV, and provenance needed to know whether two runs are comparable at all. Focused capacity checks record smaller local experiments separately.

Focused capacity checks

Latest cluster run

20260825T180219Z-f8b21fc4-worker-sweep · CSV

Latest by family

family run datasets
db-scaling 20260825T005436Z-b450b0a9-db-scaling D1 D2 D3 D4
fixed-scaling 20260824T014320Z-a5058118-fixed-scaling D2
keda 20260824T140134Z-bf7e4b24-keda D1
profile 20260825T163627Z-034d69ba-profile D1
tap-compare-scaling 20260912T225808Z-d43b538d-tap-compare-scaling (the three-server scaling comparison: egernia vs DaCHS vs argus at 8/16/24 CPUs — the paper's figure) · 20260905T073915Z-5f145831-tap-compare-scaling (egernia vs DaCHS, superseded) D1
tap-compare 20260911T065452Z-41bfc513-tap-compare (the final three-way comparison, Table A — one-process parity: egernia vs DaCHS vs argus) · 20260912T025434Z-41bfc513-tap-compare (Table B — equal CPU: the same three servers, egernia with eight workers) · 20260908T061813Z-f1cf2c25-tap-compare (egernia vs argus, equal CPU) · 20260906T145338Z-7aa14f6a-tap-compare (egernia vs argus) · 20260903T160103Z-8fec0e75-tap-compare (egernia vs DaCHS) D1
worker-sweep 20260825T180219Z-f8b21fc4-worker-sweep D1

All runs

Reading these numbers

  • A figure without an interval is one measurement. Intervals across repetitions are 95% Student-t; percentile intervals within a run are percentile bootstrap.
  • LOAD_GENERATOR_BOUND on any measurement means the client was the limit, and nothing else from that measurement describes the service.
  • A run marked invalid is published anyway, with the reason. The samples are the evidence of what went wrong.
  • Two throughputs closer together than the run-to-run variability plot shows are the same throughput.