This message was deleted.
# general
s
This message was deleted.
k
However, what I observed was that there were 10 times query timed out in the router than the one failed in the brokers due to this resource contention.
It looks like in your usecase, you are okay with having timeouts for end users/Application. You can think of setting ``druid.server.http.enableRequestLimit`` which will cause broker to reject q's if it has reached its capacity. What we could do is not hit that broker if its overloaded. For this a new router strategy might be needed.
d
There is a setting where you can turn off caching at broker layer. This pushed down some calculations to the historical, which will free up your brokers. For a large cluster, this is a must. Also, if you want to throttle, it is much easier to do this using nginx sidecar that sits next to your router.
k
@Didip Kerabat could you please share that parameter
k
There is a setting where you can turn off caching at broker layer. This pushed down some calculations to the historical, which will free up your brokers. For a large cluster, this is a must.
This is not the case here. We already disabled the caching in the broker layer so to push the queries also to the leaf (historical nodes)
What we could do is not hit that broker if its overloaded. For this a new router strategy might be needed.
@Karan Kumar, can you illustrate a little bit more in detail, what strategy would be needed in this case?
k
Like we would need to code one out 🙂 currently we do not have a strategy like that.
👍 1