v1.18: client: Start resending sooner during send_and_confirm_transactions_in_parallel (backport of #348)
#357
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
![mergify[bot]](https://avatars.githubusercontent.com/in/10562?s=60&v=4){kind=small}
anwayde
pushed a commit
to firedancer-io/agave
that referenced
this pull request
Jul 23, 2024
…ctions_in_parallel` (backport of anza-xyz#348) (anza-xyz#357) client: Start resending sooner during `send_and_confirm_transactions_in_parallel` (anza-xyz#348) client: Confirm sooner during send_and_confirm_in_parallel (cherry picked from commit b2f4fb3) Co-authored-by: Jon C <[email protected]>
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.
Problem
send_and_confirm_transactions_in_parallelis really great, but during times when one particular validator is slow or offline, sending and confirming transactions can take forever. This is because we wait to send all of the transactions before moving on to resending.With the congestion on the network nowadays, it makes deploying a program very difficult.
Summary of Changes
This really just moves things around to start retrying and confirming sooner.
Rather than send all transactions first, and then kick off the resends, the concept is to add the transaction to the unconfirmed queue before sending, and also start retrying two seconds after the start of the sending.
The impact of this change is tough to gauge, especially because of volatile priority fees on mainnet, but I tried sending 100 self-transfers with 2 lamports (2 million micro-lamports) per CU for priority fees, and a 450 CU limit. On 5 trials, here's what I got:
While testing without the patch, I had to abort a couple of runs because the sending was absolutely crawling, only one send every 3 seconds.
This is an automatic backport of pull request #348 done by [Mergify](https://mergify.com).