This message was deleted.

Hi @Kai Sun AFAIK, You are correct in that Broker does not have processing threads, it uses the http threads for processing queries and health checks, lookup loads and other short-lived internal communication. 1/ You also correct about historical processing and the fact that segment scans are queued. The metric that measures the wait time in the queue is:

query/wait/time

-

Milliseconds spent waiting for a segment to be scanned.

2/ I don't know the code enough to answer directly. I know that for each query, the broker will open connections to each data server (historical, real-time task) that contains the segments it needs. It retrieves the data from each and merges them. One metric that might help:

query/node/time	Milliseconds taken to query individual historical/realtime processes.

One known possible contention point is the http threads on the data servers (historicals, real-time tasks)

druid.server.http.numThreads

which need to be enough to hold the sum of

druid.broker.http.numConnections

across all brokers and a bit more for internal comms.

@Sergio Ferragut thx for the confirmation. The other left question is about the ForkJoinPool then. Basically how do we monitor and reason about this baby.