vtlim commented on a change in pull request #12128: URL: https://github.com/apache/druid/pull/12128#discussion_r785162976
########## File path: docs/operations/mixed-workloads.md ########## @@ -0,0 +1,213 @@ +--- +id: mixed-workloads +title: Configure Druid for mixed workloads +sidebar_label: Mixed workloads +--- + +<!-- + ~ Licensed to the Apache Software Foundation (ASF) under one + ~ or more contributor license agreements. See the NOTICE file + ~ distributed with this work for additional information + ~ regarding copyright ownership. The ASF licenses this file + ~ to you under the Apache License, Version 2.0 (the + ~ "License"); you may not use this file except in compliance + ~ with the License. You may obtain a copy of the License at + ~ + ~ http://www.apache.org/licenses/LICENSE-2.0 + ~ + ~ Unless required by applicable law or agreed to in writing, + ~ software distributed under the License is distributed on an + ~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + ~ KIND, either express or implied. See the License for the + ~ specific language governing permissions and limitations + ~ under the License. + --> + +If you frequently run concurrent, heterogeneous workloads on your Apache Druid cluster, configure Druid to properly allocate cluster resources to optimize your overall query performance. + +Each Druid query consumes a certain amount of cluster resources, such as processing threads, memory buffers for intermediate query results, and HTTP threads for communicating between Brokers and data servers. +"Heavy" queries that return large results are more resource-intensive than short-running, "light" queries. +You typically do not want these long resource-intensive queries to throttle the performance of short interactive queries. +For example, if you run both sets of queries in the same Druid cluster, heavy queries may employ all available HTTP threads. +This situation slows down subsequent queries—heavy and light—and may trigger timeout errors for those queries. +With proper resource isolation, you can execute long-running, low priority queries without interfering with short-running, high priority queries. + +Druid provides the following strategies to isolate resources and improve query concurrency: +- **Query laning** where you set a limit on the maximum number of long-running queries executed on each Broker. +- **Service tiering** which defines separate groups of Historicals and Brokers to receive different query assignments based on query priority. + +You can profile Druid queries using normal performance profiling techniques such as Druid query metrics analysis, thread dumps of JVM, or flame graphs to identify what resources are affected by mixed workloads. +The largest bottleneck will likely be in the Broker HTTP threads. +Mitigate resource contention of the Broker HTTP threads with query laning. +However, mixed workloads also affect other resources, including processing threads and merge buffers. +Reduce the burden on these resources by applying service tiering in addition to query laning. + + +## Query laning + +When you need to run many concurrent queries having heterogeneous workloads, start with query laning to optimize your query performance. +Query laning restricts resource usage for less urgent queries to ensure dedicated resources for high priority queries. + +Query lanes are analogous to carpool and normal lanes on the freeway. With query laning, Druid sets apart VIP lanes from other general lanes. Review comment: ```suggestion Query lanes are analogous to carpool and normal lanes on the freeway. With query laning, Druid sets apart prioritized lanes from other general lanes. ``` -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
