Add separate dynamic config knobs for internal-frontend rate limiting #3800
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What changed?
Add
internal-frontend.globalNamespaceRPS
andinternal-frontend.globalNamespaceRPS.visibility
to match thefrontend
versions of those configs, which divide their value among internal-frontend nodes.Why?
"Global" namespace rps was divided among the number of "frontend" nodes, but for users using internal-frontend, that didn't make much sense, since the number of internal-frontend will likely be different from frontend, and the load will be different too.
Only the "global" versions were added, not "per-instance". If they are not set, internal-frontend will use the same per-instance configs as frontend (it will not fall back to the global frontend configs). To use a separate limit for internal-frontend, use the global versions.
How did you test it?
CI
Potential risks
This only applies to configurations using internal-frontend and shouldn't affect anyone else.
Is hotfix candidate?