┌── stress test ──┐

10-client stress test

Synthetic load test against a production-configured BSC full node. Ten simulated operators — one Full Node, three Mempool, six Real-Time — pounding the box for 60 seconds after a 2-minute warmup. Real numbers, real contention, real cross-talk.

⚠

This is a stress test, not production telemetry.

Load was generated by a Go harness on the production box itself (no network/TLS overhead). Ten concurrent “clients” are simulated goroutines. Real customer traffic adds your network distance to Ashburn, VA plus TLS overhead (~0.5–2ms for most connections). This page exists so you can verify the claims on the rest of the site against real measured numbers.

Conditions

Date: 2026-05-17 01:11 UTC
Test duration: 60s (after 2-min warmup)
Hardware: Dedicated bare-metal, NVMe storage, 10 GbE uplink
Location: Ashburn, VA · Tier-III datacenter
BSC client: geth, pruning mode, ~440ms blocks
Clients: 10 simulated operators (1×A + 3×B + 6×C)
Harness: Go, persistent HTTP/WS connections, ns-resolution timestamps
Transport: HTTP + WebSocket via loopback (no nginx/TLS)
Errors: 0
WS reconnects: 0
Missed blocks: 0
Dropped subs: 0

Group A

1× Full Node ($2,499/mo) — trace every tx every block

Worst-case Tier-3 customer: WebSocket subscribes to newHeads, fetches every tx in every block, fans out debug_traceTransaction across 8 concurrent worker goroutines. Forensic indexer / heavy MEV analyst pattern.

Method	n	p50	p90	p95	p99	p99.9	max	jitter
debug_traceTransaction	8,030	6.41ms	13.37ms	15.78ms	20.94ms	31.53ms	44.15ms	1.94ms
eth_call	300	0.24ms	0.34ms	0.39ms	0.50ms	1.15ms	1.15ms	0.04ms

Group B

3× Mempool ($999/mo)

MEV searcher / arbitrage bot pattern: eth_call · eth_getTransactionReceipt · eth_sendRawTransaction plus pending-tx WS subscriptions.

Method	n	p50	p90	p95	p99	p99.9	max	jitter
eth_call	2,688	0.23ms	0.33ms	0.37ms	0.43ms	1.74ms	1.88ms	0.01ms
eth_getTransactionReceipt	900	0.20ms	0.34ms	0.42ms	0.69ms	1.54ms	1.54ms	0.02ms
eth_sendRawTransaction	18	0.17ms	0.25ms	0.26ms	0.26ms	0.26ms	0.26ms	0.04ms

Group C

6× Real-Time ($399/mo)

DApp backend / indexer pattern: eth_call · eth_getBalance · eth_getLogs · eth_getTransactionCount.

Method	n	p50	p90	p95	p99	p99.9	max	jitter
eth_call	1,080	0.22ms	0.33ms	0.37ms	0.51ms	1.12ms	1.16ms	0.02ms
eth_getBalance	360	0.16ms	0.25ms	0.27ms	0.41ms	0.60ms	0.60ms	0.04ms
eth_getLogs	72	0.30ms	0.50ms	20.69ms	20.82ms	20.82ms	20.82ms	5.64ms
eth_getTransactionCount	360	0.15ms	0.20ms	0.22ms	0.26ms	0.29ms	0.29ms	0.02ms

Cross-talk

Does heavy debug load slow other tiers?

The same method (eth_call) measured simultaneously across all three groups. If the Full Node tenant's heavy tracing degraded shared resources, you'd see latency climb in Groups B and C. It doesn't.

Group	eth_call p50	eth_call p99
Group A — 1× Full Node ($2,499/mo) — heavy debug	0.24ms	0.50ms
Group B — 3× Mempool ($999/mo)	0.24ms	0.43ms
Group C — 6× Real-Time ($399/mo)	0.22ms	0.60ms

The Full Node tenant doing constant trace work has the same eth_call p99 as the lighter tiers. CPU pinning (geth on dedicated cores) and the 131 GB geth cache absorb the contention — tracing competes with itself, not with other operators' standard RPC.

Methodology & known weaknesses

1. Same-box generation.

Load was generated on the production node itself. This adds ~2–5% CPU overhead from the harness but avoids network noise. Remote clients will see TLS handshake + TCP RTT + nginx proxy on top (~0.5–2ms added once the connection is warm).

2. Loopback, not the 10 GbE NIC.

HTTP/WS traffic used loopback. The network bandwidth numbers in our monitoring reflect only BSC P2P, not RPC.

3. Measurement precision.

Go time.Now() uses CLOCK_MONOTONIC with ~20ns resolution on Linux. Per-sample overhead is <1µs — negligible relative to the signal we're measuring.

4. eth_sendRawTransaction uses intentionally invalid txs.

Measures the RPC round-trip and validation path, not actual mempool insertion or peer relay.

5. debug_traceTransaction is chain-tip only.

Trace state is available for the most recent ~128 blocks (~60 sec). The test traces transactions immediately after they land in the latest block, which is the realistic Full Node tier workload.

6. eth_getLogs p95 tail is real.

Note Group C's p95=20.7ms for getLogs. Log queries scan ranges and are I/O-sensitive. p50 stays under 1ms but the tail is wider than other methods. If your workload is getLogs-heavy, this is the metric to look at.

Want to test it from your own location?

Pricing page has a public latency tester — runs in your browser, no signup. Or run your own benchmarks against the live endpoint with a paid tier.

See pricing Read the docs