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

Report telemetry on client health #2640

Open
ara4n opened this issue Mar 6, 2018 · 4 comments
Open

Report telemetry on client health #2640

ara4n opened this issue Mar 6, 2018 · 4 comments
Labels
A-Telemetry Telemetry / analytics to understand usage P1 T-Enhancement T-Task Tasks for the team like planning

Comments

@ara4n
Copy link
Member

ara4n commented Mar 6, 2018

As per convo on #riot-dev, I'm wondering if it would be worthwhile to track client health telemetry and feed it into Chrome Dev Tools like react-perf-tools (or some browser-agnostic client-side performance tracking library).

Specifically:

  • Frequency of dispatches (to track whether we unintentionally do something like matrix-org/matrix-react-sdk@c665c1170 which massively increases the number of actions flying around)?
  • Number of listeners? (to see how much those actions are fanning out)
  • Maximum (or average?) time taken to process dispatches?
@lampholder
Copy link
Member

lampholder commented Mar 7, 2018

  • memory profile (v8 heap size, native (RSZ) size, how much time spent major/minor GCing? - if we can get at any of that)
  • time to switch room - Track duration of page changes matrix-org/matrix-react-sdk#1814
  • time to reorder the RoomList?
  • and maybe other common regression areas
  • unhandled exceptions (especially UISI root causes)

(list expanded out by @ara4n)

@lampholder lampholder added T-Task Tasks for the team like planning P1 labels Mar 7, 2018
@ara4n
Copy link
Member Author

ara4n commented Mar 7, 2018

Further to the discussion of "how much would we win if we lazyloaded room members", some other revealing metrics could be:

  • Jank? (i.e. maximum time taken to render a frame; if we can get that programmatically)
  • Hardware stats on the browser (so we can normalise the telemetry to see if it's just a slow/overloaded/broken computer rather than our shitty code - this might be as easy as calculating a bogomips style benchmark during startup, which averages out over time by being stored in local storage. We used this very effectively in the TNG days to determine which video capabilities a given device should advertise for video calling.)
  • number of rooms, number of state events, number of members, number of timeline events
  • number of roomtiles currently in the RoomPanel? (i.e. "is this horrible jank caused by Matthew expanding all his RoomSubLists")
  • time taken to login for the first time on a device (until the app is usable)
  • time taken to open Riot (having previously logged in) (until the app is usable)

@lampholder
Copy link
Member

@lampholder
Copy link
Member

Removing this from the milestone since it's the achievable, expected to close chunks that should be in the milestone (rather than the overarching 'epic')

@aaronraimist aaronraimist added the A-Telemetry Telemetry / analytics to understand usage label Feb 21, 2020
@t3chguy t3chguy transferred this issue from element-hq/element-web Nov 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Telemetry Telemetry / analytics to understand usage P1 T-Enhancement T-Task Tasks for the team like planning
Projects
None yet
Development

No branches or pull requests

4 participants