On Tue, May 08, 2018 at 11:16:51PM +0200, Dominik wrote:
> On 08.05.2018 22:17, Simon Kelley wrote:
> > From: Dominik Derigs <dl...@dl6er.de>, Date: Tue, 8 May 2018 18:44:41 +0200
> >> [PATCH] Remove upper limit of 10,000 for cache size.
> >>
> >> We should allow users to set any (maximum) cache size they like to
> >> set. Even embedded devices usually ship with at least 1 GB of RAM
> >> nowadays so memory shouldn't be an issue.
> >>
> >> Furthermore, this clipping is also not documented in the man page.
> >
> > The reason for the limit is actually performance: there may be plenty of
> > RAM, but the larger the cache is, the slower it is. This is true for
> > reverse (PTR) queries, which are less optimised than normal forward queries.
> >
> > I accept that the limit may now be too small, but it would be worth
> > doing some measurements of cache performance before raising or removing it.
> >
> >
> Hey Simon,
Hello Mailinglist,

> removing the upper limit will not change anything except for the few
> users that have set this value manually to a very large number. However,
> if they did so they were surely not expecting that dnsmasq could just
> ignore their setting.

The undocumented clipping is indeed harmfull.

> Personal experience with dnsmasq as a caching DNS server for a few
> hundred fairly active clients shows no notable performance impact even
> when allowing the maximum cache size to be > 100,000 (query reply time
> from cache is on the order of < 5 msec). It may always be that I miss
> something but even when dnsmasq's cache would be 10 (or more) times
> slower, it would still be much faster than when we'd periodically ask
> upstream servers.

Yes, the benefit of caching.

Thing that you might miss is how fast the dnsmasq server for
the few hunderd fairly active clients is. I'm trying to tell
that the performance penality that Simon warns us about,
might by canceled by high computing power.

Thing I wonder about is how the cache size clipping was discovered.

Geert Stappers
Leven en laten leven

Dnsmasq-discuss mailing list

Reply via email to