Back to benchmark

RPC Benchmark Methodology

This page explains exactly how the benchmark run is executed, what signals are measured, how verdicts are produced, and what the results do and do not mean.

In practice, endpoint performance is shaped by provider routing, freshness of chain data, repeated-request behavior, cache state, and rate limiting. This benchmark isolates those signals with one short, same-server, mainnet-only comparison run.

Benchmark signals

What this benchmark measures

A quick map of the signals behind every result: speed, stability, method support, throttling, freshness, and production risk.

Performance
p50p95p99

Speed distribution

How fast the endpoint responds across normal and tail requests.

Methods
eth_blockNumber98%
eth_getLogs74%

Method-level breakdown

Per-method performance, compatibility, and failures.

Limits
429

Rate-limit detection

Detect throttling before it becomes production traffic pain.

Reliability

0.8%

Errors

1.2%

Timeout

JTR

Stability

Failure behavior

Timeout rate, error types, and consistency are grouped into one reliability read.

Production

Your RPC

18.4M

vs

GetBlock

18.4M

Fresh node, low lag, clearer production verdict

Freshness and readiness

Freshness, sync lag, and production readiness turn raw metrics into a decision.

Core rules

Same conditions for both endpoints

Your endpoint and the GetBlock baseline are tested from the same benchmark server, during the same run window, with the same timeout and the same generated request sequence. The backend selects the GetBlock baseline endpoint for the benchmark server region, not for the visitor browser location; if that regional endpoint is unavailable, the report marks the fallback region in metadata. Every sampled method chosen for your endpoint is also sent to GetBlock, which keeps method mix and request count aligned. This keeps the comparison fair, but it also means the tool is not a multi-region synthetic benchmark.

Mainnet protocol match required

The public tool benchmarks mainnet endpoints only. A run is valid only when the pasted endpoint belongs to the selected protocol on mainnet, such as Ethereum mainnet vs GetBlock Ethereum mainnet. Testnet and devnet endpoints are blocked because they would produce misleading latency, freshness, and method-level results against a mainnet baseline.

Read-only requests only

The benchmark uses only read-only JSON-RPC calls. It never asks for private keys, seed phrases, wallet secrets, transaction signing, or write methods. The goal is to test speed and reliability without creating on-chain side effects.

Short point-in-time benchmark

The run is intentionally short. It is meant to reveal obvious differences in latency, reliability, compatibility, throttling, and freshness, not to certify an SLA or predict exact production throughput.

Latency measurement

How request latency is measured

Measured from the benchmark server

Latency is measured on the backend benchmark service, not in the visitor’s browser. The timer starts immediately before the HTTP RPC request is sent from the benchmark server and stops after the response is received and parsed.

Round-trip response time

The measured value is round-trip RPC time: network travel from the benchmark server to the provider, provider processing time, and network travel back. It is the latency your app would see only if your app ran from a similar region.

Successful latency is separated from failures

Only successful samples are used for p50, p95, p99, average latency, jitter, and max latency. Failed requests are counted separately in error rate, timeout rate, method compatibility, and findings.

Same request number, same method

Both endpoints receive the same generated request sequence. If request #18 is `eth_getBlockByNumber` for your endpoint, request #18 is also `eth_getBlockByNumber` for GetBlock. This paired mode keeps the latency comparison method-for-method.

Profiles and methods

How “What are you building?” changes the test

The selected profile changes the read-only method mix and method weights. It does not give either provider an advantage: the generated sequence is shared, so your endpoint and GetBlock receive the same methods, params, timeout, and request count.

General dApp

Balanced lightweight reads for common frontend and backend dApp traffic.

eth_blockNumbereth_getBlockByNumbereth_getBalanceeth_call

Wallet / portfolio app

Prioritizes balances, latest blocks, and lightweight contract or account reads.

eth_getBalanceeth_calllatest block readsSolana balance reads

Data indexer / analytics

Emphasizes block-heavy and log-heavy reads that indexers and analytics pipelines depend on.

eth_getBlockByNumbereth_getLogsblock height readsmethod compatibility checks

DEX / trading bot

Focuses on fresh state, low tail latency, and methods that trading flows call repeatedly.

eth_blockNumbereth_callfresh state readslatest block / slot

NFT marketplace

Tests NFT-style read patterns where method support and consistency matter more than a single average latency.

eth_calleth_getLogsmetadata-related readscollection state reads

Protocol support matters. EVM chains can use contract and log methods, Solana uses Solana JSON-RPC methods, Tron uses EVM-compatible JSON-RPC reads, and Bitcoin-like protocols use safe node-status and height methods. If a method cannot be generated safely for a protocol, it is skipped.

Benchmark flow

1. Input validation and safety checks

  • Only `http` and `https` RPC URLs are allowed.
  • The tool blocks localhost and common private or internal ranges such as `127.0.0.1`, `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`, and `169.254.0.0/16`.
  • The pasted endpoint is checked against the selected protocol on mainnet before the run starts. EVM-like endpoints are checked with `eth_chainId`; Solana uses `getSlot`; Bitcoin-like protocols use `getblockcount`; other supported protocols use their safest available read-only identity or status method.
  • Cloudflare Turnstile verification is required before the public benchmark can start. This protects the benchmark API from automated abuse while keeping the benchmark itself free to run.
  • If the endpoint reports a different protocol or a non-mainnet network, the run is blocked before benchmarking begins.
  • Private endpoints with API keys inside the URL are supported. For storage and reporting, the tool never keeps the full URL in plain text: it stores a masked form and a SHA-256 hash instead.

2. Warm-up phase

  • After validation, both the user endpoint and the GetBlock endpoint receive one initial warm-up request before timed sampling begins.
  • Warm-up requests are used to reduce one-off cold-start noise and to make the measured run closer to the behavior a real application sees after the first request.
  • Warm-up is not the benchmark result itself. Its job is to separate setup effects such as DNS, TLS, or first-request overhead from the timed request loop as much as possible.

3. Request profile selection

  • The benchmark selects methods using weighted random choice. The selected developer profile controls which methods are used and how often they appear.
  • Supported profiles in the engine are `general`, `wallet`, `indexer`, `trading`, and `nft`. In the UI, these appear as General dApp, Wallet / portfolio app, Data indexer / analytics, DEX / trading bot, and NFT marketplace.
  • For EVM chains, the profile can include methods such as `eth_chainId`, `eth_blockNumber`, `eth_getBlockByNumber`, `eth_getBalance`, `eth_call`, and in some profiles `eth_getLogs` with a safe bounded range.
  • For Solana, the profile can include `getHealth`, `getSlot`, `getLatestBlockhash`, and `getBalance`.
  • For Bitcoin, Tron, and other supported non-EVM protocols, the benchmark uses safe read-only methods appropriate for each protocol and skips methods that cannot be generated safely.

4. Paired timed sampling loop

  • During the run, the engine creates one shared request sequence from the selected weighted profile.
  • For every item in that sequence, the same read-only method and params are sent to your endpoint and to the GetBlock endpoint. The two calls are executed as a pair, so both providers receive the same method mix and the same number of sampled requests.
  • If one provider returns an error, timeout, or rate-limit response, the paired sample is still recorded. This keeps request counts aligned and prevents one endpoint from receiving a different workload than the other.
  • The engine keeps sending paired requests until the deadline is reached. Each sample records provider, method, timestamp, latency, success state, status code, and error classification.
  • This benchmark is designed to compare endpoint behavior under a short steady sampling loop, not to simulate a large parallel load generator.
  • The observed request rate displayed in the UI is therefore the realized traffic of this benchmark run, not a guaranteed maximum capacity number.

5. Latency and error classification

  • For each request, latency starts just before the `fetch()` call and ends immediately after the HTTP response is received and parsed.
  • A request is marked as success only if the HTTP response is OK and the JSON-RPC body does not contain an `error` field.
  • A request is marked as timeout if it exceeds the configured timeout and the abort signal fires.
  • A request is marked as error for JSON-RPC errors, invalid JSON, network failures, auth failures, and other non-timeout failures.
  • HTTP 429, 401, and 403 are preserved as distinct signals because they matter for production diagnosis.

Measured signals

Average latency

Average latency is the mean of successful request latencies. It is useful, but it can hide slow outliers. That is why the report also emphasizes tail latency.

p50 latency

p50 latency is the median successful latency. Half of successful requests are faster than this number, and half are slower.

p95 latency

p95 latency shows the response time that 95% of successful requests fall under. This is one of the most useful numbers for real user experience because it captures slow-but-common tail behavior.

p99 latency

p99 latency shows the slowest edge of normal successful behavior. If p99 spikes while average latency looks fine, users can still experience inconsistent loading times.

Success, error, and timeout rates

Success rate is the share of all sampled requests that completed successfully. Error rate is the share that failed for any reason. Timeout rate is the share that did not complete before the benchmark timeout.

Jitter and consistency

Latency standard deviation and jitter help describe consistency. In this tool, jitter is calculated as `p95 - p50`, which gives a simple tail-spread signal. A low median latency with high jitter usually means the endpoint is fast sometimes, but not predictably fast.

Observed RPS

Observed RPS is calculated as `requestCount / durationSec`. It describes how much traffic this benchmark actually generated. It should not be interpreted as a contractual throughput limit or as a production-ready load test result.

Verdict logic

Method-level verdicts

Per-method verdicts compare the same method on both providers. If one side has zero successful responses while the other succeeds, the method is marked as failed on that provider. If one side has high error rate or timeout rate, the method is marked unstable. Otherwise, p95 latency decides the winner unless the difference is under 10%, in which case the method is marked similar.

Provider score

Provider scores combine average latency, p95 latency, p99 latency, success rate, timeout rate, and protocol-aware freshness. The score is latency-sensitive but reliability still matters: a very fast endpoint with many failed calls should not look production-ready. The score is not a protocol standard; it is a compact comparison signal used by this tool.

Production readiness label

Production readiness labels are chosen from the measured results. Examples include method compatibility issues, stale node risk, high timeout risk, possible rate limiting, fast and stable, slow but reliable, and similar performance. The label is meant to summarize what is most likely to break in real usage.

Actionable findings

Actionable findings are generated from concrete benchmark evidence and use a Problem → Why it matters → What to do next structure in the report. Repeated HTTP 429 responses produce a rate-limit finding, 401/403 responses produce an access finding, high timeout rate produces a timeout-risk finding, method-specific failures produce compatibility findings, high jitter produces a consistency finding, and block lag produces a freshness finding.

Freshness rules

How sync lag is detected

  • For EVM and Tron-style RPC endpoints, the benchmark compares the latest block number near the end of the run.
  • For Solana, it compares the latest slot near the end of the run.
  • For Bitcoin-like and other supported non-EVM protocols, it compares the safest available latest height, slot, ledger, or status value returned by that protocol.
  • The height difference is converted to estimated time lag using the selected protocol’s configured nominal production cadence. Fast chains can treat a one-block difference as minor, while slow chains such as Bitcoin can treat a one-block difference as significant.
  • A difference representing no more than 6 seconds is treated as similar. This makes one fast-chain block a minor difference while one Bitcoin block is a significant lag.
  • Freshness score decays with estimated time lag and contributes 10% of the provider score. If the user endpoint exceeds the tolerance, the result is marked as stale node risk.

Limitations

What this benchmark does not claim

  • This is not a geographic benchmark. The public tool currently runs from one benchmark server, not from multiple global probes.
  • This is not a high-concurrency load lab. The tool measures comparative behavior under a short automated request loop, not under a full production traffic replay.
  • Performance can change depending on where requests originate, how a provider routes traffic, whether cache is warm, and how loaded the provider infrastructure is at that moment.
  • Public endpoints can look good for a few requests and then degrade, timeout, or rate-limit later. Re-running the benchmark at a different time is often useful.
  • Caching, provider plan tier, temporary network congestion, and backend routing can all change results between runs.
  • The public benchmark is mainnet-only. Testnet and devnet endpoints need separate baselines and should not be mixed with mainnet comparison results.
  • The benchmark masks the user RPC URL before storage and keeps only masked or derived values in the benchmark metadata returned to the UI.