chore: add RPC requests logging for RETH calls slower than GETH #785
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
This stack of pull requests is managed by Graphite. Learn more about stacking. |
Graphite Automations"Request reviewers once CI passes on routing-api repo" took an action on this PR • (07/18/24)6 reviewers were added and 1 assignee was added to this PR based on 's automation. |
|
I can see the new logging showed up in my local AWS routing-api: |
mikeki
approved these changes
Jul 18, 2024
jsy1218
deleted the
siyujiang/route-198-log-rpc-requests-for-reth-calls-that-are-slower-than-geth
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I observe that RETH RPC calls are slower than GETH calls in Uniswap routing backend. My observation is based on two different time periods:
request volume dropped in half on may 20th, because I changed from shadow sampling both quicknode geth and reth to shadow sampling only quicknode reth:
If reth were to run faster than geth, then I expect P50 latency to go down, but instead it went up:
Sampling traffic volume are comparable between geth and reth, just to make sure the benchmarking is on the same traffic scale:
I can see that P50 is also higher on reth than geth:
I do believe this is due to Uniswap specific RPC call pattern, since we make heavy multicall for quoting. e.g. this tenderly simulation captures a heavy multicall with hundreds of routes. As mentioned in #775, from Paradigm flood testing, we see quicknode reth is faster than quicknode geth, so this makes me believe it's uniswap specific RPC call pattern.
I think it makes sense to log the RPC requests when we observe the evaluated latencies are slower than the current provider latencies. This can help further debug why RETH for Uniswap is slower.