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

[MM-60086][MM-60610] Implement performanceMonitor, collect CPU/memory usage data and send via API #3165

Merged
merged 4 commits into from
Oct 18, 2024

Conversation

devinbinnie
Copy link
Member

Summary

This PR contains a new module called performanceMonitor, which is responsible for:

  • Collect metrics from the main process and various utility processes
  • Dispatch requests to the renderer processes for their respective metrics
  • Collect all metrics and make any transformations necessary
  • Send those metrics to the servers that are able to accept and display them at a set interval

This monitoring will take CPU and memory usage data and send it to servers that have elected to subscribe to the Desktop App for performance data. This data will then be available to administrators via Prometheus.

The idea behind this is to get a better idea of how hard users are getting hit in terms of system resources by various parts of our app. The data is divided up by unique process, so that should give us some idea of which part of the app is causing issues if there is a lot of system resources being dedicated to a process.

Not in scope for this change are load times, which we will calculate and send as part of a separate API created later.

Ticket Link

https://mattermost.atlassian.net/browse/MM-60610
https://mattermost.atlassian.net/browse/MM-60086

Screenshots

image

Implement a performanceMonitor to collect and send anonymous usage data to server dashboards.

@devinbinnie devinbinnie added 2: Dev Review Requires review by a core committer 3: QA Review Requires review by a QA tester 1: UX Review Requires review by a UX Designer labels Oct 10, 2024
@yasserfaraazkhan yasserfaraazkhan added the Run Desktop E2E Tests This label will trigger the workflow that runs e2e automation tests label Oct 11, 2024
Copy link

Here are the test results below:

Test Summary for Linux on commit 2679017

New failed tests found on Linux:

  • menu/view MM-T816 Toggle Full Screen in the Menu Bar

Test Summary for macOS on commit 2679017

All stable tests passed on macOS.

@github-actions github-actions bot removed the Run Desktop E2E Tests This label will trigger the workflow that runs e2e automation tests label Oct 11, 2024
@yasserfaraazkhan yasserfaraazkhan added QA Deferred and removed 3: QA Review Requires review by a QA tester labels Oct 11, 2024
@yasserfaraazkhan
Copy link
Contributor

verified e2e tests locally. No blocking failures.

Copy link
Contributor

@pvev pvev left a comment

Choose a reason for hiding this comment

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

LGTM! thanks @devinbinnie

view.webContents.send(METRICS_REQUEST, view.name, view.serverId);
});
});
await Promise.all(viewPromises);
Copy link
Contributor

Choose a reason for hiding this comment

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

maybe here would be good to add some preventive code:

  1. use allSettled instead of all so you can handle individual promise rejections (in case one of the promise rejects).
  2. would be good to wrap this line and the following in a try..finally, so you can make sure that no matter what the removal of the listener will happen.
  3. should there be a timeout maybe?

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 don't see a case where I wouldn't want the app to be loud about the Promise failing, so the try/catch doesn't seem as necessary. However I did want to add the timeout, thank you for reminding me :)

}

const serverMetricsMap = new Map([...metricsMap].filter((value) => !value[1].serverId || value[1].serverId === view.serverId));
view.webContents?.send(METRICS_SEND, serverMetricsMap);
Copy link
Contributor

Choose a reason for hiding this comment

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

no need for optional chaining view.webContents?.send since it occurs after checking if (!view.webContents)

@@ -83,6 +84,7 @@ export class ServerDropdownView {
// @ts-ignore
transparent: true,
}});
performanceMonitor.registerView('ServerDropdownView', this.view.webContents);
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: for this and all the other registered views, maybe put the names in global constant values.

Suggested change
performanceMonitor.registerView('ServerDropdownView', this.view.webContents);
performanceMonitor.registerView(SERVER_DROPDOWN_VIEW, this.view.webContents);

Copy link
Member Author

Choose a reason for hiding this comment

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

This would be worth doing I'd say if we were using these constants in multiple places, but right now they're just labels that get passed along with the data and will only matter once it hits the dashboard, so I'm okay to leave this one as is.

@devinbinnie devinbinnie removed the 2: Dev Review Requires review by a core committer label Oct 15, 2024
@devinbinnie devinbinnie merged commit 1029516 into master Oct 18, 2024
19 of 20 checks passed
@devinbinnie devinbinnie deleted the MM-60086_MM-60610 branch October 18, 2024 14:13
@devinbinnie
Copy link
Member Author

@amyblais Am I okay to cherry-pick this to v5.10 to include in the next RC?

@devinbinnie devinbinnie added CherryPick/Candidate A candidate for a quality or patch release, but not yet approved and removed 1: UX Review Requires review by a UX Designer labels Oct 18, 2024
@devinbinnie devinbinnie added 4: Reviews Complete All reviewers have approved the pull request and removed Build Apps for PR Builds signed builds for testing labels Oct 18, 2024
@amyblais
Copy link
Member

amyblais commented Oct 18, 2024

Am I okay to cherry-pick this to v5.10 to include in the next RC?

I think this would be better for v5.11 unless this is considered to be urgent for v5.10. I thought you were planning only bug fixes for RC-2. We are cherry-picking to v5.10

@amyblais amyblais added this to the v5.10.0 milestone Oct 18, 2024
@amyblais amyblais added CherryPick/Approved Meant for the quality or patch release tracked in the milestone and removed CherryPick/Candidate A candidate for a quality or patch release, but not yet approved labels Oct 18, 2024
@devinbinnie
Copy link
Member Author

/cherry-pick release-5.10

@mattermost-build
Copy link
Contributor

Cherry pick is scheduled.

mattermost-build pushed a commit that referenced this pull request Oct 18, 2024
… usage data and send via API (#3165)

* [MM-60086][MM-60610] Implement performanceMonitor, collect CPU/memory usage data and send via API

* Translations

* PR feedback

* Update api-types package

(cherry picked from commit 1029516)
@mattermost-build mattermost-build added CherryPick/Done Successfully cherry-picked to the quality or patch release tracked in the milestone and removed CherryPick/Approved Meant for the quality or patch release tracked in the milestone labels Oct 18, 2024
devinbinnie added a commit that referenced this pull request Oct 18, 2024
… usage data and send via API (#3165) (#3171)

* [MM-60086][MM-60610] Implement performanceMonitor, collect CPU/memory usage data and send via API

* Translations

* PR feedback

* Update api-types package

(cherry picked from commit 1029516)

Co-authored-by: Devin Binnie <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
4: Reviews Complete All reviewers have approved the pull request CherryPick/Done Successfully cherry-picked to the quality or patch release tracked in the milestone Docs/Needed QA Deferred release-note
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants