feat(performance): implement sampling for lifecycle queries #14283
Conversation
|
Not a WIP in the sense that this works and could safely get merged but certainly an initial approach to gather feedback |
| @cached_property | ||
| def sample_factor(self) -> Optional[float]: | ||
| factor = None | ||
| if self._data.get("sample_results", False): |
There was a problem hiding this comment.
Q: Why not send the sample factor from the FE?
There was a problem hiding this comment.
I'm still unsure what the approach should be with sampling. Should we let the client decide or should we make decisions for them?
@mariusandra seems to like the idea of the client deciding too. From my side, I think I still have non-technical users in mind (i.e. building for PMs), but maybe I should drop that and think about devs first instead. If that's the case, then yeah I'd send this from the frontend and maybe make it a slider-like thing like Marius mentioned
There was a problem hiding this comment.
Note we can hard-code the value from the frontend if we want and keep api flexibility up :)
| @@ -85,6 +85,8 @@ def parse_response(stats: Dict, filter: Filter, additional_values: Dict = {}) -> | |||
| counts = stats[1] | |||
| labels = [item.strftime("%-d-%b-%Y{}".format(" %H:%M" if filter.interval == "hour" else "")) for item in stats[0]] | |||
| days = [item.strftime("%Y-%m-%d{}".format(" %H:%M:%S" if filter.interval == "hour" else "")) for item in stats[0]] | |||
| if filter.sample_factor: | |||
| counts = [c * (1 / filter.sample_factor) for c in counts] | |||
There was a problem hiding this comment.
Nit: Probably worth creating a correct_for_sampling function.
|
Will move fast/iteratively with this project and evolve the API & UI as I go along |
Problem
#12908
Changes
Adds end-to-end sampling support for lifecycle queries. Mostly to get feedback at this point.
Why lifecycle? It was just the easiest query to work with.
How did you test this code?
Manually