-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Add debounce to the status observers to reduce unnecessary CPU loops #108952
Conversation
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.
Overall makes sense to me, but to avoid regressions it would be nice if we could update the unit test to catch the edge case that wasn't covered by the existing debounce:
it('debounces events in quick succession', async () => { |
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.
With this change the setup to start time (locally) is less than a second:
[2021-08-17T10:54:48.282-07:00][INFO ][plugins-system.standard][]---Setting up [112] plugins: ...
//...setup logs
[2021-08-17T10:54:51.084-07:00][INFO ][plugins-system.standard][]---Starting [112] plugins: ...
One small suggestion is to use the same const
for the debounce time in getPluginStatuses
and getDerivedStatus$
but other than waiting for green CI, LGTM.
Note: My initial LGTM is pending other ✅
@@ -76,6 +76,7 @@ export class PluginsStatusService { | |||
|
|||
public getDerivedStatus$(plugin: PluginName): Observable<ServiceStatus> { | |||
return this.update$.pipe( | |||
debounceTime(25), |
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.
We have the same value for debounceTime
in getDerivedStatus$
as in getPluginStatuses$
now, which makes sense. Maybe we should consider adding the value as a const and using that in both?
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 removed it from getPluginStatuses$
. I noticed it's not actually needed there.
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.
Seems to work for me. +1 on improving the test coverage for this case.
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 pending other ✅
@cachedout this may fix #107300 as well. Let's test it once it's been merged and available in a snapshot. |
Thank you all for your comments!
|
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.
🚀
@@ -247,7 +247,6 @@ describe('PluginStatusService', () => { | |||
subscription.unsubscribe(); | |||
|
|||
expect(statusUpdates).toEqual([ | |||
{ a: { level: ServiceStatusLevels.available, summary: 'All dependencies are available' } }, |
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 longer needed since we don't emit the initial transient status anymore.
Pinging @elastic/kibana-core (Team:Core) |
@joshdover Thanks! FWIW, I tried all day to replicate the slow-start Kibana problem by hand and I still can't get it to happen, but for whatever reason in the CI, we see it regularly. Hopefully this is the fix! |
💚 Backport successful
This backport PR will be merged automatically after passing CI. |
💚 Build Succeeded
Metrics [docs]
History
To update your PR or re-run it, just comment with: |
…108952) (#108998) Co-authored-by: Alejandro Fernández Haro <[email protected]>
Backporting to 7.14.1 as well: #109052 |
Great diagnosis @afharo <3 |
Summary
Resolves #108950
During plugin registration, plugins can specify their own custom logic to declare the status. The status service was triggering an update of its observers for each registration, using unnecessary extra CPU loops.
This PR adds
debounceTime
to swallow any requests happening too close in time.For maintainers