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

[Dashboards][Telemetry] time_to_data does not have stable semantics #209018

Open
thomasneirynck opened this issue Jan 30, 2025 · 2 comments
Open
Assignees
Labels
Team:Presentation Presentation Team for Dashboard, Input Controls, and Canvas

Comments

@thomasneirynck
Copy link
Contributor

thomasneirynck commented Jan 30, 2025

The time_to_data-metric of the dashboard_loaded-EBT frequently shifts (it corresponds to key1), and it is often not clear what causes these shifts.

This makes long term evaluations difficult of how data-loading improves/regresses.

This is an important metric because:

  • it gives an indication of how long it takes to load the contents of a dashboard (data-fetching + rendering. ie. the time after chaning a filter, time-range, ...), without all the overhead that is not rendering or data-loading related (e.g. any bootstrapping the dashboard app itself does, the loading of the saved-object).
  • by subtracting time_to_data from duration, we derive a metric called dashboard_overhead. This should capture the flat non-panel related execution of the dashboard-app.

Describe a specific use case for the feature:

time_to_data should be implemented in a way that it is less sensitive to large shifts. It should more accurately capture the time it takes to complete the contents of the panels of a dashboard (data + chart-rendering), without the flat overhead of initializing it.

@thomasneirynck thomasneirynck added the Team:Presentation Presentation Team for Dashboard, Input Controls, and Canvas label Jan 30, 2025
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-presentation (Team:Presentation)

@thomasneirynck thomasneirynck changed the title [Dashboards][Telemetry] time_to [Dashboards][Telemetry] time_to_data should be more stable Jan 30, 2025
@thomasneirynck thomasneirynck changed the title [Dashboards][Telemetry] time_to_data should be more stable [Dashboards][Telemetry] time_to_data is not stable Jan 30, 2025
@thomasneirynck thomasneirynck changed the title [Dashboards][Telemetry] time_to_data is not stable [Dashboards][Telemetry] time_to_data does not have stable semantics Jan 30, 2025
@thomasneirynck
Copy link
Contributor Author

an example of this is how #208050 caused a very large seesaw swing in time_to_data and dashboad_overhead, and it's not really clear why

@ThomThomson ThomThomson self-assigned this Feb 4, 2025
@thomasneirynck thomasneirynck self-assigned this Feb 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Team:Presentation Presentation Team for Dashboard, Input Controls, and Canvas
Projects
None yet
Development

No branches or pull requests

3 participants