-
Notifications
You must be signed in to change notification settings - Fork 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
Move DotNetty batching scheduling off of DotNetty STEE and onto HashedWheelTimer #4678
Move DotNetty batching scheduling off of DotNetty STEE and onto HashedWheelTimer #4678
Conversation
Raw throughput numbers were the same as However, significant change in idle CPU numbers! Some important notes:
Before
After
Looks like a ~50% drop in idle CPU consumption to me. The nodes in the cluster using batching are now in the same ballpark is the ones that aren't. |
() => | ||
{ | ||
// want to fire this event through the top of the pipeline | ||
context.Channel.Pipeline.FireUserEventTriggered(FlushCmd.Instance); |
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 wanted to use an event for this as this will allow me to do some sampling around how often the FlushCmd
has to be invoked separately from other flushes. But that may end up being a distinction without difference depending on how I write the sampler.
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.
One question and one nit but looks good otherwise
public readonly BatchWriterSettings Settings; | ||
public readonly IScheduler Scheduler; | ||
private ICancelable _flushSchedule; | ||
|
||
internal bool CanSchedule { get; private set; } = true; |
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.
It looks like we don't use CanSchedule
anywhere, we are only setting it. Should it be removed?
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'll remove it
_flushSchedule = Scheduler.Advanced.ScheduleRepeatedlyCancelable(Settings.FlushInterval, | ||
Settings.FlushInterval, | ||
() => | ||
{ | ||
// want to fire this event through the top of the pipeline | ||
context.Channel.Pipeline.FireUserEventTriggered(FlushCmd.Instance); | ||
}); |
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.
So this is one heck of an edge case.... But do we want to have any sort of warning if the flush interval is for some unknown reason less than tick-duration
on HWT?
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.
No we don't - but it shouldn't be an issue. The scheduler will just put it in the next available bucket if that's the case.
@@ -114,72 +121,66 @@ public override Task WriteAsync(IChannelHandlerContext context, object message) | |||
* across the network. | |||
*/ | |||
var write = base.WriteAsync(context, message); | |||
if (Settings.EnableBatching) |
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.
Removed the Settings.EnableBatching
checks - this stage never runs if this is false.
work for #4563 and #4636