How we benchmark RPC performance

Benchmark numbers are easy to quote and easy to misread. That is especially true for RPC performance. One latency chart can hide several different questions: where the request started, which method ran, what payload was sent, what counted as success, how failures were handled, and whether the test measured one RPC call or a full application workflow.

We built our public EVM read benchmark to make those details visible. The goal is to show how providers compare under a controlled, repeatable test setup.

Our benchmark answers how providers compare on common EVM JSON-RPC read methods across selected chains, regions, and time windows.

These are method-level infrastructure benchmarks: one controlled methodology run separately for each method, chain, provider, and region. They measure individual RPC requests, not full application workflows like loading a wallet portfolio, preparing a swap, or polling transaction status across several calls. That distinction matters: method-level results help developers compare provider behavior, but they are not a complete model of any production app.

What is Alchemy's public EVM read benchmark?

Alchemy's public EVM read benchmark is a controlled test that measures how RPC providers respond to configured EVM JSON-RPC read requests. It captures successful-response latency (average, p50, and p95), success rate, and failed-request counts, grouped across providers, chains, methods, regions, and time windows.

We calculate latency only from successful responses. Failed attempts and timeouts are tracked separately, through success rate and failed-request counts. This keeps the benchmark focused on both speed and reliability rather than treating either metric in isolation.

Definitions and measurement rules

The definitions, setup, and rules the rest of this post builds on. Each row is expanded in the sections below.

What does the benchmark cover?

The benchmark covers Ethereum, Optimism, Arbitrum, Base, and World Chain mainnets, and the public provider set includes Alchemy, dRPC, Infura, and QuickNode. We selected these to cover widely used EVM mainnets and the RPC providers developers most often evaluate, with room to expand the set over time. For a given method, every provider receives the same configured JSON-RPC request.

We run each test from controlled AWS ECS regions: US East, US West, EU Central, and AP Southeast. Within a region, every provider is tested from the same runner location, because network distance can change latency. If we tested one provider from Virginia and another from Singapore, the result would tell you as much about geography as about provider performance.

Each result is grouped by:

• Provider
• Chain
• Method
• Region
• Trailing time window

What does the benchmark send to each provider?

A method is the operation being called, like eth_getBalance or eth_getLogs. A payload is the full request we send to exercise that method, including its parameters. The distinction matters because performance depends on both: a cheap lookup and a large range scan place very different load on a provider, and even one method can shift with its inputs.

For a given method, every provider receives the same configured JSON-RPC payload, on a standard paid account. That is the fairness rule: same method, same parameters, same chain, same region, same timeout, same success criteria, and no special treatment for any provider.

Today that means seven configured tests on most chains, and eight on Ethereum:

• eth_getBalance: an account balance lookup
• eth_getBlockByNumber at the earliest block: a header read at the start of the chain
• eth_getBlockByNumber at the latest block: a header read at the chain head
• eth_getLogs over a 1-block range
• eth_getLogs over a 10-block range
• eth_getLogs over a 100-block range
• eth_getLogs over a 1,000-block range (Ethereum only)
• eth_getTransactionReceipt: a single transaction receipt lookup

Some payloads move with the chain. Calls that use the latest block tag, for example, change as the chain advances. Others use fixed historical inputs: the Ethereum eth_getLogs tests use configured historical block ranges for the LINK token contract.

The mix is intentional:

• Fixed inputs make parts of the test repeatable.
• Moving inputs make parts of the test reflect live chain state.
• Fixed historical inputs may be easier for providers to cache.

RPC performance can vary widely depending on method, parameters, block range, response size, cache behavior, and chain state. When reading the benchmark, focus on the method and parameters closest to your own workload.

How is performance measured?

We measure performance through two signals, each answering a different question: latency, how fast successful responses come back (reported as average, p50, and p95), and success rate, how often requests succeed at all (with the failed-request counts behind it).

The two are related but distinct: a fast successful response is not the same as a reliable one. We report them side by side so neither hides the other.

How is latency measured?

Latency is the runner's measured request-and-response time for a successful JSON-RPC HTTP POST. The timer starts when the runner sends the request and stops when it receives the response. If a provider returns a valid response in 120 milliseconds, that request has 120 ms of latency.

We use warmed, reused HTTP connections. In plain English, we are not timing the first setup steps needed to open a new connection, such as DNS lookup, TCP connection setup, or the TLS handshake. The runner primes the connection first, then measures the POST itself over a pooled keep-alive connection.

That brings the latency number closer to repeat application traffic, where clients commonly reuse connections. It also means you should not read these numbers as cold first-request latency.

Only successful responses enter the latency distribution. If a request times out, returns an HTTP error, returns a JSON-RPC error object, fails to parse, or hits a network error, we count it as a failed attempt instead.

Timeouts are not treated as slow 8,000 ms responses. We exclude them from latency and count them in success rate, which keeps latency focused on response speed and success rate focused on reliability.

What is success rate?

Success rate is the share of attempted requests that returned successfully under the benchmark rules: successful requests divided by total attempted requests.

A request counts as successful only if all of the following happen:

1. It completes before the benchmark timeout.
2. It returns an HTTP 2xx status.
3. The response body parses as JSON.
4. The JSON-RPC response does not contain a non-null error object.

We do not use retries to hide failed attempts. One attempted request gets one chance. If it fails, that failure is counted.

How does the benchmark handle timeouts?

The benchmark runner waits up to 8 seconds for each provider to return a valid response. If no valid response comes back in time, we record the attempt as a timeout failure.

The 8-second cutoff is part of our test setup. It is not set by the chain, and it is not whatever timeout a provider may use internally.

The 8-second cutoff applies to all the public EVM read methods today. A specific method could be configured with a different timeout, but none currently is.

What counts as a failed request?

We track failed attempts separately from latency. A request is counted as a failure if it:

• returns a non-2xx HTTP status, such as 403, 429, 500, 502, 503, or 504
• returns a JSON-RPC error object
• times out after 8 seconds
• fails at the network level, or
• fails to parse as valid JSON

Rate-limit responses count as failures, and we never use retries to convert failed attempts into successful ones. Each failure lowers the provider's success rate and adds to its failed-request count for that method, chain, region, and window.

How are the metrics defined?

Why report latency and success rate together?

Fast responses only matter when responses actually come back. A provider can show low latency on the requests that succeed while timing out or failing more often, so we report latency alongside success rate: latency shows how quickly valid responses return, success rate shows how often they return at all.

For example, if we send 1,000 attempts and 990 return successfully before the 8-second timeout, the success rate is 99%. The 10 failed attempts do not enter p50, p95, or average latency; they show up as reliability failures.

That prevents two misreads: a provider with low latency but more failures should not be judged on speed alone, and a provider with a high success rate but slower tail latency should not be judged on reliability alone.

Why does the benchmark use a trailing window?

The benchmark runs continuously. Common public EVM read methods run roughly every 10 seconds, and we refresh the public benchmark page every 5 minutes from a trailing 24-hour window.

At full uptime, a method that runs every 10 seconds produces about 8,640 attempts per provider, method, network, and region each day. A trailing 24-hour window gives each public number enough samples to smooth over one-off blips while keeping the page fresh.

So read the public page as a rolling daily summary, not a single request, a one-time test, or one momentary snapshot.

What does the benchmark not measure?

Today, the benchmark measures warm, single-method read performance under controlled conditions. It does not measure:

• Multi-call user flows
• Write transactions or transaction submission
• WebSocket or subscription behavior
• Customer-specific request mixes
• Cold first-request connection setup
• Every provider, chain, region, method, or payload shape
• The exact behavior of your own architecture, traffic level, or deployment geography

That boundary is what makes the benchmark useful: it tells you where the numbers apply and where you should run your own workload-specific tests.

Speed and reliability are related but separate questions:

• Speed asks how quickly successful requests return.
• Reliability asks how often requests return successfully.

We designed the benchmark to show that distinction rather than flatten it into one "fastest provider" claim.

How should developers use the results?

Use the public benchmark as a starting point for provider evaluation. A practical reading pattern:

1. Pick the chain and method closest to your workload.
2. Compare the region that best matches where your users or infrastructure sit.
3. Look at p95, not just average or p50.
4. Check success rate beside latency.
5. If your workload uses different payloads, higher concurrency, writes, WebSockets, or multi-call flows, run a workload-specific benchmark before deciding.

Transparent benchmarks help you ask better questions. They make it easier to see what was tested, what was counted, what was excluded, and which parts of the result matter most for a real application.

Frequently asked questions

What is Alchemy's public EVM read benchmark?

It is a controlled test that measures how RPC providers handle common EVM JSON-RPC read requests. It records successful-response latency (average, p50, p95), success rate, and failed-request counts across selected providers, chains, methods, and regions, letting developers compare providers under identical, repeatable conditions rather than marketing claims.

How is RPC latency measured?

Latency is the runner's wall-clock time for one JSON-RPC POST and its response over a warmed, reused connection. The timer starts when the request is sent and stops when a valid response arrives. Only successful responses count, so latency reflects response speed, not connection setup or failures.

What counts as a successful request?

A request succeeds only if it returns within the 8-second timeout, returns an HTTP 2xx status, parses as JSON, and contains no JSON-RPC error object. Anything else, including timeouts, HTTP errors, and rate-limit responses, is counted as a failed attempt and excluded from latency.

How does the benchmark handle timeouts?

The runner waits up to 8 seconds for a valid response. If none arrives, the attempt is recorded as a timeout failure, not as a slow 8,000 ms response. Timeouts lower success rate but never inflate latency, which keeps speed and reliability as separate measurements.

Does the benchmark use retries?

No. Each measurement is a single attempt. If that attempt fails, the failure is counted rather than retried away. This keeps success rate honest, since retries would hide the intermittent failures that real applications actually experience.

Which chains and providers does the benchmark include?

The public benchmark covers Ethereum, Optimism, Arbitrum, Base, and World Chain mainnets. The provider set includes Alchemy, dRPC, Infura, and QuickNode. Each provider receives the same configured request for a given method, from the same region, under the same timeout and success rules.

Which RPC methods does the benchmark test?

The benchmark runs seven configured read tests, built from four EVM methods: eth_getBalance; eth_getBlockByNumber at the earliest and latest blocks; eth_getLogs over 1-, 10-, and 100-block ranges; and eth_getTransactionReceipt. Ethereum adds a 1,000-block eth_getLogs test, for eight. Each uses a fixed payload, so results stay comparable across providers.

What does the benchmark not measure?

It does not measure full application workflows, write transactions, WebSocket subscriptions, customer-specific traffic mixes, or cold connection setup. It also does not cover every chain, provider, region, method, or payload. For those cases, run a workload-specific benchmark that matches your own traffic.

How should I read a p95 latency number?

Read p95 as: for this method, chain, region, and time window, 95% of successful responses were at least this fast. It exposes tail behavior the average hides. Always read it beside success rate, since fast responses only matter when responses actually return.