Query Frontend: Job weights#4076
Conversation
Signed-off-by: Joe Elliott <number101010@gmail.com>
Signed-off-by: Joe Elliott <number101010@gmail.com>
Signed-off-by: Joe Elliott <number101010@gmail.com>
Signed-off-by: Joe Elliott <number101010@gmail.com>
Signed-off-by: Joe Elliott <number101010@gmail.com>
| } | ||
| totalWeight += weight | ||
|
|
||
| if totalWeight >= requestedCount { |
There was a problem hiding this comment.
I think this makes sense. I suppose what we're saying here is that we request of this batch a certain high water mark of work that we're willing to take, and the weight increases the notion of complexity for a single item above this threshold. Implicitly here I suppose is that weight and requestedCount are of the same unit of measure.
There was a problem hiding this comment.
Implicitly here I suppose is that weight and requestedCount are of the same unit of measure.
yes! currently all jobs fill a single "slot" in the batch. the "weight" is basically just making it fill more slots.
| } | ||
| } | ||
|
|
||
| if conditions > 4 { // yay, magic! |
There was a problem hiding this comment.
A fine starting point. I was wonder if each condition is weight++, and maybe each regex is weight+2 or some such. It means for the queue logic that if any condition is present, we'll never consume the entire requested batch. 🤔
What this PR does:
The query frontend treats all jobs as the same size when it farms them out to the queriers. This can cause querier instability b/c some jobs actually require quite a bit more resources to execute. By assigning weights to jobs we can reduce the amount each querier is asked to do will hopefully:
Other changes
parseQueryandcreateFetchSpansRequestto consolidate on theCompilefunction inpkg/traceqlChecklist
CHANGELOG.mdupdated - the order of entries should be[CHANGE],[FEATURE],[ENHANCEMENT],[BUGFIX]