-
Notifications
You must be signed in to change notification settings - Fork 784
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
Reduce RCR Throttling #1545
Reduce RCR Throttling #1545
Conversation
Signed-off-by: Shuting Zhao <shutting06@gmail.com>
fd67c3a
to
7b4129a
Compare
@@ -86,6 +82,7 @@ func NewReportChangeRequestGenerator(client *policyreportclient.Clientset, | |||
polListerSynced: polInformer.Informer().HasSynced, | |||
queue: workqueue.NewNamedRateLimitingQueue(workqueue.DefaultControllerRateLimiter(), workQueueName), | |||
dataStore: newDataStore(), | |||
requestCreator: newChangeRequestCreator(dclient, 3*time.Second, log.WithName("requestCreator")), |
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 set the default ticker interval to 3 seconds (the changeReqeustCreator
will aggregate buffered requests every 3s). Should we allow this to be tuned dynamically across various loads of clusters?
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, if there are no buffered requests will there be an overhead?
Why not use a fixed size pool of workers that block on the queue instead?
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.
if there are no buffered requests will there be an overhead
No.
We can use a fixed size pool, but also need to set a "timeout" interval to flush the queue. So I buffer the requests and aggrate them every fixed interval.
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.
Had a question, see comments.
Signed-off-by: Shuting Zhao <shutting06@gmail.com>
Signed-off-by: Shuting Zhao <shutting06@gmail.com>
Signed-off-by: Shuting Zhao <shutting06@gmail.com>
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! We can discuss the worker pattern and sizing separately for scale and availability as part of the HA design.
@@ -86,6 +82,7 @@ func NewReportChangeRequestGenerator(client *policyreportclient.Clientset, | |||
polListerSynced: polInformer.Informer().HasSynced, | |||
queue: workqueue.NewNamedRateLimitingQueue(workqueue.DefaultControllerRateLimiter(), workQueueName), | |||
dataStore: newDataStore(), | |||
requestCreator: newChangeRequestCreator(dclient, 3*time.Second, log.WithName("requestCreator")), |
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, if there are no buffered requests will there be an overhead?
Why not use a fixed size pool of workers that block on the queue instead?
* buffer report change requests Signed-off-by: Shuting Zhao <shutting06@gmail.com> * fix clusterReportChangeRequest Signed-off-by: Shuting Zhao <shutting06@gmail.com> * further reduce RCRs in background scan Signed-off-by: Shuting Zhao <shutting06@gmail.com> Signed-off-by: vyankatesh_neualto <vyankatesh@neualto.com>
Related issue
Fixes #1497.
This PR adds a buffer to slow down report change request creation.