-
Notifications
You must be signed in to change notification settings - Fork 20.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inefficient response handling in Snap #25600
Comments
In A better model in this case would be to tune down the OBS: this is a consequence of disk IO speed, not network lag. |
Here's one hour of execution, where I have set a hard upper limit of pending trie requests at The It places the cap very un-dynamically at the place where we schedule requests. It could be applied in several different places, and could also be made dynamic -- e.g. adjusted so that the |
Fix: #25651 |
Note This bug report is somewhat speculative, I am not 100% certain that the description here is correct.
I think I know why this PR (#25588) does not make any difference.
This is the machine charts. A few observations can be made:
Snap trienode handle
times are most commonly in3-7s
bucket, but quite often up to 20 seconds.So if all our responses have already arrived, handling them will take ~
1280
seconds, or 21 minutes. So once we get to actually handle them, they will have timed out in the snap layer, although they were fine in the p2p packet tracker layer.This is wasteful: we are making requests at a higher rate than we can handle, and thus ignoring responses and refetching stuff. We need to adjust the mechanism so that we do not request more than we can handle -- alternatively, fix the timeout management so that we do not time out deliveries which have already arrived and are just waiting in the queue.
The text was updated successfully, but these errors were encountered: