Split incoming requests by day, run them in parallel, and cache query results.#1029
Conversation
8b29dca to
266cb9c
Compare
|
This is rebased on the new caching interfaces and should be ready for review now. |
csmarchbanks
left a comment
There was a problem hiding this comment.
Would you mind creating some docs for the new flags/behavior?
Gopkg.toml
Outdated
There was a problem hiding this comment.
Looks like the referenced pr has been merged, so this can all be removed.
pkg/querier/frontend/frontend.go
Outdated
pkg/querier/frontend/frontend.go
Outdated
There was a problem hiding this comment.
Should this be a separate flag from caching? Seems like caching results wouldn't work very well without this.
There was a problem hiding this comment.
The main criticism I've heard against trickster is that it mutates the request. Also, we've put the step alignment into Grafana now. So I wanted to make this optional as I think it shouldn't be necessary in some cases. Its a niche case, for sure.
There was a problem hiding this comment.
These responses don't look empty
There was a problem hiding this comment.
Parititon -> Partition
bb805ef to
7315796
Compare
Signed-off-by: Tom Wilkie <tom.wilkie@gmail.com>
Split incoming requests by day and run them in parallel. - Generic code to parse incoming query_range requests, mutate them and round trip them. - Split queries along day boundaries, modulo step. - Run queries in parallel and combine their results. - Ensure we propagate org ids correctly; add e2e tests. - Take care to ensure we propagate trace IDs correctly; involved updating weaveworks/common. Query results caching. - Align incoming queries with their step to make the results more cachable. - Work out intersection of query and cached result and only query for difference. - Cache query results using the key `hash(userid, promql query, step, day)`. - Cache multiple, non-overlapping time ranges per day. Don't cache the last 1 minute. - Hash the key for the query results cache. - Don't cache the last minute, as results can still be in flux. - Make sure the trimmed results should also align with step. Signed-off-by: Tom Wilkie <tom.wilkie@gmail.com>
7315796 to
649666f
Compare
dep couldn't find a solution so I had to encourage it to use the later grpc and proto versions - I think this is because the constraint added into common on gogo/status. Signed-off-by: Tom Wilkie <tom.wilkie@gmail.com>
649666f to
a22db82
Compare
Done! |
…m the upstream repo. Signed-off-by: Tom Wilkie <tom.wilkie@gmail.com>
Signed-off-by: Tom Wilkie <tom.wilkie@gmail.com>
csmarchbanks
left a comment
There was a problem hiding this comment.
Is the Check endpoint on an ingester still going to work? Seems like client.RegisterIngesterServer will no longer register the Check method, so another register will need to be added to cmd/ingester/main.go?
Gopkg.toml
Outdated
There was a problem hiding this comment.
Are these new constraints necessary? Or were they just needed for when you were pointing to a branch?
There was a problem hiding this comment.
I needed them to get dep to successfully find a solution, but now it has, I don't seem to need them. Removed.
There was a problem hiding this comment.
Looks like weaveworks/common is still new and unneeded
c91dac1 to
17a544b
Compare
Good catch! I had fixed but forgot to push... |
Signed-off-by: Tom Wilkie <tom.wilkie@gmail.com>
|
BTW we've deployed this in production and it makes a huge difference to query performance. |
|
One last thing to remove in Gopkg.toml, then this LGTM |
Signed-off-by: Tom Wilkie <tom.wilkie@gmail.com>
|
Thanks! |
Includes #995, fixes #977, fixes #963, fixes #266Continuation of the work proposed in https://docs.google.com/document/d/1lsvSkv0tiAMPQv-V8vI2LZ8f4i9JuTRsuPI_i-XcAqY/edit?usp=drive_web&ouid=103586900408483314805.