Historical http.numThreads should be set to (# Brokers * Broker http.numConnections) + 10 ... so if you have 2 Brokers, then (2 * 40) + 10 = 90 ... numLoadingThreads are used to upload segments to Historical from deep storage, the unzip process is cpu intensive, so I suggest don't ever set this to more than 50% of the cpu count on the machine. The default is 1/6 of the cpu core count to allow plenty of breathing room for query processing. How many cpus on your Broker nodes and your Historical nodes ... and are any other services running on these same nodes?

We're using a query node of size : 2 Vcpus and 16GB ram and historicals of size : 16vcpus and 128 gb ram Our query node is also hosting a router service

I'm not an expert on this part of the product (and/or Jetty threads, I'm not a Java person) ... but my understanding is that the thread pool will allow concurrent query processing, so as long as the queue size is 0 that means you are staying under the http.numThreads count, and therefore all queries able to be active to some extent. As far as what can actually process simultaneously on the cpus, I don't know if there are restrictions in how Jetty threads and/or processing threads can be spread across the cpus on a given machine and kind of wait states on a given thread will allow other threads to continue processing ... however if your Broker has only 2 vCPUs I would venture to say that your Broker level processing won't be able to handle more than 4 or so queries from broker-level processing without seeing some cpu contention. Druid has many layers of processing for a single query, and many "pools" for parallel processing of multiple queries as well as parallel processing of multiple parts of a single query, so something that's hard to estimate ... it's more helpful to just monitor usage and resources to see what might be saturating, then find parameters than adjust behavior in that area of the product.