Is your feature request related to a problem?
While access to the RPC endpoint is currently limited with a semaphore, RpcHelper does not manage rate-limiting of requests. This can potentially lead to snapshotters making many unnecessary RPC calls that would result in rejection when the request limits can be known before the call is made.
Describe the solution you'd like
Simple rate limiting should be added to RpcHelper on a per-second basis to allow operators to configure the rate of requests to match the limitations of their RPC endpoints. This should allow for more efficient resource usage and prevent unnecessary retries for calls failing due to a 429.
Describe alternatives you've considered
I've considered adding support for various Compute Unit (CU) based RPCs, but decided against this after discussing with @xadahiya due to the added complexity and inability to guarantee the correct configurable options for all providers. Keeping the limit anchored to a per-second rate allows for general support, and the option of building a request profile for each snapshotter-core and compute unit is available if an operator would like to convert their CU limits to a per-second basis.
Is your feature request related to a problem? While access to the RPC endpoint is currently limited with a semaphore, RpcHelper does not manage rate-limiting of requests. This can potentially lead to snapshotters making many unnecessary RPC calls that would result in rejection when the request limits can be known before the call is made.
Describe the solution you'd like Simple rate limiting should be added to RpcHelper on a per-second basis to allow operators to configure the rate of requests to match the limitations of their RPC endpoints. This should allow for more efficient resource usage and prevent unnecessary retries for calls failing due to a 429.
Describe alternatives you've considered I've considered adding support for various Compute Unit (CU) based RPCs, but decided against this after discussing with @xadahiya due to the added complexity and inability to guarantee the correct configurable options for all providers. Keeping the limit anchored to a per-second rate allows for general support, and the option of building a request profile for each snapshotter-core and compute unit is available if an operator would like to convert their CU limits to a per-second basis.
Additional context N/A