9e30a3eb29
* refactor: rework querier concurrency limiting With #4752 we introduced a concurrency limit into the querier. It works by drawing permits from a central semaphore whenever we create a `QuerierNamespace`. This however only limits concurrency during query planning and not query execution, because the objects contained within the plan (chunks and some metadata) neither reference the permit nor the `QuerierNamespace`. Now one approach to fix that would be to wire up the permit all the down into all the query-related data structures. This however is very fiddly and potentially will get lost at some point, because as soon as we transform these data structures -- e.g. into streams -- the permit might get lost again. This will be potentially query-dependent and very hard to debug. So instead we reverse the approach and track the permits at the upper layer of the stack: the gRPC service entry points. There we also need to be careful -- e.g. when we return streams to tonic -- but it's way easier to review that then the deeply nested object hierarchy that is involved with queries. Also the separation of concerns is a bit clearer, because why would a "chunk" care about the "query concurrency" as a whole. * refactor: improve gRPC permit keeping and prepare tests |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||