-
Notifications
You must be signed in to change notification settings - Fork 892
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
Avoid contention on netty channel promise #1321
Conversation
@merlimat what is the impact of this change? like how much performance change we can get? do you have a microbenchmark for that? |
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.
+1 good catch!
I cannot quantify directly the impact yet. I'm working to remove other contention points in Pulsar code. The results are only visible when most contention points are removed.
Basically this means that this mutex has blocked IO threads for a total of 753 millis (the profiling was done over 5minutes at 100K writes/s). That is all added to latency.
|
With profiler, I have seen there can be heavy contention between BK threads and Netty IO thread due the the checking for channel write condition that was recently added for monitoring purpose.
The problem relies in that there is one BK thread that is doing the
writeAndFlush()
on the PCBC and getting theChannelFuture
, adding a listener to the future.The write operation, though, is completed in the Netty IO thread and the promise gets also triggered from that thread. So, there is contention between current thread adding the listener and the IO threads completing the promise.
If we add the listener before doing the write on channel, we can avoid the contention. Another option could be to do the write from the Netty IO thread as well.