-
Notifications
You must be signed in to change notification settings - Fork 107
remove excessive request alignment, add MDP optimization and pre-normalisation #951
Conversation
62b221b
to
44feb3e
Compare
c525a2d
to
1f78d5a
Compare
Thoughts on moving the prometheus removal to a separate PR? |
1f78d5a
to
c947cf9
Compare
ffa1608
to
6b5b654
Compare
clearer. more robust.
easier to understand
this will simplify our testing
7abd386
to
260c7eb
Compare
maxPointsPerReqSoft workload benchmarkgoalprogressively fetch longer time window of different interval data. track response sizes and latencies. check overhead of maxPointsPerReqSoft when it's pushed to the extreme.
how?
We keep using the same storage-schemas.conf as posted above, and a similar fakemetrics command, but with longer time span to backfill:
The main question is, how many points do we fetch per hour worth of data? Well it depends...
let's try a spectrum starting at no maxPointsPerReqSoft breach all the way to breach it as significantly as possibly. the hard limit allows us to query 20M/150k=~133 hours of data. execution
observations
cpu profilingI collected a cpu profile in a separate run, and noticed that none of planRequests or PointsFetch functions showed up in the top 50. (even when we were querying timeranges of 130-133). Meaning the performance is definitely good enough. (item 50 on the list was at 0.0.24% flat) |
Conclusionsbased on the experiments done so far:
|
fix #926 |
see #926
Note that when MDP/PN optimizations are disabled (or for non-MDP-optimizable singles), the behavior of request planning is the same as in master (set highest resolution based on TTL and ready status) except:
TODO: