Closed wlach closed 6 years ago
Backend returns 72 KB for 24 hours and 1.2 MB file for 14 days data which is huge. Would it be possible to return lesser(interval) data from services?
We could do it at that level, but as I said, the slowness is mostly on the client. Downloading/fetching the data is relatively fast. My preference would be to leave things as-is there, in case some other consumer of the API wanted a complete set of data.
I think I've changed my mind on the above: let's still use the percentile filter, it should still be useful (since the reduced data will still be affected by the calculations).
I think it makes sense to do this in the same place I mentioned above though. Here's one possible implementation strategy:
Hopefully that makes sense?
In the end I think just clamping on hourly / daily intervals makes more sense. Have a PR brewing to that effect.
Here's what hourly agagregates look like for 14 days worth of main crashes:
The detail view seems to work pretty well for smaller intervals (24, 48 hours) but seems to get kind of slow when viewing larger ones (e.g. 7 days). I think most of this is metricsgraphics/d3 being slow with this quantity of data -- not sure how easy that is to fix. Another solution might be to only display data on an hourly interval for older data (probably taking the median value). That will still show changes over the course of each day without slowing the ui to a crawl.
We could probably do this in the getTransformedSeriesList method in the detail view. Likely if we do this sort of filtering, we should just ignore the results of the percentile filter:
https://github.com/mozilla/missioncontrol/blob/a1d0044cbf1d0d113ccfc5756379680584af3a8c/frontend/ui/detailview.jsx#L21