Performance
Fanout does not publish a throughput headline. That is a decision, not an omission, and it is worth stating plainly because the absence otherwise reads as something to be embarrassed about.
The number that used to be here
Section titled “The number that used to be here”An earlier two-vCPU report quoted specific ingest and query figures. It was withdrawn before the first public release, for reasons that had nothing to do with the numbers being unflattering:
- Its raw JSON reports and the exact benchmark-driver commit were not retained.
- Its ingest run predated mandatory ingest authentication, so it measured a path the current release does not have.
The prose was detailed. Detail is not provenance — a result nobody can reproduce from the artifacts that produced it is an anecdote with decimal places.
What a published result would have to carry
Section titled “What a published result would have to carry”Before any figure goes back on this page, it has to ship with:
- the Fanout image digest and the benchmark-driver commit;
- complete machine, network, container and Fanout configuration;
- the raw
ingest.jsonandmixed.jsonreports from that same run; - an authenticated OTLP path matching the current release;
- repeated runs, or an explicit note that it is a single run;
- separate ingest-only and mixed read/write results.
Measure your own instead
Section titled “Measure your own instead”cmd/bench is the supported load generator. It sends traces, metrics and logs,
ramps to find the ingest boundary, and confirms the result at the rate it found.
It can add authenticated dashboard reads on top, which is the part that matters:
ingest and query contend for the same write gate, so an ingest-only number
overstates what an instance does while anyone is looking at it.
Build it, create an ingest token through first-admin setup, then:
./bin/bench \ -endpoint localhost:4317 \ -token "$INGEST_TOKEN" \ -report ingest.json./bin/bench -help covers fixed-rate, query-load and metrics options.
What to watch instead of a headline
Section titled “What to watch instead of a headline”For capacity, the useful signals are the ones an instance emits about itself: telemetry drops, sustained query latency, readiness failures, and free disk. Troubleshooting lists where they are.