Reamer Stream Benchmarks

Test system

Why no competitor comparison

The reamer_py vs. Backtrader/LEAN comparison measures reamer_py head-to-head against named, freely-runnable competitors in the same category. Reamer Stream isn't positioned against an equivalent named rival — there's no widely-recognized "OHLCV socket streaming server" product it's being sold against. The numbers below are absolute figures for a reader asking "is this fast enough for my use case," not a competitive claim against anything else.

Methodology

• Single-threaded server. The protocol docs' Concurrency semantics section documents that reamer-stream is single-threaded and fully serializes every request. The round-trip figure below is one connection driving the server as fast as it can; Concurrent connections measures what happens with more.
• Synthetic data. Bar count is all that matters to the code path measured here — bars are generated locally with a fixed, deterministic pattern, not real price action.
• The real product path, not a shortcut. Every number below comes from a live reamer-stream subprocess this benchmark starts itself — wire encoding, epoll dispatch, and a real AF_UNIX round trip all included, not an in-process measurement of the engine underneath it.
• No warm-up runs are discarded — the reported numbers are directly what one full benchmark run measured.

Socket round-trip latency

One client connection, one ticker (100 bars) ingested once, then 1,000 QueryHistorical round trips (send → server epoll dispatch → receive), timed individually:

This is the number that actually matters for an external tool's perceived responsiveness — includes wire encoding/decoding and the epoll dispatch loop, not just the in-process engine call above.

Concurrent connections

The round-trip figure above is one connection. reamer-stream is single-threaded — every request is fully serialized, no matter how many clients are connected (see Concurrency semantics) — so the real question is what a second, third, or thirty-second concurrent client actually costs. Real OS processes as clients (not threads — no client-side interpreter contention to muddy the numbers), each opening its own connection and sending QueryHistorical as fast as it can, same 100-bar payload as above. Server CPU usage is sampled throughout via /proc, so the table below distinguishes "the server is genuinely doing the work" from "clients just aren't sending fast enough to prove anything."

One client can't even saturate the server — 63.5% of one core, because the client itself spends time waiting on its own round trip between requests. The moment a second client is added, the server pegs one core solid (~97–100%) and stays there through 32 concurrent clients, while aggregate throughput holds flat around 70,000–76,000 queries/s — a real ceiling set by the server's single-threaded dispatch loop, not by how many clients are asking. It's higher than the one-client number above for the same reason a busy checkout line moves more items/minute than an empty one: the server never sits idle waiting on any one client's next request.

What scales instead of throughput is queueing: with the server's total capacity roughly fixed, each additional concurrent client waits behind however many others are already in line. Implied per-client latency (concurrent clients ÷ aggregate throughput) works out to roughly 26 µs at 2 clients, ~450 µs at 32, ~1.1 ms at 64 — a direct, linear consequence of one thread serving everyone, not a sign of anything misbehaving.

Reading these numbers honestly

• These are throughput/latency numbers on synthetic data, on one ultrabook-class laptop CPU (8 cores) — not a comparison against any other product.
• ~19 µs average round-trip latency and ~52K queries/s reflect one connection driving the server as fast as it can — the actual reamer-stream product experience, wire framing and epoll dispatch included.
• The concurrency numbers used real OS processes as clients specifically to rule out a client-side interpreter bottleneck standing in for a server one — a single-client control run (63.5% server CPU, not saturated) confirmed the harness itself wasn't the limiting factor before trusting the multi-client results.
• The 64-client dip (59,489 q/s, down from the 70–76K plateau) is the one number here we haven't fully run to ground — server CPU was still ~99% at that point, so it looks like client-side process-scheduling contention on an 8-core machine running 64 Python processes, not a server regression, but that's not conclusively proven.
• The round-trip figure is reproducible with eval-kit-stream/benchmark_your_machine.py — the same script sent with every evaluation license. The concurrency sweep is an internal characterization test, not yet part of that shipped script.