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

Add debounce to the status observers to reduce unnecessary CPU loops #108952

Merged
merged 2 commits into from
Aug 17, 2021

Conversation

afharo
Copy link
Member

@afharo afharo commented Aug 17, 2021

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

@afharo afharo added bug Fixes for quality problems that affect the customer experience release_note:skip Skip the PR/issue when compiling release notes auto-backport Deprecated - use backport:version if exact versions are needed v7.15.0 v7.14.1 labels Aug 17, 2021
@afharo afharo requested a review from a team as a code owner August 17, 2021 17:23
@afharo afharo requested a review from joshdover August 17, 2021 17:23
Copy link
Member

@lukeelmers lukeelmers left a 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 () => {

src/core/server/status/plugins_status.ts Outdated Show resolved Hide resolved
Copy link
Contributor

@TinaHeiligers TinaHeiligers left a 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),
Copy link
Contributor

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?

Copy link
Member Author

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.

@TinaHeiligers TinaHeiligers self-requested a review August 17, 2021 18:19
Copy link
Contributor

@joshdover joshdover left a 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.

Copy link
Contributor

@TinaHeiligers TinaHeiligers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM pending other ✅

@joshdover
Copy link
Contributor

@cachedout this may fix #107300 as well. Let's test it once it's been merged and available in a snapshot.

@afharo
Copy link
Member Author

afharo commented Aug 17, 2021

Thank you all for your comments!

  1. Added the test in 1aa2639 (#108952).
  2. I also had to update some previous tests since we now don't return the initial default All dependencies are available anymore thanks to the initial debounce
  3. I also noticed that the debounceTime is only needed in one this.update.pipe. Updated the code for that and added a comment explaining why it's needed there.

Copy link
Member

@lukeelmers lukeelmers left a 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' } },
Copy link
Member Author

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.

@afharo afharo removed the v7.14.1 label Aug 17, 2021
@afharo afharo enabled auto-merge (squash) August 17, 2021 18:49
@lukeelmers lukeelmers added the Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc label Aug 17, 2021
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-core (Team:Core)

@cachedout
Copy link
Contributor

this may fix #107300 as well. Let's test it once it's been merged and available in a snapshot.

@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!

@afharo afharo merged commit 335393e into elastic:master Aug 17, 2021
@afharo afharo deleted the status-observers/add-debounce branch August 17, 2021 20:46
@kibanamachine
Copy link
Contributor

💚 Backport successful

Status Branch Result
7.x

This backport PR will be merged automatically after passing CI.

@afharo afharo added the v7.14.1 label Aug 17, 2021
@kibanamachine
Copy link
Contributor

💚 Build Succeeded

Metrics [docs]

✅ unchanged

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@afharo
Copy link
Member Author

afharo commented Aug 18, 2021

Backporting to 7.14.1 as well: #109052

@kobelb
Copy link
Contributor

kobelb commented Sep 1, 2021

Great diagnosis @afharo <3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
auto-backport Deprecated - use backport:version if exact versions are needed bug Fixes for quality problems that affect the customer experience release_note:skip Skip the PR/issue when compiling release notes Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc v7.14.1 v7.15.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Kibana startup timing has doubled in the last 30 days
8 participants