1576573 - Add telemetry for cursor preloading

Status: NEW

(Core :: Storage: IndexedDB, task, P3)

Description

[Simon Giesecke [:sg] [he/him]]

Bug 1168606 introduced preloading for IndexedDB cursors. The behaviour is significantly influenced by the number of preloaded records, which should be chosen such that preloading improves the performance in the majority of cases (in particular when a cursor is iterated through to the end of the range) without impairing it overly in a significant minority of cases. An indicator of whether the performance is impaired is the number of dropped or invalidated preloaded records. This should be measured by telemetry.

It must be decided if this needs to be discriminated by origin or other parameters.

Comment 1

[Subhamoy [:ssengupta][he/him]]

Attachment: Bug 1576573 - Telemetry added to check rate of cache miss and transaction latency improvements r=#dom-workers-and-storage

Comment 2

[Simon Giesecke [:sg] [he/him]]

Summary of the discussion between @ssengupta, @sg and @janv today:

• Do not gather time measurements with telemetry for now. For measuring specific times, a different approach should be used, see Bug 1601214
• Data should be submitted to Telemetry when a cursor is closed:
  • The number of discarded entries for each Advance/Continue operation should be accumulated/summed up internally. (Only one sum for all of Advance/Continue/ContinuePrimaryKey).
  • In addition, the sum of invalidated entries should be submitted.
  • In addition, the number of entries accessed should be submitted, or the relation of discarded/invalidated entries to the number of entries accessed should be submitted.
  • We probably also need to know the value of the preloading preferences.
• The same entry can only be discarded once, but it can be invalidated multiple times.
• Maybe use a single probe (keyed or categorical histogram) for all different metrics rather than multiple independent probes. Check with Telemetry team / #fxmetrics.
• The data should be used to see if we need to further optimize preloading (statically or dynamically), and in the future if additional optimizations are effective.
• Beyond the scope of this particular bug: This data could also be stored in the SQLite database (similar to maintenance statistics) for dynamic adjustments.