How does clients-per-query work?
- Updated on 16 Oct 2018
- 2 minutes to read
How does clients-per-query work when named is running?
There is often confusion over clients-per-query, especially when encountering logfile entries such as these below:
10-May-2011 13:01:02.745 resolver: notice: clients-per-query increased to 20 10-May-2011 13:21:02.747 resolver: notice: clients-per-query decreased to 19 10-May-2011 14:47:03.775 resolver: notice: clients-per-query increased to 15 10-May-2011 15:01:01.679 resolver: notice: clients-per-query increased to 15
A client in this scenario is a unique query that has been received by named and which should receive its own query response. (Duplicate queries are identified and discarded.)
When there are multiple client queries received for the same 'name' (in fact same name and type) that cause the server to perform queries on the behalf of the requester, then named optimizes how it operates. Behind the scenes, named is doing the necessary work just once, but the multiple requests (clients) are linked to that one piece of work.
named limits the number of clients that can simultaneously be querying for a particular name/type. The initial limit is clients-per-query, which by default starts at 10. If 10 clients are already waiting for an answer for example.com/A, then the 11th client to ask for it is dropped. When an answer finally arrives for example.com/A, the limit is raised by 5.
Later, if there's another name/type that builds up to 15 clients waiting for an answer, and a 16th comes in and gets dropped, then when an answer arrives for that name, the limit will be raised to 20, and so on.
This continues until the limit has reached max-clients-per-query, which defaults to 100.
After a while if named is getting along successfully with 100, it will try lowering the limit back down to 99, then 98, and so on until it reaches the original 10.
Thus the significant tuning knob here is max-clients-per-query, which you need to have large enough to handle the situation under normal processing, where you have a lot of duplicate queries for the same name, so that they can all wait until that name is resolved and placed in cache.
The other side of this is that if your server is stormed by duplicate queries from different clients, you want named to be dropping most of these queries - so you don't want max-clients-per-query to be too large either.
Most clients who don't get an answer will retry the query, so having max-clients-per-query too small for an unexpected but genuine peak in 'same' client queries shouldn't cause more than a short delay in query resolution - noting particularly that once the in-progress query is resolved by the server (and assuming that the authoritative servers aren't being silly and providing an answer with TTL 0), it will be added to cache so that query retries can be answered immediately.