You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
thomasneirynck
changed the title
[Dashboards][Telemetry] time_to
[Dashboards][Telemetry] time_to_data should be more stable
Jan 30, 2025
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
changed the title
[Dashboards][Telemetry] time_to_data is not stable
[Dashboards][Telemetry] time_to_data does not have stable semantics
Jan 30, 2025
The
time_to_data
-metric of thedashboard_loaded
-EBT frequently shifts (it corresponds tokey1
), 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:
time_to_data
fromduration
, we derive a metric calleddashboard_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.The text was updated successfully, but these errors were encountered: