┌── run-from-your-bot ──┐
Stop trusting marketing numbers.
Measure us from your bot.
Free CLI tool. Runs where your bot lives. Reports two numbers separately: what your network looks like, and what our server actually does. No signup, no telemetry, no data collection beyond the output you choose to share.
install (linux + macOS, amd64 + arm64)
curl -sSL https://streamsuite.io/bench/install.sh | sh~5 MB static Go binary. No dependencies. Source on GitHub · All releases
direct download · v1.0.1
Prefer not to curl | sh? Download the archive directly.
After download: tar -xzf streamsuite-bench_*.tar.gz (or unzip on Windows) → ./streamsuite-bench. Verify the binary with the SHA-256 checksums.
why two numbers
Network and server are not the same thing.
Most RPC vendors quote one mushy latency number that mixes their server speed with your network distance. That number is marketing, not engineering. The bench tool reports them separately:
server processing
How fast our Ashburn node answers your RPC call once it arrives. This is what we SLA.
network RTT
The physical distance between your machine and our Ashburn box. Physics. Not something we (or anyone) can SLA away.
If you run your bot in us-east-1, both numbers are small. If you run it in Singapore, network is big and you’ll know to colocate or pick a different vendor. We’d rather you self-disqualify than discover it after you paid.
sample output
What you’ll see.
us-east bot → PASS
$ streamsuite-bench
detected location: us-east-1 (Reston, VA)
1000 × eth_blockNumber → va-bsc-01.streamsuite.io
Network RTT (TCP-SYN → :443): 1.12 ms
Server processing (RPC − network): 0.58 ms
----------------------------------------------
Total RPC RTT (p99): 1.70 ms
Server SLA target (p99 ≤ 5 ms): PASS (0.58 ms)vs. your current RPC
$ streamsuite-bench --vs https://your-current-rpc.example/<YOUR_API_KEY>
endpoint p50 p99 max
streamsuite (ashburn) 0.8 ms 1.7 ms 3.2 ms
your-current-rpc.example 11.3 ms 42.1 ms 89.0 ms
Verdict: streamsuite is 14× faster (p50), 17× faster (p99).APAC bot → server still passes, but network dominates
$ streamsuite-bench
detected location: ap-southeast-1 (Singapore)
1000 × eth_blockNumber → va-bsc-01.streamsuite.io
Network RTT (TCP-SYN → :443): 218.3 ms
Server processing (RPC − network): 0.61 ms
----------------------------------------------
Total RPC RTT (p99): 218.9 ms
Server SLA target (p99 ≤ 5 ms): PASS (0.61 ms)
Note: total latency dominated by network distance.
Colocate within US-east for sub-5 ms total.methodology
What we measure. What we don’t.
- Measured: RTT for
eth_blockNumberover HTTPS, plus TCP-SYN handshake tova-bsc-01.streamsuite.io:443. Results stay on your machine. - Not measured: DNS lookup time (resolved once, cached), browser/proxy overhead, your bot’s internal processing. The tool times TCP-SYN → JSON-RPC response on the same keep-alive TCP connection.
- SLA boundary: our SLA covers the server processing number only — second line in the output. Network RTT is not a refund condition. See refund policy.
- Rate limit: the public benchmark API key embedded in the binary is capped at 1,000 requests per IP per day, read-only methods only.
See the numbers? Skip the trial.
We don’t run a free tier. We don’t do free trials. The bench tool is how you decide. If we look right for your bot, start a plan; if not, you saved both of us a dispute.
quick answers
Is the binary safe?
Static Go binary, MIT-licensed source on GitHub, no network calls outside the benchmark target and a single GitHub release lookup. Easy to audit, easy to sandbox.
Does it send data back to you?
Only the RPC calls themselves — same as if you curl’d the endpoint yourself. We do not collect, store, or share your output.
Does it work for Ethereum / Base / Arbitrum?
Not yet. BSC only at launch. Other chains follow the same model — request access at /pricing.
Browser version?
We have one at home for a quick first impression, but JS fetch adds 1–3 ms of overhead and can’t isolate server vs network. The CLI is the honest version.