Fastest Solana RPC: How to Measure Latency & Endpoint Performance

Why the Fastest Solana RPC Depends on Workload and Region

Solana RPC latency is the sum of network round-trip time (RTT), server processing time, and response serialization/transfer. Physical distance dominates RTT; an app in Singapore will see lower latency to a Hong Kong endpoint than to a US East endpoint, all else equal. Workload type changes which part of the request path dominates: a getSlot call is cheap and network-bound, while a getProgramAccounts call may be compute- and I/O-bound.

Providers often advertise headline latency numbers, but these may come from light methods in a single region. For your stack, the relevant question is how fast each method you rely on responds from your users' or server's region.

• Network path and peering matter as much as geographic distance; a direct route to Solana validators reduces jitter.
• Light methods (e.g., getSlot, getBlockHeight) are latency-sensitive to distance.
• Heavy methods (e.g., getProgramAccounts, getSignaturesForAddress) are sensitive to node hardware, database indexing, and cache.
• Streaming and subscriptions depend on WebSocket stability, not just HTTP response time.

p50, p95, and Tail Latency Metrics

Average latency hides outliers. A provider may have a low mean because most requests are fast, but occasional slow responses can degrade user experience. p50 (median) represents typical response time; p95 is the 95th percentile, meaning 95% of requests are faster than this value. p99 or max are tail latencies that matter for real-time trading or interactive UI.

For a high-frequency bot, p95 might be more important than p50; for a wallet showing balances, p95 under 200ms might be acceptable. Capture multiple percentiles from your benchmark runs.

Method-Specific RPC Testing

Solana JSON-RPC methods vary widely in cost. Testing only getSlot or getHealth misses the heavy methods that actually load the node. Classify your methods: cheap reads (<10ms typical), medium reads, and expensive historical or account scans.

Run each method multiple times and record p50/p95. Use identical payloads and connection settings. For heavy methods, test with and without encoding options that reduce payload size (e.g., jsonParsed vs base58).

• Cheap: getSlot, getBlockHeight, getHealth, getVersion – mostly network-bound.
• Medium: getAccountInfo, getBalance, getBlock with limited transaction details – depend on cache and disk.
• Expensive: getProgramAccounts, getSignaturesForAddress, getBlock with full transactions – scan account state or history; often vary widely between providers.
• Archive methods may not be available on some endpoints; check archive support before benchmarking historical queries.

WebSocket Stability and Connection Pressure

Real-time apps rely on WebSocket subscriptions for slots, accounts, logs, and program changes. The latency of a subscription message is only part of the story; connection stability, reconnection behavior, and message ordering matter. A provider may have fast HTTP responses but drop WebSocket connections under high subscription count or during network congestion.

Measure WebSocket stability by subscribing and tracking: time to first message, message rate vs expected slot/account updates, number of disconnects per hour, and reconnection time. Use a simple script that logs these events.

• Test with slotSubscribe for basic liveness and accountSubscribe or logsSubscribe for real workload behavior.
• Check if the endpoint enforces a maximum number of concurrent WebSocket connections per API key or IP.
• Public endpoints often have limited WebSocket capacity; managed endpoints may offer higher limits or dedicated connections.

Rate Limits, Retries, and Queueing Effects

Rate limits on shared endpoints cause throttling, which appears as latency or request failures. When a request exceeds the limit, the endpoint may return HTTP 429 or 403, or queue the request. Queueing adds to effective latency because the request waits before processing. Some providers implement fair-use policies that slow down heavy users instead of hard failing.

Public endpoints enforce per-IP limits that can change without notice; managed providers usually define plan-specific limits. Do not assume a fixed number; check current documentation for any endpoint you rely on. When benchmarking, induce controlled load to see when throttling begins and how errors are returned.

• Implement exponential backoff with jitter on retries to avoid thundering herd after a 429.
• Batch multiple JSON-RPC calls where supported to reduce request overhead and limit consumption.
• Cache expensive reads locally to reduce call volume, especially for getProgramAccounts and historical methods.
• If your workload consistently approaches rate limits, consider a dedicated node or higher-tier plan.

A Reproducible Benchmark Methodology

Start by defining the workload: list all methods your application calls, their expected frequency, and whether they are HTTP or WebSocket. Then choose a test region that matches your user base or your backend's region. Run the benchmark from a VPS or cloud instance in that region to avoid local network variability.

Create a script that sends requests sequentially or with mild concurrency, records latency for each call, and outputs percentiles. Run it at different times of day, especially during Solana network congestion periods. Use a baseline public endpoint for sanity checks, but don't rely on it for production comparisons.

• Use curl for quick single-method checks, but for percentiles use a script that repeats requests 100+ times.
• Capture HTTP status codes, response time, and error messages for every request.
• For WebSocket, test subscription establishment, first-message latency, and reconnection time after a forced disconnect.
• Log the endpoint URL, region, and timestamp to allow fair comparisons.

How to Interpret Results and Choose an Endpoint

After collecting data, compare providers on p50, p95, tail, error rate, and WebSocket stability. Weight metrics by your workload: a trading bot prioritizes low p95 and tail latency for sendTransaction and getLatestBlockhash; an NFT marketplace might prioritize getAccountInfo and getProgramAccounts throughput with acceptable p95.

Consider region coverage: if your users are global, you may need multiple endpoints or a provider with multiple regions. OnFinality's Solana endpoint covers regions like N. Virginia and Hong Kong (verify current availability on /networks/solana). But do not assume those regions will match your latency needs without testing.

If shared endpoints show tail latency spikes or rate-limit pressure, explore dedicated node options. The trade-offs between shared and dedicated capacity are explained in /rpc-assistant/dedicated-vs-shared-node-access-solana-rpc-performance. For a broader provider evaluation framework, see /rpc-assistant/best-solana-rpc-provider.

• Do not choose based on a single benchmark run; look for consistency across times and load levels.
• Check historical archive support if your app queries old state.
• Confirm whether Devnet access is included for testing; use https://api.devnet.solana.com with test SOL from https://faucet.solana.com.
• Make sure the endpoint supports your required WebSocket subscriptions and that reconnection logic works in your client.

Frequently Asked Questions