Date: Tue, 11 Oct 2011 12:18:08 +0200 From: Stefan Esser <se@freebsd.org> To: Michael Bushkov <bushman@freebsd.org> Cc: freebsd-hackers@freebsd.org, dougb@freebsd.org, perryh@pluto.rain.com Subject: Re: Does anyone use nscd? Message-ID: <4E9417E0.9050804@freebsd.org> In-Reply-To: <CANkaO_GMY4TiaJW3k0KxQ_x=JdsWLpyV1jXB_S4jjLhSt4Sw2g@mail.gmail.com> References: <20111004160043.GA16034@lpthe.jussieu.fr> <051853CE-03EC-4EEC-A5AC-C380131B28E4@gsoft.com.au> <alpine.BSF.2.00.1110050931310.18373@mail.fig.ol.no> <j6k00t$2tk$1@dough.gmane.org> <4e8f073c.3g2aD/Zz9KdsWOKN%perryh@pluto.rain.com> <CAFHbX1LN5zidePrusaSyD_nE79VwbjNpc4s7TwMszYKBK=n4NQ@mail.gmail.com> <CANkaO_ESdeoSiuwatqaPEY%2BDDN8eGGj_ymPsxOsu9AOtHX6ydQ@mail.gmail.com> <CAHHaOuYkhYp_x5ONbRcr_8Zb6ZcyPaZZvG02f6f1%2B8XyQYUe%2Bg@mail.gmail.com> <4E935105.1090602@FreeBSD.org> <4e942bc2.diL95Gr/XYELJ%2Bgj%perryh@pluto.rain.com> <CANkaO_GMY4TiaJW3k0KxQ_x=JdsWLpyV1jXB_S4jjLhSt4Sw2g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 11.10.2011 10:32, schrieb Michael Bushkov: > On Tue, Oct 11, 2011 at 1:42 PM, <perryh@pluto.rain.com> wrote: >> Doug Barton <dougb@freebsd.org> wrote: >> >>> On 10/10/2011 11:55, David Brodbeck wrote: >>>> Is there any reason to cache negative hits? >>> >>> It's very important for DNS since there are a fairly large number >>> of misbehaving applications that don't stop querying until they >>> get some kind of answer. >> >> Would this need be sufficiently covered if negative cache timeout >> were set to, say, 1/4 of a second? That should be short enough >> to cover virtually any instance in which a missing entry is added >> manually and the new entry then needs to be found. > > You can actually change negative caching timeout as well as turn it > off completely. There's negative-time-to-live option in nscd.conf (see > http://www.freebsd.org/cgi/man.cgi?query=nscd.conf). Unfortunately it > accepts only integer number of seconds, so 1/4 of a second is > impossible. But you can turn negative caching off completely by > setting negative-time-to-live to 0. Just an idea, which would slightly complicate the internal logic, but not by too much, IMHO: How about counting negative hits and requiring a *threshold* to be crossed, *before cached negative results are returned*? E.g. if there is a negative response, then put it into the cache with a timeout of e.g. 60 seconds, but do not rely on the cached value but repeat the actual lookup if another query is issued. Only after e.g. 5 queries that were not answered from the cache within the (relatively short) negative cache timeout period, the cached reply is returned as is currently done for the second query already. This would introduce a 3rd state besides known-to-exist and not-to-not-exist. The 3rd state would be "expected-to-not-exist" and that state would migrate to known-to-not-exist for a (possibly longer time) after it has been confirmed a number of times by repeating the lookup. The code changes should be simple, only needing a counter for the number of retries for a cached negative result. The threshold should be configurable as well as the timeout for the 3rd state. This should cover install scripts (which check just once or twice for the existance of a UID/GID before deciding to create it), but also negative DNS lookups (which would quickly migrate to state known-to-not-exist). Think of this proposal as a rate-limiting of queries for probably not existing entries. There will be the specified number of retries after negative replies within the specified time window. Any other query will be answered from the cached negative entry. But if there is a positive reply, before the retries are used up, the newly defined value will be cached instead of the negative reply without any delay (not even 1/4 of a second). Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E9417E0.9050804>