clintropolis commented on a change in pull request #9407: query laning and load shedding URL: https://github.com/apache/druid/pull/9407#discussion_r388751700
########## File path: docs/configuration/index.md ########## @@ -1476,9 +1476,31 @@ These Broker configurations can be defined in the `broker/runtime.properties` fi |`druid.broker.select.tier`|`highestPriority`, `lowestPriority`, `custom`|If segments are cross-replicated across tiers in a cluster, you can tell the broker to prefer to select segments in a tier with a certain priority.|`highestPriority`| |`druid.broker.select.tier.custom.priorities`|`An array of integer priorities.`|Select servers in tiers with a custom priority list.|None| +##### Query laning + +The Broker provides facilities to aid in query capacity reservation for heterogeneous query workloads in the form of 'laning' strategies, which provide a variety of mechanisms to examine and classify a query, assigning it to a 'lane'. Lanes are defined with capacity limits which the broker will enforce, causing requests in excess of the capacity to be discarded with an HTTP 429 status code, reserving resources for other lanes or for interactive queries (with no lane). + +|Property|Description|Default| +|--------|-----------|-------| +|`druid.query.scheduler.numThreads`|Maximum number of HTTP threads to dedicate to query processing. To save HTTP thread capacity, this should be lower than `druid.server.http.numThreads`.|Unbounded| +|`druid.query.scheduler.laning.type`|Query laning strategy to use to assign queries to a lane in order to control capacities for certain classes of queries.|`none`| + +###### No laning strategy + +In this mode, queries are never assigned a lane and only limited by `druid.server.http.numThreads` or `druid.query.scheduler.numThreads`, if set. This is the default Druid query scheduler operating mode. + +###### 'High/Low' laning strategy +This laning strategy splits queries with a `priority` below zero into a `low` query lane, automatically. The limit on `low` queries can be set to some desired fraction of the total capacity (or HTTP thread pool size), reserving capacity for interactive queries. Queries in the `low` lane are _not_ guaranteed their capacity, which may be consumed by interactive queries, but may use up to this limit if total capacity is available. + +This strategy can be enabled by setting `druid.query.scheduler.laning.type` to `hilo`. + +|Property|Description|Default| +|--------|-----------|-------| +|`druid.query.scheduler.laning.maxLowThreads`|Maximum number of HTTP threads that can be used by queries with a priority lower than 0.|No default, must be set if using this mode| Review comment: I'm not sure I agree that it is particularly confusing, since the HTTP setting is `druid.server.http.numThreads` and the new scheduler 'total' lane is `druid.query.scheduler.numThreads`. Are you considering the hypothetical of if we ever decided to extend the concept of laning to the processing pool I guess? Would this setting be better as a percentage, so one property could be applicable to either usage? It doesn't seem like it would be hard to switch, would just need to adjust `QueryLaningStrategy.getLaneLimits` to take the 'total' limit, and make `ServerConfig` available to the `QueryScheduler` so it could fall back to `druid.server.http.numThreads` if `druid.query.scheduler.numThreads` isn't set. `ServerConfig` should probably already be provided to `QueryScheduler` so it can treat the case where `druid.query.scheduler.numThreads` is higher than `druid.server.http.numThreads` the same as not setting the scheduler `numThreads` at all and ignoring total limiter. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
