-
Notifications
You must be signed in to change notification settings - Fork 790
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
Optimize cemented callbacks #4642
Optimize cemented callbacks #4642
Conversation
1caf7fa
to
b5f58df
Compare
dcbb985
to
48f4b0c
Compare
9f19e65
to
4204f98
Compare
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.
I see two new worker thread sets were added, I don't see anything wrong with more threads though was this to deal with specific latency issues or just for clearer separation?
This usage of asio thread pool isn't really correct. Thread pool is designed to process many short lived tasks, and if they're doing io they should be non-blocking (using async io). This is not the case with our current database operations. Because of that, a single task can block others for a potentially long amount of time. To workaround this, each thread pool should process homogenous workload. |
This attempts to optimize the election cementing callbacks. It often takes as long or even longer to cement a confirmed election as it takes to get it confirmed in the first place. This is not a complete solution, there is still a delay, but I hope it's a step in the right direction.
We're debugging this together with @gr0vity-dev who really is doing incredible work to dig deep into this issue.