RPC Latency Slow: Causes, Measurement, and Fixes

What Causes Slow RPC Latency?

When your blockchain application feels sluggish, the first suspect is often the RPC endpoint. But 'RPC latency' is not a single number; it's a combination of network round-trip time, node processing time, and queueing delays. Understanding each component is the first step to fixing it.

The total latency you observe is the sum of: network latency (the time for packets to travel between your client and the node), node processing time (how long the node takes to execute the request, which depends on the method and the node's load), and queueing delay (if the node is busy, your request waits in line). For example, a simple eth_blockNumber request might take 10 ms on a local node, but 200 ms on a public endpoint across the ocean.

The dominant factor is often network distance. Light travels about 5 ms per 1,000 km in fiber, but real-world latency is higher due to routing and congestion. A request from New York to a node in Tokyo can easily take 150-200 ms round-trip. Node load is the second major factor: if the node is processing many heavy queries (like eth_getLogs over a large range), your request may be queued behind them.

Finally, the query itself matters. Some RPC methods are inherently expensive. For example, eth_getLogs with a wide block range can take seconds, while eth_blockNumber is nearly instant. If your application is making expensive calls frequently, you'll see high latency even with a fast node.

To get a clear picture, you need to measure each component separately. The rest of this article shows you how.

• Network latency: round-trip time between client and node, affected by geography and routing.
• Node processing time: time for the node to execute the request, depends on method and load.
• Queueing delay: time waiting for the node to become free, increases under load.
• Query cost: some methods (e.g., eth_getLogs) are much slower than others.

How to Measure RPC Latency Reproducibly

To measure RPC latency, you can use curl with the -w option to capture timing details. This gives you a reproducible method that doesn't require special tools. Here's a command that sends a simple eth_blockNumber request to a public endpoint and prints the total time:

Run this command a few times to get a sense of the distribution. The time_total is the total time for the HTTP request, including network and node processing. To separate network latency from node processing, you can use time_connect (TCP handshake) and time_starttransfer (time to first byte).

For a more robust measurement, you should collect multiple samples and compute percentiles. The p50 (median) tells you the typical latency, while p99 (99th percentile) reveals tail latency, which is critical for user experience. You can use a simple script to send 100 requests and calculate these values.

Here's a bash script that sends 100 requests and computes p50, p95, and p99 using awk and sort. It assumes you have curl and jq installed.

curl -s -o /dev/null -w "time_total: %{time_total}s\n" -X POST https://eth.api.onfinality.io/public -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

Interpreting the Numbers: What Is 'Good' RPC Latency?

Once you have measurements, you need a baseline. For a public RPC endpoint, a p50 of under 100 ms is generally acceptable, and under 50 ms is good. However, for trading applications or real-time interactions, you may need p99 under 100 ms. For reference, a typical round-trip time from a US East Coast client to a US West Coast node is about 70 ms; to Europe it's about 140 ms; to Asia it's 200 ms or more.

If your p50 is high but p99 is much higher, you likely have a node load issue. If both are high, it's probably network distance. You can test this by comparing a local node (if you have one) with a remote public endpoint. If the local node is much faster, the network is the bottleneck.

Also, consider the method you're measuring. eth_blockNumber is the cheapest method; if it's slow, everything else will be slower. For a more realistic test, measure the actual methods your application uses, such as eth_getBalance or eth_call.

Remember that latency is not the same as throughput. A node can have low latency but low throughput, or vice versa. For high-throughput applications, you may need to batch requests or use WebSocket subscriptions to reduce the number of round trips.

• p50 < 100 ms: acceptable for most public endpoints.
• p50 < 50 ms: good for interactive applications.
• p99 < 100 ms: required for trading or real-time apps.
• Compare p50 vs p99 to identify load vs. network issues.

Reducing Latency: Geographic Endpoints and Provider Selection

The most effective way to reduce network latency is to use an endpoint that is geographically close to your application. If your users are in Europe, use a European endpoint; if they're in Asia, use an Asian one. Many providers, including OnFinality, offer regional endpoints. For example, OnFinality's Polkadot RPC endpoints include options in different regions.

When choosing a provider, look for one with a global edge network. OnFinality's RPC service routes requests to the nearest node, reducing round-trip time. Similarly, for Ethereum, you can use best Ethereum RPC APIs that offer low-latency access.

If you're building a trading bot on Hyperliquid, latency is critical. Check out our guide on best Hyperliquid RPC providers for low-latency trading to see which providers offer the fastest connections.

For Solana, the network is designed for high throughput, but latency still matters. See our Solana RPC endpoints page for recommended providers.

Finally, consider running your own node if you have the resources. A local node eliminates network latency entirely, but requires maintenance and can still be slow if the node is underpowered. For many applications, a well-chosen public endpoint is sufficient.

Reducing Latency: Batching, Subscriptions, and Caching

Even with a fast network, you can reduce perceived latency by reducing the number of round trips. JSON-RPC batching allows you to send multiple requests in a single HTTP request, cutting down on network overhead. For example, if you need to fetch 10 balances, you can send one batch request instead of 10 separate requests. This is especially effective for high-latency networks.

Learn how to implement batching correctly in our article on JSON-RPC batching best practices. Batching can reduce total time from N * latency to roughly latency + N * processing_time, which is a huge win.

Another technique is to use WebSocket subscriptions instead of polling. Subscriptions push data to you when it changes, eliminating the need for repeated requests. This is ideal for real-time applications like price feeds or transaction monitoring. WebSocket connections also have lower overhead after the initial handshake.

Caching is also powerful. If you're fetching the same data repeatedly (e.g., block numbers, gas prices), cache it client-side and refresh at a reasonable interval. This reduces the load on the node and improves your application's responsiveness.

Finally, consider using a dedicated node if you have high traffic. Public endpoints are shared, so you may experience rate limiting or queueing. A dedicated node gives you consistent performance. OnFinality offers dedicated nodes with SLAs.

Diagnosing Common Latency Issues

If you've measured and your latency is still high, here are common issues to check:

1. DNS resolution: The time to resolve the endpoint's hostname can add 10-50 ms. Use curl -w "time_namelookup: %{time_namelookup}s\n" to measure it. If it's high, consider using an IP address directly or a faster DNS provider.

2. TLS handshake: HTTPS adds a handshake that can take 20-100 ms. Use time_appconnect to measure it. You can't avoid TLS, but you can reuse connections with keep-alive.

3. Node overload: If the node is returning errors or slow responses, it may be overloaded. Check the node's status page or use a health check endpoint. If you're using a public endpoint, try a different one to compare.

4. Firewall or proxy: Corporate networks or VPNs can add latency. Test from a different network to isolate.

5. Client-side issues: Your application might be making requests sequentially when they could be parallel. Use asynchronous calls or batching.

For a systematic approach, read our guide on monitoring RPC endpoints to set up alerts for latency spikes.

Trade-offs and Limitations

While you can reduce latency, there are trade-offs. Geographic endpoints may have different data availability or may be less reliable. For example, a node in a region with fewer peers might have higher sync latency. Also, batching can increase the load on the node, so use it judiciously.

Subscriptions require maintaining a persistent connection, which can be more complex to manage. Caching can lead to stale data if not invalidated properly. And dedicated nodes cost more.

Finally, remember that RPC latency is only one part of the equation. Your application's performance also depends on the blockchain's consensus time, block time, and the efficiency of your code. Optimize your code before blaming the RPC.

For a deeper dive into related issues, see our article on how to fix RPC timeout errors and monitoring RPC endpoints.

Next Steps: Build a Latency Budget

Now that you know how to measure and reduce latency, create a latency budget for your application. Decide what p50 and p99 you need, and test your endpoints regularly. Use the techniques above to meet your budget.

If you're using OnFinality, you can leverage our global network to get low-latency access to multiple chains. Check our pricing for dedicated options. And explore the how to choose an RPC provider to find the best endpoints for your needs.

Remember, latency is a moving target. As your user base grows or your application changes, re-evaluate your endpoints and architecture. Regular monitoring is key.