Skip to content
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

Expose throttleTimeout on the command line #4

Closed
rg0now opened this issue Sep 2, 2022 · 0 comments
Closed

Expose throttleTimeout on the command line #4

rg0now opened this issue Sep 2, 2022 · 0 comments
Assignees

Comments

@rg0now
Copy link
Member

rg0now commented Sep 2, 2022

The constant throttleTimeout controls the time under which config generation is suppressed. The idea is that we do not want to re-generate the config and update the API server every time one of our watchers update a resource in the local storage since the config rendering pipeline is expensive. Rather, every time a watcher triggers an update we start a timer to wait throttleTimeout msecs and we completely suppress all config rendering triggers until the timer ticks. This decreases the CPU footprint of the operator at the cost of artificially delaying all updates with at most throttleTimeout msecs.

In large clusters with massive control plane churn, the hardcoded 250 msec timeout would be too little. This enhancement request covers:

  • make throttling the default: remove DefaultEnableRenderThrottling and EnableRenderThrottling and change the code equally to as if EnableRenderThrottling=true was in effect,
  • expose throttleTimeout to the command line and as an ENV variable.
@rg0now rg0now self-assigned this Sep 2, 2022
@rg0now rg0now closed this as completed in a4416ca Jan 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant