eth_getLogs performance comparison

eth_getLogs is not just a basic lookup. The node must search event logs across a block range and apply address and topic filters. Performance depends on:

• block range size
• event density
• topic selectivity
• chain size
• node client
• archive/full node behavior
• provider limits
• cache state
• retries and concurrency

This means one benchmark result does not represent all workloads.

Latency distribution

Do not only track average latency. Measure:

• p50
• p95
• p99
• max latency
• timeout rate

For production systems, p95 and p99 often matter more than the average.

Error rate

Track:

• 429 responses
• timeouts
• invalid range errors
• inconsistent responses
• partial failures
• provider-specific limits

A slower but consistent provider may be better than a fast provider that fails unpredictably under load.

Range behavior

Test multiple block range sizes:

• small recent ranges
• medium historical ranges
• large backfill ranges
• dense event ranges
• sparse event ranges

Many systems perform fine on small ranges and fail when backfills begin.

Cost per successful result

Cost should be measured per useful result, not only per RPC call. If a provider has high timeout or retry rates, the effective cost goes up.

Use a repeatable test matrix:

1. Select real contracts from your workload.
2. Pick recent and historical block ranges.
3. Include dense and sparse event periods.
4. Run tests with realistic concurrency.
5. Record latency, errors, and retries.
6. Compare cost based on actual method billing.
7. Repeat at different times of day.

Avoid synthetic-only tests. They may tell you the endpoint is alive, but not whether it can support your indexer.

SolidRPC is built for teams where eth_getLogs is not an edge case but a core workload. One application endpoint covers live reads and historical backfills while SolidRPC routes by block range and capability, monitors the upstream layer, fails over, and owns recovery.

The platform focuses on:

• full and archive capacity behind one integration
• predictable response quotas
• heavy method support
• continuous monitoring and recovery
• managed routing and node operations
• direct engineer support

The goal is not to win a toy latency test. The goal is to let production workloads scan logs and backfill history without the application team operating a provider pool.

Avoid these patterns:

• using very large block ranges without testing provider limits
• treating all chains the same
• retrying too aggressively
• measuring only current blocks
• ignoring response size
• ignoring empty ranges
• ignoring failed requests in cost calculations
• assuming archive and full node behavior is identical

eth_getLogs performance should be benchmarked with real contracts, real block ranges, realistic concurrency, and method-level cost analysis.