-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Destroy tx sets outside of lock. #4761
base: develop
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks pretty good. I left a few comments for your consideration. Feel free to push back on any of them.
FWIW, I did confirm that destroying a std::vector<TxSet_t>
occasionally can take over a 100 microseconds. So I understand the motivation for the change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 Looks good as far as I'm concerned. However clang-format is complaining. If you want you can cherry-pick the topmost commit here which will hopefully deal with the clang-format: https://github.com/scottschurr/rippled/commits/markt-garbage
Internal tracker: RPFC-84 @mtrippled - could you resolve the merge conflicts? |
Currently blocked because this depends on #4505 (which was reverted) |
High Level Overview of Change
This is a performance enhancement that moves destruction of objects that are time consuming to destroy outside of locks.
As transaction volume increases, so does the size of transaction sets for each ledger. This makes it more time-consuming to destroy. Prior to the change, they were destroyed synchronously while in consensus operations, which directly caused consensus to take longer. This change moves unused tx sets into a function that executes on the job queue. Destruction is automatic that way.
Context of Change
Type of Change
Throughput increases after the change. Also, the duration of consensus is reduced under high volumes, such as >4000/s.
Note: This depends on re-introduction of #4505.