-
Notifications
You must be signed in to change notification settings - Fork 1.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
feat: option to query metrics only on polling interval #3940
Conversation
/run-e2e internals* |
/run-e2e Update: You can check the progress here |
/run-e2e |
/run-e2e predictkube* |
/run-e2e external* |
f29ecf9
to
829a541
Compare
/run-e2e external* |
/run-e2e |
/run-e2e |
1d0879c
to
3795e1b
Compare
/run-e2e external* |
48c351c
to
b0f48bc
Compare
/run-e2e external* |
47285f9
to
cd1f4dc
Compare
/run-e2e internals/cache_metrics* |
/run-e2e |
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.
Awesome work! I have left some comments inline
/run-e2e |
4ee7c42
to
0960d3e
Compare
/run-e2e |
@zroubalik I took a look at the PR, but it's kind of hard for me to understand the changes with 92 files changed (although I guess most of those are just merging the I am also a little bit confused by the PR title. Doesn't KEDA already query metrics on polling 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.
LGTM! 2 suggestions inline, but not blockers
/run-e2e |
On my local test it looks like it should work will. |
@champly thanks a lot for the response, I have already solved this :) |
/run-e2e external* |
/run-e2e predictkube* |
/run-e2e external_scaler_so* |
/run-e2e |
/run-e2e |
/run-e2e |
Last run and I'll merge it @zroubalik |
please let the merge on me, there might be some PRs merged before this one, so rebase might be needed. |
Signed-off-by: Zbynek Roubalik <[email protected]>
/run-e2e |
/run-e2e |
/run-e2e Update: You can check the progress here |
Signed-off-by: Zbynek Roubalik [email protected]
Adding an option in the trigger spec, that enables caching metric values during polling interval. Then each request coming to KEDA Metrics Server from k8s server (HPA controller), reads the value from this cache and not querying the external service directly. This reduces load on the external services and user have the ability to select this option for an individual trigger in ScaledObject.
, though I am not happy with the name and I am eager to hear suggestions ->queryMetricsOnPollingInterval
useCachedMetrics
See example:
Code changes:
scaler.IsActive()
andscaler.GetMetrics()
calls to single methodscaler.GetMetricsAndActivity()
-> this way we don't ask for the same information twice. I was able to reduce this calls for majority of scalers, there are some leftovers to be refactored, as the logic was more complex (so inscaler.GetMetricsAndActivity()
we callscaler.IsActive()
andscaler.GetMetrics()
methods instead of single call) - TODO tracking issue for leftoversOutstanding issues:
Checklist
trigger.name
&trigger.useCachedMetrics
docs keda-docs#1003Fixes #3921
Relates to #2282