Knowledge Base ISC Main Website Ask a Question/Contact ISC
How does clients-per-query work?
Author: Evan Hunt Reference Number: AA-00463 Views: 134 Created: 2011-09-14 03:08 Last Updated: 2017-04-20 06:52 0 Rating/ Voters


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, then the 11th client to ask for it is dropped.  When an answer finally arrives for, 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 where 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 you 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

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.

© 2001-2017 Internet Systems Consortium

For assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership.

ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.

  • There is no feedback for this article
Quick Jump Menu